zookeeper学习记录-02一致性协议

前言

在对一个分布式系统进行架构设计的过程中，往往会在系统的可用性和数据一致性之间进行反复权衡，于是就产生了一系列的一致性协议，在长期的探索研究过程中，涌现了一大批经典的一致性协议算法，其中最著名的就是二阶段提交协议(2PC),三阶段提交协议(3PC)和Paxos算法

我: 老王，今晚7点老地方，搓够48圈不见不散！
……
（第二天凌晨3点） 隔壁老王: 没问题！       // 消息延迟
我: ……
----------------------------------------------
我: 小张，今晚7点老地方，搓够48圈不见不散！
小张: No ……                           
（两小时后……）
小张: No problem！                     // 宕机节点恢复
我: ……
-----------------------------------------------
我: 老李头，今晚7点老地方，搓够48圈不见不散！
老李: 必须的，大保健走起！               // 拜占庭将军
（这是要打麻将呢？还是要大保健？还是一边打麻将一边大保健……）

2PC与3PC

在分布式系统中，每一个机器节点虽然能够明确知道自己在进行事务操作过程中的结果是成功或是失败，但是却无法直接获取到其他分布式节点的操作结果，因此，当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的ACID的特性，需要引入协调者的组件来统一调度所有分布式节点的执行逻辑，而被调度的节点则被称为参与者，协调者负责调度参与者的行为并最终决定这些参与者是否要把事务真正进行提交，基于这个思想，衍生出了二阶段提交和三阶段提交两种协议。

2PC

2PC为Two-Phase Commit的简写，为二阶段提交协议将事务的提交过程分成了两个阶段来进行处理，并执行如下流程：

　　阶段一：提交事务请求

　　① 事务询问，协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

　　② 执行事务，各参与者节点执行事务操作（已经执行），并将Undo和Redo信息记入事务日志中。

　　③ 各参与者向协调者反馈事务询问的响应，如果参与者成功执行了事务操作，那么就反馈给协调者Yes响应，表示事务可以执行；如果参与者没有成功执行事务，那么就反馈给协调者No响应，表示事务不可以执行。

　　第一阶段近似于是协调者组织各参与者对一次事务操作的投票表态的过程，因此二阶段提交协议的阶段一也被称为投票阶段。

　　阶段二：执行事务提交

　　协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作，正常情况包含如下两种可能：

　　1. 执行事务提交，假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务提交。

　　① 发送提交请求，协调者向所有参与者节点发出Commit请求。

　　② 事务提交，参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。

　　③ 反馈事务提交结果，参与者在完成事务提交之后，向协调者发送Ack消息。

　　④ 完成事务，协调者接收到所有参与者反馈的Ack消息后，完成事务。

　　2. 中断事务，假如任意一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到参与者的反馈响应，就会中断事务。

　　① 发送回滚请求，协调者向所有参与者节点发出Rollback请求。

　　② 事务回滚，参与者接收到Rollback请求后，会利用其在阶段一中记录的Undo信息来执行事务回滚，并在完成回滚之后释放在整个事务执行期间占用的资源。

　　③ 反馈事务回滚结果，参与者在完成事务回滚后，向协调者发送Ack消息。

　　④ 中断事务，协调者接收所有参与者反馈的Ack消息后，完成事务中断。

　　二阶段提交协议的优点：原理简单，实现方便。缺点：同步阻塞，单点问题，数据不一致，太过保守。

　　同步阻塞：在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，即当参与者占有公共资源时，其他节点访问公共资源不得不处于阻塞状态。

　　单点问题：若协调器出现问题，那么整个二阶段提交流程将无法运转，若协调者是在阶段二中出现问题时，那么其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成事务操作。

　　数据不一致：在二阶段的阶段二，执行事务提交的时候，当协调者向所有的参与者发送Commit请求之后，发生了局部网络异常或者是协调者在尚未发送完Commit请求之前自身发生了崩溃，导致最终只有部分参与者收到了Commit请求，于是会出现数据不一致的现象。

　　太过保守：在进行事务提交询问的过程中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，此时协调者只能依靠自身的超时机制来判断是否需要中断事务，这样的策略过于保守，即没有完善的容错机制，任意一个结点的失败都会导致整个事务的失败。

3PC

三阶段提交，将二阶段提交协议的提交事务请求过程分为CanCommit、PreCommit、doCommit三个阶段组成的事务处理协议。

　阶段一：canCommit

　　① 事务询问，协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

　　② 各参与者向协调者反馈事务询问的响应，参与者在接收到来自协调者的canCommit请求后，正常情况下，如果自身认为可以顺利执行事务，则反馈Yes响应，并进入预备状态，否则反馈No响应。

