分布式一致性协议

主要介绍分布式一致性协议Paxos

主要内容：

1. Paxos协议

1.1. Paxos协议的角色

1.2. 分布式一致性协议的原则

1.3. 提案的选定条件

1.4. 提案的生成与批准

2. Zab协议

Paxos协议

paxos协议是一种基于消息传递的且具有高度容错特性的分布式一致性协议，是目前公认的解决分布式一致性问题的最有效的算法之一。paxos协议是用来解决在一个可能会发生机器宕机或者网络异常的分布式系统中，快速正确的保证集群内部对某个数据的值达成一致。

paxos的角色

1. Proposer：提议者
2. Accpeteor：决策者
3. Learner：组中决策的学习者
4. Client：产生议题者

上面的4中角色中，Proposer和Accpeteor是最重要的，其他的两个角色在整个算法中应该算是打酱油的存在，Proposer就像是Client的使者，由Proposer拿着Client的议题去向Acceptor提议，让Acceptor来做决策。

分布式一致性协议的原则

1. 安全原则
   只有被提出的提案才能被选定；
   只有一个提案的值会被选定；
   如果某个进程认为一个提案被选定了，那么这个提案就应该是真的被选定的那个
2. 存活原则，只要有多数的服务器存活，并且彼此之间可以相互通信，那么就可以做到：
   最终会批准某个被提出的提案；
   一个值如果被批准了，那么其他服务器最终会学会这个值

提案的选定条件

1. 要选定一个唯一提案最简单的办法就是只有一个Acceptor，这样的话所有的Proposer只能发送提案给该Acceptor，Acceptor会选择它收到的第一个提案作为被选定的提案。
   

这种方式实现起来比较简单，但是存在非常严重的单点问题，一旦这个Acceptor出现问题，那么整个系统就没法继续工作下去。因此可以使用多个Acceptor来避免单点问题。

每次Proposer会将提案发送给一个Acceptor集合，当这个Acceptor集合中有过半的Acceptor批准这个提案，那么我们就认为这个提案被批准了。

要满足存活性的要求:最终会批准某个被提出的提案，那么就必须有这样的一个条件成成立：

p1: 一个Acceptor必须批准它收到的第一个提案

但是这个条件又引出另一个问题，如果多个提案被不同的Proposer提出，所有的Acceptor都批准它收到的第一个提案，但是最终没有一个提案是被过半的Acceptor批准，那么这时候也没办法选择一个被批准的提案。

在条件p1的基础上，需要加上一个条件：每个Acceptor必须能够批准不止一个提案。在这里，我们使用一个全局唯一的编号来标识每个被Acceptor批准的提案，当一个具有某个value值的提案被过半的Acceptor批准了，那么我们就认为这个value被选定了，同时也认为这个提案被选定了。这里，我们用[编号，value]来表示一个提案。虽然允许多个提案被选定，但是这个提案必须具有相同的value值，这是一个关于提案value的约定，因此有如下的条件：

p2: 如果提案[M0，value]被过半的>Acceptor选定了，那么所有被选定的提案[Mi,value1],只要Mi>M0,那么就一定有value1==value成立。

又因为提案[M0，value]被批准是被选定的前提，因此上述的条件p2可以进一步描述为：

p2a: 如果提案[M0，value]被过半的>Acceptor选定了，那么所有被Acceptor批准的提案[Mi,value1],只要Mi>M0,那么就一定有value1==value成立。

基于上面的条件，但是由于网络通信是异步的，比如现在系统中有Acceptor1，Acceptor2，Acceptor3，以及Proposer1，Proposer2，当前Proposer1提出一个提案[m1,v1]，发送给{Acceptor1，Acceptor2}，并且被批准了，因此提案[m1,v1]是被选定的提案。这时，Proposer2提出了一个提案[m2,v2],发送给{Acceptor3}，根据条件p1，Acceptor3必须要批准这个提案，但是根据p2a，v2必须等于v1，这是很难保证的，就会产生冲突。因此，需要进一步将p2a进行条件加强。

p2b: 如果提案[M0，value]被过半的Acceptor选定了，那么今后所有被提出的提案[Mi,valuei],只要Mi>M0,肯定有valuei==value0成立。

之所以会有条件p2b，是因为一个提案只有被提出后才有可能会被批准。接下来我们就需要去证明p2b成立即可。要证明p2b成立，还需要一个额外的不变性条件：

