一致性算法-Paxos算法

Paxos算法

“一个再怎么高高在上的理论，再怎么被神化的技术方案，就算再好，如果无法落地，就意味着没有任何价值”

一：一致性协议的由来

Paxos、Raft一致性协议，有些地方也称之为一致性算法，但不管称呼怎么变化，它们代表的意义是相同的，即作为CAP理论的落地者。

不过在聊Paxos、Raft这些著名的一致性协议前，我们先来聊聊为何需要它们。

回到起初集中式的单机部署方案，因为现实中存在太多不可控因素，如硬件损坏、自然环境影响、网络故障、系统/进程崩溃……，这些因素都会导致部署在该机器上的程序无法正常运转，也无力处理到来的外部请求。

这就是所谓的单点故障问题，如果一个系统未曾解决单点故障，意味着它还不够健壮、不够可靠、不够稳定！

如何保证高可用？最有效的手段就是选择集群模式部署

对业务系统这种无状态的服务来说，使用集群方案一本万利，可对于存储型的服务来说，虽然保证了可用性，但也带来了新的问题。

因为如果使用集群方案，意味着所有数据都将以副本形式存储在其余节点上，这种形式虽然提高了系统的可用性，可多节点之间的数据如何保证一致性呢？

这个问题在前几篇中反复提及，可聊来聊去，无非就是在说同步、半同步、异步复制这三种方案，一致性真有这么简单吗？实则不然，大家不妨看看这些问题：

• 集群中拥有多个节点，如何解决多个节点写入时的冲突
• 集群内某些节点出现故障时，怎么保证对外服务的可用性
• 集群发生故障转移时，如何保证新主拥有旧主的所有数据
• 集群内发生网络分区问题时，如何避免集群出现脑裂问题
• 使用读写分离时，如何保障多节点间读到的数据完全一致
• …

二：Paxos协议

Paxos算法由Lamport（莱斯利·兰伯特）提出，它是现有保证分布式一致性最有效的手段，也是诸多分布式一致性协议的“老祖宗”。

Paxos是基于消息传递且具有高度容错性的一致性算法，它被广泛运用于各类分布式存储系统。

当然，Paxos算法最早出现在兰伯特《The Part-Time Parliament》这篇论文里

Paxos算法实际有两个大类，即：

• Basic-Paxos：兰伯特论文中提到的Paxos算法，只具备单决策能力；
• Multi-Paxos：《Paxos Made Simple》论文最后拓展提到的算法，具备多决策能力。

1：拜占庭将军问题

拜占庭是古代东罗马帝国的都城，而拜占庭将军问题，是指守卫边境的一群将军，需要通过信使来与都城完成信息交换，以决定是否共同进攻敌人的场景：

然而，这些将军中可能存在叛徒，有可能发送虚假信息以干扰首都的决策。

此外，信使也可能不可靠，导致信息丢失或被篡改。

因此，拜占庭将军问题关注的是：如何在“有内奸、信使不可靠”的情况下，确保首都决策的正确性。

上述场景套到分布式系统里，身处四方的将军们，就是系统内一个个节点，而负责交换信息的信使，就是网络。

各节点发出的数据可能不一致，网络传输数据时有可能中断丢失、重发乱序、被篡改等，而这就是分布式系统里的拜占庭将军问题。

Paxos算法需要解决的就是拜占庭将军问题，即：如何在不可靠的分布式系统中，快速且正确地使各节点能够达成一致状态。

拜占庭将军问题，该如何保证决策的正确性？答案是根据大多数将军的共识进行决策！

即使将军里有内奸、通信可能被篡改

但同一件事，如果大部分将军都秉持同一个说法，那就可以认为这个信息是可靠的，也可以用来作为下达决策的依据

因此，Paxos、Raft还有另一个名字，即共识算法！

现在有一家企业叫熊猫集团

• 提案者相当于领导阶级(proposer)
• 接受者相当于董事会（acceptor）
• 学习者就是底层打工的小马仔(learner)。
• 提出的方案(proposal)

在年度总结大会上，领导可以在会议上提出各种新的方案，以此来促进集团发展，比如“小竹提出来年实行上四休三工作制”。

董事会的各位大领导，则可以针对“小竹”提出的方案进行批准，如果批准通过，集团所有打工人按方案落实即可。