　阶段二：preCommit

　　该阶段会根据反馈情况决定是否可以进行事务preCommit操作，正常情况下，包含如下两种可能：

　　执行事务预提交，假如所有参与反馈的都是Yes，那么就会执行事务预提交。

　　① 发送预提交请求，协调者向所有参与者节点发出preCommit请求，并进入prepared阶段。

　　② 事务预提交，参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。

　　③ 各参与者向协调者反馈事务执行的响应，若参与者成功执行了事务操作，那么反馈Ack，同时等待最终的指令：提交（commit）或终止（abort）。

　　中断事务，若任一参与反馈了No响应，或者在等待超时后，协调者尚无法接收到所有参与者反馈，则中断事务。

　　① 发送中断请求，协调者向所有参与者发出abort请求。

　　② 中断事务，无论是收到来自协调者的abort请求或者等待协调者请求过程中超时，参与者都会中断事务。

　阶段三：doCommit

　　该阶段会进行真正的事务提交，也会存在如下情况。　　

　　1. 执行提交

　　① 发送提交请求，进入这一阶段，若协调者处于正常工作状态，并且他接收到了来自所有参与者的Ack响应，那么他将从预提交状态转化为提交状态，并向所有的参与者发送doCommit请求。

　　② 事务提交，参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行过程中占用的事务资源。

　　③ 反馈事务提交结果，参与者在完成事务提交后，向协调者发送Ack响应。

　　④ 完成事务，协调者接收到所有参与者反馈的Ack消息后，完成事务。

　　2. 中断事务

　　① 发送中断请求，协调者向所有的参与者节点发送abort请求。

　　② 事务回滚，参与者收到abort请求后，会根据记录的Undo信息来执行事务回滚，并在完成回滚之后释放整个事务执行期间占用的资源。

　　③ 反馈事务回滚结果，参与者在完成事务回滚后，向协调者发送Ack消息。

　　④ 中断事务，协调者接收到所有参与者反馈的Ack消息后，中断事务。

三阶段提交协议降低了参与者的阻塞范围，能够在发生单点故障后继续达成一致。但是其可能还是会发生数据不一致问题。

Paxos算法

Paxos算法是一种基于消息传递且具有高度容错特性的一致性算法，其需要解决的问题就是如何在一个可能发生异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致，并且保证不论发生以上任何异常，都不会破坏整个系统的一致性。

和2PC类似，Paxos先把节点分成两类，发起提议(proposal)的一方为proposer，参与决议的一方为acceptor。假如只有一个proposer发起提议，并且节点不宕机、消息不丢包，那么acceptor做到以下这点就可以确定一个值：

