Zookeeper研究系列之二阶段提交到Paoxs协议到ZAB协议的演进

要解决的问题：分布式数据一致性(当客户端发起写入数据请求时，各个节点的数据保持一致)

两阶段提交

存在的问题：

1. 同步阻塞： 协调者发起命令后只能无限等待参与者响应
2. 单点问题：协调者宕机则整个集群不可用
3. 脑裂问题：网络分化后，导致部门节点提交成功，部分节点失败，造成数据不一致

 

Paoxs协议

问题背景：假设我们有下图的系统，想要在server1，server2，server3选一个master。

prepare阶段 
  1. 每个server向proposer发送消息，表示自己要当leader，假设proposer收到消息的时间不一样，顺序是： proposer2 -> proposer1 -> proposer3，消息编号依次为1、2、3。 
  紧接着，proposer将消息发给acceptor中超过半数的子成员(这里选择两个)，如图所示，proposer2向acceptor2和acceptor3发送编号为1的消息，proposer1向acceptor1和accepto2发送编号为2的消息，proposer3向acceptor2和acceptor3发送编号为3的消息。 
   2. 假设这时proposer1发送的消息先到达acceptor1和acceptor2，它们都没有接收过请求，所以接收该请求并返回【pok，null，null】给proposer1，同时acceptor1和acceptor2承诺不再接受编号小于2的请求； 
  紧接着，proposer2的消息到达acceptor2和acceptor3，acceptor3没有接受过请求，所以返回proposer2 【pok，null，null】，acceptor3并承诺不再接受编号小于1的消息。而acceptor2已经接受proposer1的请求并承诺不再接收编号小于2的请求，所以acceptor2拒绝proposer2的请求； 
  最后，proposer3的消息到达acceptor2和acceptor3，它们都接受过提议，但编号3的消息大于acceptor2已接受的2和acceptor3已接受的1，所以他们都接受该提议，并返回proposer3 【pok，null，null】； 
  此时，proposer2没有收到过半的回复，所以重新取得编号4，并发送给acceptor2和acceptor3，此时编号4大于它们已接受的提案编号3，所以接受该提案，并返回proposer2 【pok，null，null】。

accept阶段 
1 
  Proposer3收到半数以上（两个）的回复，并且返回的value为null，所以，proposer3提交了【3，server3】的提案。 
  Proposer1也收到过半回复，返回的value为null，所以proposer1提交了【2，server1】的提案。 
  Proposer2也收到过半回复，返回的value为null，所以proposer2提交了【4，server2】的提案。 

   （这里要注意，并不是所有的proposer都达到过半了才进行第二阶段，这里只是一种特殊情况）
2 
  Acceptor1和acceptor2接收到proposer1的提案【2，server1】，acceptor1通过该请求，acceptor2承诺不再接受编号小于4的提案，所以拒绝； 
  Acceptor2和acceptor3接收到proposer2的提案【4，server2】，都通过该提案； 
  Acceptor2和acceptor3接收到proposer3的提案【3，server3】，它们都承诺不再接受编号小于4的提案，所以都拒绝。

所以proposer1和proposer3会再次进入第一阶段，但这时候 Acceptor2和acceptor3已经通过了提案（AcceptN = 4，AcceptV=server2），并达成了多数，所以proposer会递增提案编号，并最终改变其值为server2。最后所有的proposer都肯定会达成一致，这就迅速的达成了一致。
原文链接：https://blog.csdn.net/u013679744/article/details/79222103

存在问题:

1. 活锁问题：假如提案者1因为不能获得过半响应而将自己的编号变为maxN+1=3，而此时提案者2的提案号是2<3,因此也会将自己的编号maxN+1=4,and so on， 造成活锁问题

ZAB协议

广播模式

无历史数据时，选举leader

有历史数据，则按照zxid, myid 顺序选择最大的节点