basic paxos协议——分布式一致性协议初探

1、什么是paxos协议？

定义：Paxos算法是在多个成员之间对某个值（提议）达成一致的协议。这个值可以是任何东西。比如多个成员之间进行选主，那么这个值就是主的身份。在应用到日志同步中时，这个值就是一条日志。通过多次Paxos的执行就可确定出一个日志的序列，保证在主备服务器上看到相同的日志顺序。

前提：Paxos算法假设不存在拜占庭问题，也就是说消息的传递可能丢失，迟到或者重复，但是一定不会被篡改。

拓展：Paxos算法有很多变种，旨在提高共识收敛速度、减少通信延迟或减少磁盘IO次数，典型的包括Multi-Paxos、Fast Paxos、Generalized Paxos等

思考：为什么需要paxos协议？为什么不直接统计投票，得票最多的值得选？

我们日常中最常见的表决方式就是投票，得到选票数最多的值为决议结果，那么为什么在分布式系统中不使用这种简单的方法呢，主要有两个原因：

• 一个是没有组织者。也就是说没有一个leader节点来发起投票，多个（甚至所有）的节点都觉得自己是leader节点，都要发起投票，那不是乱套了。
• 二个是不知道投票选项。因为节点间相互没有通信，所以根本不知道有哪些选项，这样是没有办法进行投票的（就像着急一群不认识的人来选举主席，但是大家相互不认识，也不告诉大家有哪些人参与选举，总不能随便写个名字就交上去，因为很可能乱写的名字根本没有这个人）。而paxos协议的准备阶段解决了第二个问题。

2、Paxos算法流程

paxos协议的决议形成需要两个阶段：准备阶段、决议阶段

我们将使用一个具体的集群选主的例子来描述paxos算法的流程：

（1）准备阶段

发送proposal请求，不带具体提案值。目的是收集其它节点的意见并得到自己的提案值，也就是确定本轮paxos算法要表决的提案。

•   每个proposer发送的proposal消息包含自己的提案编号（唯一，随时间递增）
•   接收的回复消息包含自己已经参与表决的提案编号和提案值[round，value]，如果之前没有参与过，那么返回[round，null]
•   对于发起者proposer来说，如果收到的所有消息的value都为null，那么在接下来的决议阶段提案值为自己，否则提案值为准备阶段收到的消息中round最大的消息对应的value（即参考文献中的maxVote值）

我们假设在一个分布式集群中有3个sever，我们需要在其中选一个作为leader，因此3个server分别作为proposer发出proposal请求：而3个server发起proposal的时间稍微存在差异，这里proposer2最先（假设在3:01），proposer1其次（3:02），proposer3最后（3:03），我们根据发起时间给每个proposal请求分配提案号（round），可以得到proposer2的提案号为1，proposer1的提案号为2，proposer3的提案号为3，如下图所示，我们把proposal请求简称为P1（P2，P3），这里的proposal请求的内容包含的就是提案号（round），比如说“你好，我的提案号是1，请问你有什么想法”。

如下图所示，P1请求发送给accepter1、2（最先达到），P2请求发送给accepter2、3（其次到达），P3请求发送给accepter2、3（最后到达）。

那么接下来我们对准备阶段的流程进行模拟，最后可以得到各个proposer的最终提案值：

（2）决议阶段

发送accept请求，携带具体的提案值。目的是告诉集群自己的提案，并由决议算法得到最后的决议。在决议阶段会继续使用准备阶段的accept的情况，并且一个节点始终都只能支持一个提案，因此，在决议阶段一定会有且只有一个超过半数的提案被作为决议，保证一致性。

•   每个proposer发送自己的提案号和最终的提案值[round，value]给各个accepter
•   每个accepter将收到的消息提案号与自己在准备阶段的意向比较，如果收到的提案号大于之前的意向提案号，则接受提案，否则拒绝
•   选择支持数过半的提案作为最后的决议

对准备阶段得到的提案值进行决议流程的模拟，得到最终的决议值[4，S2]：

1. Acceptor1、Acceptor2接收到Proposer1的提案[2,server1]请求，Acceptor2承诺编号大于4所以拒绝了通过，Acceptor1通过了请求；

2. Proposer2的提案[4,server2]发送到了Acceptor2、Acceptor3，提案编号为4所以Acceptor2、Acceptor3都通过了提案请求；

3. Acceptor2、Acceptor3接收到Proposer3的提案[3,server3]请求，Acceptor2、Acceptor3承诺编号大于4所以拒绝了提案；

4. 此时过半的Acceptor都接受了Proposer2的提案[4,server2],Larner感知到了提案的通过，Larner学习提案，server2成为Leader；

发布决议

而在决议形成后，要实现分布式系统的最终一致性，还需要将决议分发布给分布式系统中的learner节点，也就是说我们可以认为一次分布式系统的最终一致性结果可以分为三个步骤：

• 一个显而易见的方法是当acceptors批准一个value时，将这个消息发送给所有learner。但是这个方法会导致消息量过大。
• 由于假设没有拜占庭问题，也就是消息不会被篡改，learners可以通过别的learners获取已经通过的决议。因此acceptors只需将批准的消息发送给指定的某一个learner，其他learners向它询问已经通过的决议。这个方法降低了消息量，但是指定learner失效将引起系统失效。
• 因此acceptors需要将accept消息发送给learners的一个子集，然后由这些learners去通知所有learners。但是由于消息传递的不确定性，可能会没有任何learner获得了决议批准的消息。当learners需要了解决议通过情况时，可以让一个proposer重新进行一次提案。注意一个learner可能兼任proposer

经过以上步骤，就可以将一个值（决议）一致地放到分布式系统的各个节点中。

 

参考文章：

paxos算法流程：https://blog.csdn.net/steven_change/article/details/79875227

https://segmentfault.com/a/1190000005717258#articleHeader7

maxVote值的选取：https://blog.csdn.net/feng12345zi/article/details/79653996

对paxos的理解：http://www.sohu.com/a/146811077_575744

paxos算法证明：https://www.jianshu.com/p/fbda069a282d