《从Paxos到ZooKeeper》第二章总结二：Paxos算法

2.3 Paxos

基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一

其需要解决的问题就是如何在一个可能发生机器宕机或网络异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致，并且保证不论发生以上任何异常，都不会破坏整个系统的一致性

2.3.1 源头

计算机容错理论：拜占庭将军问题
在这里插入图片描述
从理论上来说，因为大多数系统都分布在同一局域网，因此消息被篡改的情况非常罕见
而由于硬件或网络原因而造成的消息不完整问题，通过简单的校验算法即可避免
因此在实际工程实践中，可以假设不存在拜占庭将军问题

那么这种情况下，需要什么样的算法来保证一致性呢？看看新场景：
在这里插入图片描述

2.3.2 Paxos算法详解

用来提高分布式系统容错性的一致性算法，作用是保证整个集群对某件事情达成一致

2.3.2.1 问题描述

假设有一组可以提出提案的进程集合，对于一个一致性算法来说，需要保证以下几点：
在这里插入图片描述
对于一致性来说，没有精确定义活性需求(最终一定会发生的事情)，保证最终有一个提案会被选定即可；

安全性需求如下：
在这里插入图片描述
该算法有三种参与角色：Proposer(提供者)、Acceptor、Learner

一个进程可能充当不止一种角色

可能出现的错误：
在这里插入图片描述

2.3.2.2 提案选定

2.3.2.2.1 方案一：

只允许一个Acceptor存在，这样的话，Proposer只能发送提案给该Accpetor，Acceptor会选择它接收到的第一个提案作为被选定的提案。
这个方案实现简单，但是容易单点问题，及Acceptor出问题

2.3.2.2.2 方案二：

使用多个Acceptor：Proposer向一个Acceptor集合发送提案，同样，集合中的每个Acceptor都可能会批准(Accept)该提案。当有足够多的Acceptor批准这个提案时，就可以认为该提案被选定了
规定：
1.足够多的Acceptor是整个Acceptor集合的一个子集，且可以包含Acceptor集合中的大多数成员，因为任意两个包含大多数Acceptor的子集至少有一个公共成员；
2.每一个Acceptor最多只能批准一个提案，这样就能保证只有一个提案被选定。

2.3.2.3 推导过程

1.如果希望即使在只有一个提案被提出的情况下，仍然可以选择一个提案
那么其需求P1为：

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

造成的问题为：如果有多个提案被不同的Proposer同时提出，可能会导致虽然每个Acceptor都批准了收到的第一个提案，但是没有一个提案是由多数人批准，可以真正通过的
在这里插入图片描述

2.来到1中所说的如果有多个提案被不同的Proposer同时提出的场景，此时无法选定一个提案的，如上图。
另外，即使只有两个提案被提出，如果每个提案都被差不多一般的Acceptor批准了，此时即使只有一个Acceptor出错，也可能无法选定
在这里插入图片描述
所以，在P1的基础上，再加上一个提案被选定需要由半数以上的Acceptor批准的需求暗示着一个Acceptor必须能够批准不止一个提案

使用一个全局编号来唯一标识每一个被Acceptor批准的提案；且当一个具有某Value值的提案被半数以上的Acceptor批准后，就认为该Value被选定了；此时就认为该提案被选定了；此处由[编号，Value]表示一个提案

允许多个提案被选定，意味着必须保证所有被选定的提案都具有相同的Value值，这时可以引出P2：

如果编号为M0、Value值为V0的提案(即[M0、V0])被选定了，则所有比编号M0更高的，且被选定的提案，其Value值也必须是V0

因为提案的编号是全序的，P2就保证了只有一个Value值被选定的安全性需求(需求2)；且一个提案要被选定，首先必须被至少一个Acceptor批准，因此可以通过如下条件来满足P2，即P2a：

如果编号为M0、Value值为V0的提案(即[M0、V0])被选定了，则所有比编号M0更高的，且被Acceptor批准的提案，其Value值也必须是V0

至此，仍然需要P1来保证提案会被选定，但是因为通信是异步的，一个提案可能会在某个Acceptor还未收到任何提案时就被选定了
在这里插入图片描述
此时已经批准了[M0,V1]，又来了一个[M1,V2]，且M1>M0，V1!=V2，按照P1，Acceptor1需要批准该提案，但是这与P2a矛盾，因为其Value值不等于V1；因此如果要同时满足P1和P2a，需要对P2a进行强化为P2b：