3：Paxos推导过程

3.1：最初的P1

集团里可以提出方案的领导不止一人，而多位领导同时提出方案时，这时有可能会出现冲突，比如：

• 小竹：为了提升员工幸福感，明年实行“上四休三”工作制！
• 老王：为了提高工作的饱和度，明年将双休改为单休模式！

小竹和老王同时提出方案，如果一起批准落实，就会出现“一部分马仔一周干四天，另一部分马仔一周干六天”

这显然破坏了集团内部的“一致性”，此时该咋办？最简单的方案就是：

P1 -> 只让一位董事可以拥有批准权限，并且该董事必须接受提出的一个方案

因为董事只批准第一个方案，所以集团内部最终同时只能推行一种方案，避免多个方案冲突造成的不一致性！

3.2：P2的改进

上面这种模式可以嘛？不太行，毕竟现在只有一位领导，集团内大大小小方案都需要经他之手，万一某天他请假了呢？

这时方案就没人通过了（单点故障问题）

对于一个大型集团而言，这种现象必然是不可接受的，为此，具备“批准方案”权限的董事肯定不能只有一个，如下：

现在有多位董事都具备批准权限，那就出现了新的问题

如果不同的方案，同时提交给不同的董事，因为每位董事之前都没批准过其他方案，所以不同董事会一起批准通过，多种方案同时在集团内推行，又会因为方案冲突带来不一致！怎么办？完善一下通过批准的制度：

P2 -> 一个方案必须被大多数董事（至少半数以上）批准通过后，才允许在集团内推行！

为了满足这个规定，意味着某个领导提出的方案，不仅仅只是提交给一位董事，而需要提交给多位董事；

同时，一位董事不仅只接收一个方案，同时要接收、批准多个方案。

当然，为了帮助各位董事区分出“同时接收到的多个方案”，每个方案都必须有个唯一标识，即方案的编号。

就目前为止，一个完整的方案 = 方案编号 + 方案内容

通过这种“过半批准”机制，貌似解决了“不同方案被不同董事批准通过”的问题，但新问题又来了，看例子：

如上图所示

• 小竹将方案①“上四休三”提交给一号、二号董事，接着得到了两位董事批准；
• 同时，老王将方案②“双休改单休”提交给二号、三号董事，他的方案也得到了两位董事批准。

目前董事会一共三人，方案一、二都有两位董事支持，意味着这两个方案都得到了大多数董事的批准

根据前面的P2规定，集团内部又会同时推行两个方案，导致“一部分马仔一周干四天，另一部分马仔一周干六天”这种不一致场景复现。

OK，我们先来分析下产生不一致问题的原因，究其根本，就是因为在同一轮决策中，二号董事即批准了方案一、也批准了方案二

因此，在这轮决策里，最终有两个方案被批准通过。

3.3：P3的改进

怎么解决？很简单，既然同一轮决策批准多个方案会造成不一致性问题发生，那同一轮决策只允许批准通过一个方案即可。

P3 -> 同一轮决策中，所有董事都对同一个方案进行批准！

一轮决策中，所有董事同一个方案，代表最终只会有这一个方案通过，这样就解决了前面的问题。

当然，上面只是理想状态，现实情况并不可控，再看个例子：

在上午10:00时，只有一号董事在，小竹提交了“上四休三”方案，来看看是否满足前面的三个规定：

• ①小竹的方案，对一号董事来说，是收到的第一个方案，P1满足，一号批准通过；
• ②目前只有一位董事，1÷1=100%，通过此方案的董事在半数以上，P2满足；
• ③上午10:00只有一号董事在，因此P3也满足。

因为小竹提出的方案一，同时满足三个规定，因此准备开始在集团内推行。

可是到了10:30，堵车的二号董事、拉肚子的三号董事都来了，这时老王提交了“双休改单休”方案，再来看看前面的三个规定：

• ①老王的方案对二、三号董事来说，是收到的第一个方案，P1满足，二、三号批准通过；
• ②目前总共三位董事，2÷3≈66.67%，通过该方案的董事也在半数以上，P2满足；
• ③上午10:30，三位董事都在，并且同时对老王的方案进行批准，P3也满足。

此时来看，小竹的方案一还