p2c: 如果提案[Mn，Vn]能被提出，那么肯定存在一个由半数以上的Acceptor组成的集合C，满足以下条件：

1. 如果之前没有提案被选定的话，C中不存在任何Acceptor批准过编号小于Mn的提案；
   
2. 如果之前有提案被选定了，那么C中所有Acceptor批准过的提案中，编号小于Mn的提案的最大值一定是Vn；
3. 基于p2c来证明p2b就显而易见了。数学归纳法证明：提案[M0，V0]被选定了，那么后续被提出的任意提案[Mn,Vn]，都有Vn==V0.
   
4. 证明[M1，V1]被提出，那么V1==V0：因为[M0，V0]已经被选定了，那么根据p2c，就一定存在一个过半数的集合C，C的所有的Acceptor批准的提案中编号最大的那个提案一定是[M0，V0],因为此时M0就比M1小1，并且这个提案的值一定要是V1，所有V1==V0，p2b的初始条件得证；
   
5. 假设提案[M2,V2]~[Mn-1m,Vn-1]都满足p2b；
   
6. 证明当提案[Mn,Vn]被提出，必然后Vn==V0：根据p2c，必然存在一个集合C，集合C的所有的Acceptor批准的提案中，编号最大并且小于Mn的那个提案一定是[M2,V2]~[Mn-1m,Vn-1]中的任意一个，这个提案的Value一定等于V0，在上面已经证明了，那么必然有Vn==V0，所以p2b得证。

提案的生成

这部分主要介绍Proposer是如何进行提案生成的

1. 提案的生成主要是基于条件p2c进行的。对一个Proposer而言，要产生一个编号为Mn的提案，它必须要知道当前某一个被过半的Acceptor批准的，并且编号最大的提案；并且，Proposer会要求所有的Acceptor都不再批准任何编号小于Mn的提案。提案生成算法如下：
   

   1. Proposer选择一个新的提案编号Mn(这个编号的生成是有一定机制保证的),然后向某个Acceptor集合发送请求，要求该集合中的成员做出如下回应：
      1.1. 向Proposer承诺不再批准任何编号小于Mn的提案；
      1.2. 如果Acceptor批准过某些提案，那么需要向Proposer反馈当前该Acceptor批准过的提案的中编号小于Mn，且编号最大的编号的value值
      
   2. 如果Proposer收到来自半数的Acceptor响应的结果，那么它就会产生一个提案[Mn,Vn]，这里的Vn是所有响应中编号最大的那个提案的value值。如果半数以上的Acceptor都没有批准过任何提案，那么这个value值就可以是Proposer任意指定的。
      
   3. 确定提案[Mn,Vn]之后，Proposer就会把该提案再次发送给某个Acceptor集合，期望获得他们的批准。

   
   

   这部分主要介绍Acceptor是如何批准提案的

1. Acceptor接受来自Proposer的请求分为prepare请求和accept请求两种。
2. Acceptor在处理accept请求的处理逻辑非常简单：只要它没有响应过编号大于Mn的prepare请求，那么它就可以批准这个编号Mn的提案。

这部分总结一下整个提案批准算法的流程，类似一个2PC

阶段一：

1. Proposer选择一个编号为Mn的提案，向一个Acceptor集合C发送一个prepare请求；
2. 如果集合C的Acceptor收到这个编号为Mn的prepare请求，且Acceptor没有相应过任何编号大于Mn的提案的prepare请求，那么Acceptor就会将它已经批准过的最大编号的提案作为响应回送给Proposer，同时该Acceptor会承诺不再批准任何编号小于Mn的提案。举个例子，如果一个Acceptor已经响应的所有prepare请求对应的提案编号为1，2，3，6，那么在该Acceptor接受到一个编号为7的提案的prepare请求时，它会将6对应的提案回送给Proposer；如果收到的是编号为5的提案的prepare请求，那么它会忽略这样的请求；

阶段二：

1. 如果Proposer收到来自半数的Acceptor响应的结果，那么它就会产生一个提案[Mn,Vn]，这里的Vn是所有响应中编号最大的那个提案的value值。如果半数以上的Acceptor都没有批准过任何提案，那么这个value值就可以是Proposer任意指定的；
2. Acceptor在收到这个accept请求时，只要它没有响应过编号大于Mn的prepare请求，那么它就可以批准这个编号Mn的提案。

未完待续～

zab协议明天更新