Zookeeper Paxos算法 一致性协议

前言

Paxos 一致性协议可以说是一致性协议研究的起点,也以难以理解闻名。其实协议本身并没有多难理解,它的难理解性主要体现在:为何如此设计协议以及如何证明其正确性。本文尝试通过流程图来说明协议的内容以及基本应用过程,不涉及如何证明其正确性。

基本概念

Paxos 可以分为两种:

  • Single-Decree Paxos:决策单个 Value
  • Multi-Paxos:连续决策多个 Value,并且保证每个节点上的顺序完全一致,多 Paxos 往往是同事运行多个单 Paxos 协议共同执行的结果。

本文只关注单 Paxos 的原理,理解了单 Paxos,多 Paxos 也就不难理解了。

Paxos 协议中的三种角色

  • 倡议者(Proposer):倡议者可以提出提议(数值或者操作命令)以供投票表决
  • 接受者(Acceptor):接受者可以对倡议者提出的提议进行投票表决,提议有超半数的接受者投票即被选中
  • 学习者(Learner):学习者无投票权,只是从接受者那里获知哪个提议被选中

在协议中,每个节点可以同时扮演以上多个角色。

Paxos 的特点

  • 一个或多个节点可以提出提议
  • 系统必须针对所有提案中的某个提案达成一致(超过半数的接受者选中)
  • 最多只能对一个确定的提议达成一致
  • 只要超半数的节点存活且可互相通信,整个系统一定能达成一致状态,即选择一个确定的提议

协议图示

 


通过上面的流程,如果有多个节点同时提出各自的提议,Paxos 就可以保证从中选出一个唯一确定的值,保证分布式系统的一致性。

实例

下面我们通过例子来理解 Paxos 的实际应用过程。

假设现在有五个节点的分布式系统,此时 A 节点打算提议 X 值,E 节点打算提议 Y 值,其他节点没有提议。

假设现在 A 节点广播它的提议(也会发送给自己),由于网络延迟的原因,只有 A,B,C 节点收到了。注意即使 A,E 节点的提议同时到达某个节点,它也必然有个先后处理的顺序,这里的“同时”不是真正意义上的“同时”。

A,B,C接收提议之后,由于这是第一个它们接收到的提议,acceptedProposal 和 acceptedValue 都为空。

由于 A 节点已经收到超半数的节点响应,且返回的acceptedValue 都为空,也就是说它可以用 X 作为提议的值来发生 Accept 请求,A,B,C接收到请求之后,将 acceptedValue 更新为 X。

A,B,C 会发生 minProposal 给 A,A 检查发现没有大于 1 的 minProposal 出现,此时 X 已经被选中。等等,我们是不是忘了D,E节点?它们的 acceptedValue 并不是 X,系统还处于不一致状态。至此,Paxos 过程还没有结束,我们继续看。

此时 E 节点选择 Proposal ID 为 2 发送 Prepare 请求,结果就和上面不一样了,因为 C 节点已经接受了 A 节点的提议,它不会三心二意,所以就告诉 E 节点它的选择,E 节点也很绅士,既然 C 选择了 A 的提议,那我也选它吧。于是,E 发起 Accept 请求,使用 X 作为提议值,至此,整个分布式系统达成了一致,大家都选择了 X。

以上内容均引用自: http://blog.jobbole.com/106327/

感谢作者画图解说如上的paxos算法

 

 

原设计师的最先设计方案:

上图的图解,缺了一部分同步的操作,当然不是作者画错了,而是我们的分布式发现服务的问题,当一个节点不可用,那么发起议案的时候,节点不可用,那么提交议案成功后,也不会去再同步此节点,因为不可用。

交叉分布式事务

下图将解说交叉分布式同步问题,下图将采用的另一个收费课程的图解:更复杂!!!!

模拟场景:战略会议       交叉分布式事务

制定作战计划,两位作战计划的制定者,分别制定一个计划,上面的进攻时间改为进攻目标更妥当

三位将军作为计划的执行者。

开始:

1:参谋1  制定作战目标成功,发送给三个将军。但是将军3与他有意见,拒绝他的意见,此时的将军1,将军2,觉得作战目标可行。同意

2:在参谋1还没做表决的时候,参谋2,将作战目标做完,分别发给三位将军,这时将军1跟参谋2有意见,不接受他的作战目标。其他两个将军觉得作战目标可行,同意

3:这是参谋1 举行表决,超过半数即可行。将军2 将军1 做表决,但是将军2接受了新的作战计划,此时不再能执行作战计划1了,所以参谋一的作战计划未通过

4:此时参谋2开始做作战计划的表决,因为将军2 将军3 同意,因此此计划通过。这时其实意味这分布式事务的成功,数据一致性处理成功

5:此时参谋1 又做了一个作战计划,3 发给将军1,将军2,此时将军1,2返回他们手里的作战计划,看是否领先作战计划3。

6:参谋1发现将军1,将军2 的作战计划已执行,可以表决自己的作战计划,则提交表决

7:将军1 将军2 表决通过参谋1的作战计划3

 

哈哈,懵了没有,其实这模拟的是:

    如淘宝交易,同一时间两个会员购买同一个商品 第一个会员需要去修改淘宝的分布式系统的商品剩余数量,此时第二位会员同时间消费的会员也要来修改数据。时间在0.00毫秒间产生。交叉型的分布式事务处理出现在超大型并发系统中。这时两个会员会出现争夺谁先去修改库存的操作。

    看得懂的行家可能会说,在参谋2提交计划成功的时候,参谋1又提交议案,就造成了死锁了。Paxos算法在提交失败后,睡眠1毫秒参谋2的提议就表决通过了。当然算法内还有更深层次的实现,无法得知:,目前 Google Facebook IBM 都有自己的算法实现,可是都没有公开源码,zookeeper的实现源码好像说也很晦涩。但是算法内部用队列或者一些简单的类似MQ处理机制就可以避免上面这种彼此死锁的方式。

 

 

 

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值