如果一个提案[M0,V0]被选定后，那么之后任何Proposer产生的编号比M0更高的提案，其Value值都为V0

因此，接下来的数学归纳法就是证明P2b成立即可：
假设某个提案[M0,V0]已经被选定了，证明任何编号大于M0的提案，其Value值都是V0
而通过数学归纳法可以得出P2b的进一步条件P2c：
在这里插入图片描述
每个Proposer如何产生一个提案：实际上是由P2c规定的，对于产生的每个提案[Mn,Vn]，需要满足如下条件：

当每个Proposer都按照这个规则来产生提案时，就可以保证满足P2b了

P2c同样通过数学归纳法来证明

2.3.2.4 Proposer生成提案

在P2c的基础上进行提案的生成

算法如下：
在这里插入图片描述
确定提案之后，Proposer就会将该提案再次发送给某个Acceptor集合，并期望获得它们的批准，即Acceptor请求

2.3.2.5 Acceptor批准提案

一个Acceptor可能收到来自Proposer的两种请求，分别是Prepare和Accept，对这两类请求做出响应的条件：
在这里插入图片描述
因此约束条件可以定义如下：P1a

可以看到，P1a包含了P1，同时，Paxos允许忽略任何请求而不用担心破坏安全性

2.3.2.6 优化

尽可能地忽略Prepare请求：
在这里插入图片描述
这样，每个Acceptor只需记住：它已经批准的提案的最大编号以及它已经做出Prepare请求响应的提案的最大编号，以便在出现故障或节点重启的情况下，也能保证P2c的不变性；而对于Proposer来说，只要它可以保证不会产生具有相同编号的提案，那么就可以丢弃任意的提案以及它所有的运行时状态信息

2.3.2.6 算法总结

综合可以得到两个阶段：

阶段一：
阶段二：
需要注意的是：

阶段二可参考如下说法： https://www.cnblogs.com/shaohef/p/4499881.html

阶段1：竞争提案编号。（阶段一可看图）
（a）想要发起提案的Proposer自行选择一个提案编号n，向过半数的Acceptor发送Prepare消息，消息的内容只包含提案编号n，并不包含想要提议的值。
（b）Acceptor记录自己接收过的Prepare消息的提案编号的最大值。如果接收到的Prepare消息的提案编号n，小于等于有记载的最大值，就忽略这个消息。如果n大于有记载的最大值，那么Acceptor就要向Proposer回复一个Promise消息。如果Acceptor曾对某个提案运行到了阶段2，那么Promise消息的内容是在阶段2中曾被接受的提案值及其对应提案编号。如果Acceptor未曾对任何一个提案运行到阶段2，那么Promise消息的内容就是“未决”。Promise消息的意思是，告知Proposer其选择的提案编号是目前见过的最大的，并且保证将来不会接受小于等于这个提案编号的消息了。

阶段2：提交提案。
（a）如果Proposer在一段时间内，没能够得到多数的Acceptor回应的Promise消息，就表明竞争提案编号失败了，递增自己的提案编号，开始新一轮的阶段1。如果得到多数Acceptor的Promise，下一步就是要实际的提交提案。首先要决定提交提案的值。找出收到的Promise消息中带的最大的提案提案编号，把其提案值作为要提交提案的值，如果所有的Promise消息内容都是“未决”，那么Proposer就可以按自己的需要决定提案的值，这个值当然就是客户本次提交的请求了。接着Proposer向多数Acceptor发送Accept消息，消息的内容是之前竞争成功的提案编号n，以及刚才决定好提案值。
（b）Acceptor收到Accept消息之后，检查其中的提案编号n，如果之前针对更大的提案编号发送过Promise消息，那么就忽略这个Accept消息，否则这个Accept消息就是目前见过的最大编号的提案，应当接受为法案。一旦一个提案接受为法案，Acceptor就向Proposer和所有的Learner发送Accepted消息，消息的内容自然是法案的编号和其法案值了。Learner在收到Accepted消息后，就可以提交法案了。