paxos协议

前言

想理解paxos得先知道paxos解决的问题是什么。paxos解决的是2PC，3PC存在的节点阻塞，脑裂，低容错性，单点问题。而且还能做到2PC，3PC不能做到的事，master选举。3PC是主从结构，如果主节点崩溃了，3PC并没有提供master选举的算法。

推荐资料：

• lamport老爷子写的论文Paxos Made Simple
• 《从paxos到zookeeper》
• 分布式系统入门

问题定义

假设有一系列proposer可以发起关于proposal（比如竞选master），一个共识算法保证只有一个值最终被chose(即一个proposal被多数acceptor通过)。
算法的safety定义如下：

• 被chose的值必须来自于某一个提案
• 最终只有一个proposal被chose
• 只有最终被chose的提案才会被learner学习到

paxos是分布式系统下的具有容错性的共识算法。它的目的是在一个没有拜占庭问题的异步系统中，达成共识，最终chose一个proposal
这个模型有如下假设：

• 节点以任意速度执行，可以宕机，重启。
• 节点间消息传输时间没有上界，消息可能丢失，重复，但是不会被篡改
• 系统没有全局时钟

paxos算法推理过程：

paoxos是根据safety的三条规则不断加强约束得到的，特别是第二条。
最简单的方式就是一个proposer，acceptor直接通过proposal就OK了，我们假设只有一个proposal，则可以得到约束P1

P1 ：acceptor必须通过第一个收到的proposal

这样当然是不行的，存在单点问题。实际上存在一系列proposer和acceptor。并发的情况下不同的proposer如果提出不同的提案，根据P1，这会导致系统无法达成一致。因此我们需要给每个提案加编编不同的号（相当于排序），定义proposal(n,v)。n为编号（标识proposal的顺序)，v为value，要保证acceptor最终只chose一个proposal，则必须有以下约束：

P2:如果提案 (n,v)已经被chose，每一个更高编号的提案必须包含v才能被chose

继续则可以推出P2a:

P2a:如果提案 (n,v)已经被chose，每一个更高编号的提案必须包含v才会被acceptor通过

我们如何能够维持P2a了，于是有了更强的约束

P2b:如果提案 (n,v)已经被chose, 每个发起的更高编号的提案必须包含v

P2b -> P2a -> P2
如何能过实现P2b呢，可以使用一个更强的约束P2c

P2c: 对于所有n,v,如果一个提案(n,v)被发起,必然存在一个有大多数 acceptor组成的集合满足以下两个条件之一：
 (a) S中没有任何acceptor通过编号小于n的提案 
 (b) v 是所有acceptor都通过的编号小于n的最大编号的提案的值

取编号小于n的最大编号的提案的值是一个很巧妙的技巧，可以使得两个分区恢复之后丢弃旧值达成一致。

paxos算法

• 阶段1:

  • 提案者获取一个编号n，向超过一半的acceptor 发起 prepare request，请求通过的最大编号的提案，如果有的话并要求acceptor承诺不再通过编号小于n的提案

  • 对于每个acceptor， 如果n大于已经响应的prepare编号的最大值 ，返回已经通过的最大的提案的value(如果有的话)，并且承诺不会再接受任何编号小于n的提案；否则不响应

• 阶段2：

  • 提案者如何收到大多数的acceptor的响应，则向其中每一个acceptor发起 accept request, 请求通过提案(n,v), v是返回的最大编号提案的值，如果没有的话可以时任意值
  • 对于每个accept request， 如果其编号n等于acceptor最大的响应的prepare请求的提案编号，则通过，否则不响应

这里其实存在一个很小概率的无限循环：假设两个proposer p1 , p2分别提案, 提案编号分别是n1,n2，且n1 < n2, 假设p1和p2都进入了阶段2， 则p1在阶段2发起的请求不会被通过。n1继续增加提案编号n3, n3 > n2, 如何n3很快进入阶段2，则p2阶段2又不会通过。
为了避免这个小概率事件，实际上都会先选举一个proposer类似于master。定时检测住proposer是否挂了，挂了的话重新选举。像Google的Chubby，Zookeeper（基于ZAB协议，和paxos类似）都是这样。

总结

paxos vs 3PC:

3PC协调者需要所有的参与者事物都执行成功，只要有一个参与者不成功就回滚。和3PC相比，paxos执行事物的时候只需要大多数执行成功就行了，这样是可以保证最终一致性的，而且性能高了太多，不需要所有参与者都阻塞在那。
paxos的fault tolerant体现在：

• 任何阶段如果proposer没有到acceptor的响应则认为是不通过，而且结果依然正确。
• 任何时候proposer都可以放弃发起提案，结果仍然正确
• 就算proposer挂了，其他节点依然可以运用paxos算法选择新的proposer。

paxos vs raft

paxos只是提了一个理论，但是这个理论抽象度太高，而且没有说明具体的使用场景以及最佳实践，所以不同的使用到的地方都不一样，比如chubby，zookeeper，最终实现都不一样。实现一致性算法的系统。 Chubby 和 Spanner 的算法并没有公开发表其技术细节，尽管他们都声称是基于 Paxos 的。ZooKeeper 的算法细节已经发表，但是和 Paxos 有着很大的差别。paxos不易理解而且对于如何使用paxos构建系统没有理论指导。因此出现了raft。看raft之前，我自己想怎么构建一个分布式系统的时候也是觉得先选一个leader比较好。raft将分布式系统的各个组成部分结构，详细的说每一步的协议。非常清晰，看完raft论文感觉自己都能上手写一个简单的分布式系统了。而paxos看完之后感觉很难运用。