架构设计：系统存储（25）——数据一致性与Paxos算法（下）

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！ 

2-3. Paxos算法变种

上文我们提到，Paxos算法的设计是为了解决多个Proposer针对一个具体提案产生的多个赋值，并最终帮助多个Proposer确定一个大家一致认可的赋值，最终达到一致性。从理论层面上说，如果多个Proposer一直不产生竞争起来，那么算法研究就没有意义。例如上文中提到的一个Proposer A的投票轮次编号始终从1000开始，其它Proposer的投票轮次编号始终从100开始，那样的话Paxos算法系统中其它Proposer发起的提案申请在第一轮就会被拒绝（在Proposer A的第一次提案申请到达Acceptor之前，可能会有其它Proposer发起的提案进入第二轮，但最终也会被大多数Acceptor决绝），所以这样的Proposer编号设定实际上就会让所有Proposer都听命于Proposer A的提案决断。

可是从实际应用的角度出发，却刚好相反——让Paxos算法过程尽可能少的产生竞争有利于提高算法效率。在Basic-Paxos算法中，任何一个提案要被通过都至少需要和单独的Acceptor通讯两次（这里还不考虑多Proposer抢占的问题），如果有N个Acceptor则至少进行 （N/2 + 1）× 2次网络通讯。如果在一个完整的Paxos算法中，网络通讯占去了相当的时间，那么Paxos算法的性能自然不会好。所以Paxos算法会产生了很多变种形式。本节我们就对一些主要的变种形式进行说明

2-4. Paxos变种：Multi-Paxos算法

介绍Basic-Paxos时我们只针对了一个议题形成多数派达成一致的值的算法过程进行了说明，无论有多个Proposer参与了抢占Acceptor赋值权的过程，无论为了形成这个多数派决议发起了多少轮Prepare投票申请，也无论Acceptor拒绝了多少次Acceptor赋值请求。所有这一切都只是为了处理一个议题，如：关于K的赋值是多少、关于你爸的名字是A还是B、关于下一次事件触发时间是在1000秒以后还是2000秒以后。

但实际业务场景往往不是这样的，在分布式存储环境中，拥有Paxos算法功能的整个系统需要在生命周期内对多种议题进行一致性处理，例如日志编号X的操作是将编号K的值赋为A还是赋为B；下一个日志编号X+1的操作，是将K的值赋为Y还是赋为W……

为了将Basic-Paxos算法用于实际应用中，Basic-Paxos算法有一种变种算法叫做Multi-Paxos，其中的“Multi”当然就代表在Paxos算法系统存活的整个生命周期需要处理的多个提案。Multi-Paxos算法的工作过程大致可以概括为选主保持、正式工作、重选恢复，本节我们就和大家一起讨论一下Multi-Paxos算法这几个工作步骤。

2-4-1. Multi-Paxos：选主与保持

Multi-Paxos算法核心过程的工作原则和Basic-Paxos算法核心工作原则是相同的，即多数派决定、Acceptor第一轮只接受更大的投票编号、Acceptor第二轮只接受和目前第一轮授权相同的投票编号。但是为了提高对每一个议题的判定效率，Multi-Paxos算法在第一投票过程中做了一个调整： 首先通过一个完整的Paxos算法过程完成一次选主操作，从多个Proposer中选出一个Proposer Leader，待所有Proposer都确认这个Proposer Leader后，后续的带有业务性质的提案，都只由这个Proposer Leader发起和赋值 。这样的做法至少有两个好处：

• 其它Proposer在确定自己不是Proposer Leader后，就 不再发起任何提案的投票申请 ，而只是接受Learner（最终结果学习者）传来的针对某个提案的最终赋值结果。而往往Le