P1. 一个acceptor接受它收到的第一项提议
(注: 注意以上“接受”和“确定”的区别）

当然上面要求的前提条件有些严苛，节点不能宕机、消息不能丢包，还只能由一个proposer发起提议。我们尝试放宽条件，假设多个proposer可以同时发起提议，又怎样才能做到确定并只确定一个值呢？

首先proposer和acceptor需要满足以下两个条件：

1. proposer发起的每项提议分别用一个ID标识，提议的组成因此变为(ID, value)

2. acceptor可以接受(accept)不止一项提议，当多数(quorum) acceptor接受一项提议时该提议被确定(chosen)

我们约定后面发起的提议的ID比前面提议的ID大，并假设可以有多项提议被确定，为做到确定并只确定一个值acceptor要做到以下这点：

P2. 如果一项值为v的提议被确定，那么后续只确定值为v的提议
(注: 乍看这个条件不太好理解，谨记目标是“确定并只确定一个值”)

由于一项提议被确定(chosen)前必须先被多数派acceptor接受(accepted)，为实现P2，实质上acceptor需要做到：

P2a. 如果一项值为v的提议被确定，那么acceptor后续只接受值为v的提议
满足P2a则P2成立 (P2a => P2)。

目前在多个proposer可以同时发起提议的情况下，满足P1、P2a即能做到确定并只确定一个值。如果再加上节点宕机恢复、消息丢包的考量呢？

假设acceptor c 宕机一段时间后恢复，c 宕机期间其他acceptor已经确定了一项值为v的决议但c 因为宕机并不知晓；c 恢复后如果有proposer马上发起一项值不是v的提议，由于条件P1，c 会接受该提议，这与P2a矛盾。为了避免这样的情况出现，进一步地我们对proposer作约束：

P2b. 如果一项值为v的提议被确定，那么proposer后续只发起值为v的提议
满足P2b则P2a成立 (P2b => P2a => P2)。

P2b约束的是提议被确定(chosen)后proposer的行为，我们更关心提议被确定前proposer应该怎么做：

P2c. 对于提议(n,v)，acceptor的多数派S中，如果存在acceptor最近一次(即ID值最大)接受的提议的值为v’，那么要求v = v’；否则v可为任意值
满足P2c则P2b成立 (P2c => P2b => P2a => P2)

条件P2c是Basic Paxos的核心，光看P2c的描述可能会觉得一头雾水，我们通过 The Part-Time Parliament 中的例子加深理解：

假设有A~E 5个acceptor，- 表示acceptor因宕机等原因缺席当次决议，x 表示acceptor不接受提议，o 表示接受提议；多数派acceptor接受提议后提议被确定，以上表格对应的决议过程如下：

1. ID为2的提议最早提出，根据P2c其提议值可为任意值，这里假设为a
2. acceptor A/B/C/E 在之前的决议中没有接受(accept)任何提议，因而ID为5的提议的值也可以为任意值，这里假设为b
3. acceptor B/D/E，其中D曾接受ID为2的提议，根据P2c，该轮ID为14的提议的值必须与ID为2的提议的值相同，为a
4. acceptor A/C/D，其中D曾接受ID为2的提议、C曾接受ID为5的提议，相比之下ID 5较ID
   2大，根据P2c，该轮ID为27的提议的值必须与ID为5的提议的值相同，为b；该轮决议被多数派acceptor接受，因此该轮决议得以确定
5. acceptor B/C/D，3个acceptor之前都接受过提议，相比之下C、D曾接受的ID
   27的ID号最大，该轮ID为29的提议的值必须与ID为27的提议的值相同，为b

以上提到的各项约束条件可以归纳为3点，如果proposer/acceptor满足下面3点，那么在少数节点宕机、网络分化隔离的情况下，在“确定并只确定一个值”这件事情上可以保证一致性(consistency)：

• B1(ß): ß中每一轮决议都有唯一的ID标识
• B2(ß): 如果决议B被acceptor多数派接受，则确定决议B
• B3(ß):
  对于ß中的任意提议B(n,v)，acceptor的多数派中如果存在acceptor最近一次(即ID值最大)接受的提议的值为v’，那么要求v
  = v’；否则v可为任意值

另外为保证P2c，我们对acceptor作两个要求：

1. 记录曾接受的ID最大的提议，因proposer需要问询该信息以决定提议值
2. 在回应提议ID为n的proposer自己曾接受过ID最大的提议时，acceptor同时保证(promise)不再接受ID小于n的提议

至此，proposer/acceptor完成一轮决议可归纳为prepare和accept两个阶段。prepare阶段proposer发起提议问询提议值、acceptor回应问询并进行promise；accept阶段完成决议，图示如下：

还有一个问题需要考量，假如proposer A发起ID为n的提议，在提议未完成前proposer B又发起ID为n+1的提议，在n+1提议未完成前proposer C又发起ID为n+2的提议…… 如此acceptor不能完成决议、形成活锁(livelock)，虽然这不影响一致性，但我们一般不想让这样的情况发生。解决的方法是从proposer中选出一个leader，提议统一由leader发起。

最后我们再引入一个新的角色：learner，learner依附于acceptor，用于习得已确定的决议。以上决议过程都只要求acceptor多数派参与，而我们希望尽量所有acceptor的状态一致。如果部分acceptor因宕机等原因未知晓已确定决议，宕机恢复后可经本机learner采用pull的方式从其他acceptor习得。

通过以上步骤分布式系统已经能确定一个值，“只确定一个值有什么用？这可解决不了我面临的问题。” 你心中可能有这样的疑问。

其实不断地进行“确定一个值”的过程、再为每个过程编上序号，就能得到具有全序关系(total order)的系列值，进而能应用在数据库副本存储等很多场景。我们把单次“确定一个值”的过程称为实例(instance)，它由proposer/acceptor/learner组成，下图说明了A/B/C三机上的实例：

不同序号的实例之间互相不影响，A/B/C三机输入相同、过程实质等同于执行相同序列的状态机(state machine)指令 ，因而将得到一致的结果。

proposer leader在Multi Paxos中还有助于提升性能，常态下统一由leader发起提议，可节省prepare步骤(leader不用问询acceptor曾接受过的ID最大的提议、只有leader提议也不需要acceptor进行promise)直至发生leader宕机、重新选主。

小结

以上介绍了Paxos的推演过程、如何在Basic Paxos的基础上通过状态机构建Multi Paxos。Paxos协议比较“艰深晦涩”，但多读几遍论文一般能理解其内涵，更难的是如何将Paxos真正应用到工程实践。