从2PC到Paxos
在分布式系统中,一个事务可能涉及到集群中的多个节点。单个节点很容易知道自己执行的事务成功还是失败,但因为网络不可靠难以了解其它节点的执行状态(可能事务执行成功但网络访问超时)。
若部分节点事务执行失败进行回滚,而其它节点完成事务提交,则事务会处于部分完成的不一致状态。为了避免错误,分布式系统需要使用分布式一致性协议来保证分布式事务的执行。
2PC
两阶段提交(2-Phase Commit, 2PC)是一种比较简单的分布式一致性协议。
2PC协议中,每个事务需要一个协调者来协调各个参与者。每个事务分为两步执行。
- 阶段一: 事务请求
- 协调者向所有参与者发送事务内容,询问是否可以执行事务操作。
- 各参与者执行事务,写事务日志但不进行提交。 各参与者锁定事务相关的资源,保证事务可以正常提交。
- 各参与者向协调者返回响应,YES表示可以提交,NO表示不可以提交。若协调者收到所有参与者的YES回复,则准备进行事务提交。若有参与者回复NO或者超时,则准备回滚事务。
- 阶段二: 提交事务
- 协调者向所有参与者发送提交请求
- 参与者正式提交事务,并在完成后释放相关资源。
- 参与者协调者回复ACK,协调者收到所有参与者的ACK后认为事务提交成功。
- 回滚事务
- 在事务请求阶段若有参与者回复NO或者超时,协调者向所有参与者发出回滚请求
- 各参与者执行事务回滚,并在完成后释放相关资源。
- 参与者协调者回复ACK,协调者收到所有参与者的ACK后认为事务回滚成功。
2PC是一种简单的一致性协议,它存在一些问题:
- 单点服务: 若协调者突然崩溃则事务流程无法继续进行或者造成状态不一致
- 无法保证一致性: 若协调者第二阶段发送提交请求时崩溃,可能部分参与者受到COMMIT请求提交了事务,而另一部分参与者未受到请求而放弃事务造成不一致现象。
- 阻塞: 为了保证事务完成提交,各参与者在完成第一阶段事务执行后必须锁定相关资源直到正式提交,影响系统的吞吐量。
参与者在完成阶段一的事务执行后等待协调者的下一个请求,若协调者超时则可以自行放弃事务。
这种方案仍然有无法保证一致性的缺点,但并不会出现某些资料所述一直锁定资源,无法继续的情况。
3PC
三阶段提交协议(3-Phase Commit, 3PC)进一步将事务请求分为两个阶段,可以解决2PC协议阻塞的问题但无法解决单点服务和不一致的问题。
3PC协议下事务分三步提交:
- CanCommit
- 协调者向所有参与者发送CanCommit请求
- 各参与者判断是否可以完成事务提交,但不执行事务也不锁定资源
- 各参与者根据是否可以完成事务向协调者回复YES或NO
- PreCommit
- 协调者向所有参与者发送PreCommit请求,执行事务预提交
- 各参与者执行事务,写事务日志但不进行提交。 各参与者锁定事务相关的资源,保证事务可以正常提交。
- 各参与者向协调者返回响应。若协调者收到所有参与者的YES回复,则准备进行事务提交。若有参与者回复NO或者超时,则放弃事务。
- DoCommit
- 协调者向所有参与者发送提交请求
- 参与者正式提交事务,并在完成后释放相关资源。
- 参与者协调者回复ACK,协调者收到所有参与者的ACK后认为事务提交成功。若有参与者回复NO或者超时,则回滚事务。
- 参与者进入 PreCommit 状态后,若始终未收到协调者的 DoCommit 请求则会超时后自动执行提交。
三阶段提交协议在CanCommit阶段不锁定资源,解决了阻塞降低吞吐量的问题。
若某个参与者进入 PreCommit 后始终未收到协调者的进一步指令则会自动提交,该策略一定程度上避免协调者单点服务问题。
但是 3PC 仍然无法解决数据不一致问题。
Paxos
Paxos 算法的目的在于使分布式系统对于某个值达成一致,比如 Master 选举过程中保证最终所有节点对 Master 身份达成共识。
作者认为 Paxos 解决的分布式共识问题与分布式事务有着较大不同。
Paxos 认为信道可能丢失数据但是不会篡改数据(即不存在拜占庭将军问题),实际上我们也很容易通过校验检查数据是否被篡改。
在介绍Paxos算法之前,我们先来分析2PC(3PC)协议在分布式共识问题上的不足。
2PC(3PC)协议要求收到所有参与者的 ACK 消息后才认为提交成功,而在Master选举这类分布式共识问题上只需要过半参与者达成一致即可。
而最难以解决的问题在于协调者的单点服务问题,若协调者在过程中崩溃则集群很难继续达成共识。
因此,关键在于设计在有多个协调者的情况下仍然可以达成共识的协议。
Basic Paxos
Paxos算法中有3个角色:
- Proposer: 负责发起提案,类似于2PC中的协调者
- Acceptor: 负责批准提案,类似于2PC中的参与者
- Learner: 不参与提案过程,只从其它Acceptor那里学习已通过的提案。
我们重点介绍 Proposer 和 Acceptor 参与的流程,暂时不介绍 Learner。
在集群中每个进程(节点)可能会扮演其中多个角色。
提案由编号N和值V组成记作(N, V), 每个提案都的编号N是唯一的。保证编号唯一非常简单,若集群中有k个 Proposer, 那么第i个Proposer提出的第n个提案编号为 i + k * n。
我们希望集群最终可以选中一个V,且所有节点知道集群最终选定的V值。
算法做出几个规定:
- 只要集群中有超过半数的Accpetor批准了提案,Proposer 就可以认为集群对接受了提案
- 在一轮投票中,Acceptor总是批准它收到的第一个提案
- 在一轮投票中,Acceptor可以批准多个提案,但是批准提案的值V必须相同
算法分为两个阶段:
- prepare 阶段
- Proposer 选择提案N,向半数以上Acceptor发送请求Prepare(N)
- Acceptor 保存自己受到过的最大请求的编号 maxN 和已接受的编号最大提案 (acceptedN, acceptedV)。
- 若 maxN > N, 那么 Acceptor 返回拒绝响应
- 若 maxN < N, 那么 Acceptor 返回已接受的编号最大提案(acceptN, acceptV),若尚未接受过提案则返回空的成功响应。同时,Acceptor 更新 maxN, 即不会在接受编号小于N的请求
- accept 阶段
- 若 Proposer 收到过半 Acceptor 对 Prepare(N) 返回的ACK响应,那么它会从响应的提案中选出编号最大的一个(acceptN, acceptV), 若响应中不包含提案则由 Proposer 决定提案。决定提案后 Proposer 会向过半 Acceptor 发送 Accept(N, V)请求。
- Acceptor 收到 Accept(N, V) 请求后
- 若 maxN > N, 那么 Acceptor 返回拒绝响应
- 若 maxN < N, 那么 Acceptor 返回成功响应,并更新已接受的编号最大提案 (acceptedN, acceptedV)
- 若 Proposer 未收到过半 Acceptor 对 Accept(N, V) 请求的成功响应,则认为提案被拒绝。
若集群中存在两个 Proposer 依次提出编号递增的提案可能会使 Paxos 算法陷入死循环:
- Proposer1 提出提案 N1, 并收到过半Prepare(N1)响应
- Proposer2 提出提案 N2 (N2 > N1), 并收到过半Prepare(N2)响应
- Proposer1 进入第二阶段, 过半Accept(N1)请求被拒绝 (过半Acceptor 的 maxN = N2)。 Proposer1 提出提案 N3 (N3 > N2) ...
这种情况称为算法陷入活锁,在工程实践中我们通常选择一个 Proposer 作为 leader。
Paxos 算法可以在数学上证明它的正确性深入浅出Paxos算法协议。
Paxos 算法实现难度和运行开销非常大,因此开发出 Raft、ZAB等协议用于生产实践。
从2PC到Paxos的更多相关文章
- 分布式:2PC,3PC,Paxos,Raft,ISR [转]
本文主要讲述2PC及3PC,以及Paxos以及Raft协议. 两类一致性(操作原子性与副本一致性) 2PC协议用于保证属于多个数据分片上的操作的原子性.这些数据分片可能分布在不同的服务器上,2PC协议 ...
- 2PC/3PC/Paxos
在分布式系统中,一个事务可能涉及到集群中的多个节点.单个节点很容易知道自己执行的事务成功还是失败,但因为网络不可靠难以了解其它节点的执行状态(可能事务执行成功但网络访问超时). 若部分节点事务执行失败 ...
- 分布式一致性算法 2PC 3PC Paxos
分布式一致性算法的目的是为了解决分布式系统 一致性算法可以通过共享内存(需要锁)或者消息传递实现,本文讨论后者实现的一致性算法,不仅仅是分布式系统中,凡是多个过程需要达成某种一致的场合都可以使用. 本 ...
- 【转】PaxosLease算法--2PC看Paxos选主
原文请参考[[置顶] Paxos master选举--PaxosLease算法] 众所周知,为了避免Paxos算法的活锁问题,必须选举唯一的proposor.偏偏在Paxos原论文中,作者L. Lam ...
- [转载] 一篇文章带你了解Paxos算法
原文: http://dockone.io/article/640 [编者的话]本文是Quora上关于Paxos算法的回答,两位答者分别从不同的角度描述Paxos算法.Vineet Gupta的回答细 ...
- Paxos 学习总结
近期学习了分布式领域的重要算法Paxos,这里罗列下关键点当作总结.自己水平有限,难免存在谬误,恳请读者指正.本篇不包含Paxos的基本理论介绍.Paxos基础能够參考以下的学习资料章节. 1 Pax ...
- Paxos算法与Zookeeper分析,zab (zk)raft协议(etcd) 8. 与Galera及MySQL Group replication的比较
mit 分布式论文集 https://github.com/feixiao/Distributed-Systems wiki上描述的几种都明白了就出师了 raft 和 zab 是类似的,都是1.先选举 ...
- NoSQL数据库笔谈(转)
NoSQL数据库笔谈 databases , appdir , node , paper颜开 , v0.2 , 2010.2 序 思想篇 CAP 最终一致性 变体 BASE 其他 I/O的五分钟法则 ...
- web技术人员-推荐书籍
学习是技术人员成长的基础,本次分享20本技术方面的书籍,这些书不是每一本都是经典,但是每一本都有其特点.以下20本大部分本人都看过,因此推荐给大家.(本次推荐的20本只是一个参考,比如像Head Fi ...
随机推荐
- maple推导剑桥模型塑性势函数
with(DEtools); Parameter(M); de := diff(q(p), p)+(M^*p^-q(p)^)/(*p*q(p)) = ; dsolve({de, q(px) = }, ...
- react-eslintrc
{ "extends": ["eslint:recommended"], "plugins": [ "react" ], ...
- C++代码审查---审查孙晓宁马踏棋盘谜题程序
与孙晓宁同学结对审查,其代码地址如下:https://github.com/brunnhilder/-1/blob/master/%E9%A9%AC%E8%B8%8F%E6%A3%8B%E7%9B%9 ...
- POJ2391 Ombrophobic Bovines
Ombrophobic Bovines Time Limit: 1000MS Memory Limit: 65536K Total Submissions: 19359 Accepted: 4 ...
- 我的C#跨平台之旅(一):从 Hello World 开始
创建一个“控制台应用程序”,目标框架为“.NET Framework 4.5”,并移除无关的文件及引用,仅保留对 “system.dll”的引用:其中工程文件中核心内容如下: 使用NuGet添加如下引 ...
- java 判断用户是PC端和还是APP端登陆
java 判断用户是PC端和还是APP端登陆 public void getRequestHeader(HttpServletRequest request){ // 从浏览器获取请求头信息 Stri ...
- Python之旅Day12 HTML与CSS
前端CSS与HTML部分 <a href="http://www.baidu.com" target="_Blank">百度</a>_B ...
- Kali学习笔记18:OpenVAS使用
上一篇讲了什么是OpenVAS以及如何安装: https://www.cnblogs.com/xuyiqing/p/9690373.html 接下来就是使用: 我先打开一台Metasploitable ...
- Apache Lucene全局搜索引擎入门教程
Lucene简介 Lucent:Apache软件基金会Jakarta项目组的一个子项目,Lucene提供了一个简单却强大的应用程式接口,能够做全文索引和搜寻.在Java开发环境里Lucene是一个成熟 ...
- linux上安装jdk环境
只在于安装jdk1.6.jdk1.7和jdk1.8,其他版本请绕行,目的在于方便自己和大家以后急于做jdk环境,苦于没有jdk安装包和设置变量的过程,我将安装包均放在云盘中, 需要直接在连接中找即可: ...