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处理机制就可以避免上面这种彼此死锁的方式。