Paxos算法的案例表述及证明

案例引入

在”Paxos Made Simple”中对于paxos算法的引导推证表述是比较晦涩难懂的,所以我们先引入一个便于理解的案例来作为铺垫,案例的目的完全是通过更形象化的逻辑来表述paxos算法的思想,两者在细节上并不一定完全契合,但是对于后续算法的理解会有很大程度上的促进.

公司部门组织一次旅游,推行投票的方式来选择地点,部门员工一共 20个人,部门这次一共联系了旅游公司的 5名导游,这次选址的方式就是员工自主的与导游进行短信联系,告诉他们自己倾向的旅游地点,其中 5名导游之间不会进行通信,只会与 20名员工进行短信通信.

我们规定这次投票选址的方式分两个阶段:第一阶段(申请阶段)和第二阶段(沟通阶段),每个员工都会试图与5个导游进行沟通,每个导游也会不断收到不同员工的短信,但是每个导游任意时间段都只能跟一个员工进行沟通.
员工和导游之间短信沟通会通过(短信编辑时间)这种格式来进行申请,导游会根据短信编辑时间最新的人来给予沟通权,如果收到新的短信,其内容中短信编辑时间更新,那么就会将沟通权给最新的员工,并反馈其可以进行沟通,反之,如果收到的新短信,其短信编辑时间比当前沟通员工时间更旧,那么忽视这条短信.

以下分为两种情况:
1.所有导游A-E均未与任何一名员工沟通好旅游地点
2.存在导游跟员工沟通好旅游地点

---

1.所有导游A-E均未与任何一名员工沟通好旅游地点

第一阶段(申请阶段):

每个员工会给所有的导游发送短信来申请沟通权,如果某个员工收到3个或3个以上的导游的反馈信息---同意进行沟通,那么此员工就可以进入第二阶段(沟通阶段),反之,如果某个员工由于其短信的编辑时间过旧,导游已经收到其他员工的短信,并且编辑时间还要更新,那么他的短信就会被导游忽视,从而收不到3个或3个以上导游的反馈,只能从新编辑短信修改更新的编辑时间,重新向导游申请沟通权限

第二阶段(沟通阶段):

当某个员工得到了3个或3个以上导游的反馈信息后就可以正式跟导游进行旅游地的沟通了(短信编辑时间,建议的旅游地点),当你将短信发送给某个导游的时候,导游首先会看你沟通阶段发送的短信编辑时间是否是最新的,如果不是最新的,也就是在这个期间有其他更新的员工抢夺了沟通权,那么就会忽视你发送的沟通短信,若是最新的,则对应的导游就会你短信沟通的旅游地点作为他的成功沟通确认地点,如果最后你收到的沟通成功反馈大于等于3个时,那么你所提议的旅游地点将会作为最终的结果,反之,如果最终的反馈小于3,那么就会重新编辑更新的短信时间进行第一阶段(申请阶段)的流程.

---

2.存在导游跟员工沟通好旅游地点,但是没有任何一个地点是三个或三个以上导游共同确定的

在第一阶段(申请阶段)中:

如果员工向某个导游申请沟通权限过程中,这个导游已经和某个员工沟通确认过一个旅游地点,那么这个员工申请沟通权限成功后,会获得导游提供的之前员工已经确认的短信信息(短信编辑时间,建议的旅游地点)

在第二阶段(沟通阶段)中:

当某个员工获取到沟通权限(获取3个或3个以上的导游同意沟通的反馈),那么这个员工就会从之前申请权限阶段从导游获取到已经沟通好的旅游地点中选取编辑时间最新的一个地点作为自己在第二阶段(沟通阶段)进行沟通的地点,而不是自己原有打算的旅游地点,这个规则是非常重要的一点

当某个员工第二阶段(沟通阶段)成功,即成功得到3个或3个以上的导游反馈,那么这个员工的建议旅游地点就会顺利成章最终的结果,原因如下:

• 1.当某个员工建议的旅游地点被3个或3个以上的导游沟通确认,那么当其他员工进行第一阶段(申请阶段)时,这个员工必须要经过3个或3个以上的导游进行同意才能进行第二阶段
• 2.当其他员工第一阶段进行短信交互的导游中必然有一个是之前已经确认地点员工所交互的导游中的一个(一共5个导游,两个不同的3个以上的导游集体肯定会有同一个人),所以这个员工第一阶段收到的反馈地点肯定存在之前已经确认的地点,并且这个地点的更新时间是最新的,之后就会把这个确认的地点作为沟通地点进行沟通,这也就是为什么合法人数是N/2+1.

---

结论

所以得到一个结论:当一个地点被三个或三个以上的导游确认之后,那么这个地点就不会再改变

• 当一个地点(如泰国)被三个或三个以上的导游确认之后,之后每一个申请沟通的员工,如果被超过半数的导游同意后,总都会拿到其中至少一个导游反馈这个被确认的地点(泰国),并且这个地点将会一直是最新的
• 之后的员工都会放弃自己原有的地点(北京长城),重新选择这个已经确认好的地点(泰国)与导游进行沟通,所以一旦某一个地点被三个或三个以上的导游确认后,那么之后员工每一次沟通都会用这个被确定的地点(泰国)去沟通

• 可以看到,后续时间更新的员工发出的沟通都会在第一阶段(申请阶段)获取到最新已经确认的反馈地点(泰国),当收到超过三个反馈地点后,之后在第二阶段(沟通阶段)就会将地点替换后的地点(北京长城->泰国)发送给导游进行确认沟通.

所以得出结论: 一旦有三个导游沟通的地点一致

之后被三个或三个以上导游达成一致的地点只能是最初达成一致的地点(泰国)
之后任何一个导游沟通同意的地点也只会是这个(泰国)
之后任何一个员工发起与导游沟通的地点也只会是这个(泰国)

---

算法证明

在理解上述故事的逻辑之后,我们来正式了解Paxos算法.
Paxos算法的核心是:解决分布式系统的一致性的问题,所有的问题均围绕着在分布式环境达成一致性而展开讨论的.而Paxos算法为了达成一致性,算法就需要保证其安全性和活性

• 安全性:只有被提出的提案才能被选定,并且只有一个提案被选定
• 活性:最终保证会有一个提案被选定
• 安全性和活性的综合结果就是:最终有且只有一个被提出的提案被选定.

算法名词:

1.Proposer:提案者,它可以提出一个提案
2.Acceptor:提案的受理者,有权决定是否它本身是否批准该提案
3.Choose:提案被选定,当有半数以上的Acceptor批准该提案时,就认为该提案被选定
4.Learn:不参与Paxos提案选定的过程,只在体案被选定时,知道提案结果的角色
5.Proposal:提案,由Proposer提出.一个提案由一个编号及value形成的键值对组成,如[n,value],提案的编号必须是全局唯一,value即代表了提案本身的内容

[在具体的执行过程中,同一个进程可能不止充当一种角色,同一个进程可能在三个角色中互换,且系统中所有消息不存在篡改的问题,即不存在拜占庭的问题]

Paxos中主要涉及三个角色和两个阶段

角色: Acceptor, roposer和 Learn. (其中 Accptor可以认为是导游, Proposer认为是员工)
阶段: Prepare(预提案阶段)和 Accept(提案阶段).

---

Paxos提案选举过程

第一阶段(预提案):

1.Proposer先选择一个提案编号N(我们假设所有的proposer都是从0开始的),并将该编号的预提交请求Prepare(N)发送给acceptor集合中大多数服务(一般是全部的acceptor集合)
2.假如一个acceptor接受到了一个提案编号为N的预提案请求Prepare(N),则比较acceptor已存储的最大提案编号N`和编号N的大小关系
如果 N`为空,则令n= N`-> n=N,value=null,并且同意proposer的预提案请求,并将当前acceptor的最大提案编号和value值[N,null]反馈给Proposer.
(此阶段可以认为是员工向导游发起沟通申请过程,并且每个导游都还未与任何员工同意沟通过旅游地点)
如果 N`N` -> n=N ,并且同意proposer的预提案请求,同时发送当前acceptor的最大提案编号和最后的数据value值[N,value]给proposer
(此阶段可以认为是员工向导游发起沟通申请过程,并且导游之前已经跟某个员工沟通同意过旅游地点)
如果 N`>N,则拒绝该proposer的预请求.
(此阶段可以认为是员工向导游发起沟通申请过程,并且此条沟通信息编辑时间晚于该导游之前已经同意的信息)

第二阶段(提案):

1.当Proposer的预提案Prepare(N)被acceptor集合中大多数同意时,则proposer会从acceptor反馈中选取一个最新的value值Vnew最为本次提案的value值进行提交Proposal [N,Vnew].
(此阶段可以认为员工获取大多数导游的申请同意后,开始正式向导游沟通,当每个导游都从未与任何员工沟通过地点时,员工就用自己原有的地点进行沟通,如果之前有员工和导游进行沟通过地点,那么就选择此导游反馈的地点进行沟通)

2.如果一个acceptor接受到一个提案编号为N的提案Proposal[N,Vnew],如果N<=N,则令n=N -> n=N,value=Vnew,并且通过该提案
(此阶段可以认为员工向导游进行旅游地点的正式沟通,并且此条信息的编辑时间是最新的,那么此导游将此条沟通信息作为最新的沟通结果)

3.如果N`>=N,则拒绝该提案
(此阶段可以认为员工向导游进行旅游地点的正式沟通,但此条信息的编辑时间不是最新的,那么将决策此条沟通信息)

• 当一个value值的提案为N时被大多数的acceptor批准了,因此在N+1个提案时,其从大多数acceptor获取预提案的反馈时必然会接收到值为Value的提案,并且此题案编号是最大的,因此N+1个体案Value值也必须是value,以此类推,之后所有的提案都不会改变value值的取值
• 所以一旦一个值被大多数acceptor批准,则之后的提案不会再改变这个值

(此阶段可以认为在一个地点(泰国)被3个或3个以上导游确认之后,那么之后员工在沟通阶段进行沟通的地点都会用泰国来进行沟通,所以之后导游同意的地点只能是泰国)

---

算法证明

最后来我们正式来分析<>的证明过程,此证明过程容易让人产生混淆的关键在于其中1-6点的推导过程是针对accept过程的,还不涉及到prepare过程,而prepare过程是逐步引导出来的,特别是p2c证明p2b的过程,会犯下拿运作过程当已知条件来证明证明过程的错误,所以要想理解证明过程,必须先抛弃运作过程的认知.

算法问题描述:

假设有一组可以提出提案的进程集合,那么对于一个一致性算法来说需要保证如下几点:
1.在这些被提出的提案中,只有一个会被选定
2.如果没有提案被提出,那么就不会有被选定的提案
3.当一个提案被选定后,进程应该可以获取被选定的提案信息

从而对于一致性来说,

安全性需求如下:
1.只有被提出的提案才能被选定(chosen)
2.只有一个值能被选定
3.如果某个进程认为某个提案被选定了,那么这个提案必须是真的被选定的那个

对于活性需求来说
1.最终保证会有一个提案被选定

安全性和活性的综合结果就是:最终有且只有一个被提出的提案被选定,当提案被选定后,进程最终也能获取到被选定的提案

---

推导证明:

安全性:

P0. 要选定一个唯一的提案最简单的方式就是只允许一个Acceptor存在,这样的话,Proposer只能发送提案给这个Acceptor,该Acceptor会选择它接受到的第一个提案作为被选定的提案
这样的方式尽管实现很简单,但是存在单点问题,一旦这个Acceptor出现问题,那么整个系统就无法工作了
因此此方案的改进方式,可以使用多个Acceptor来避免Acceptor的单点问题

现在就来看看,存在多个Acceptor的情况下,如何进行提案的选取:

• Proposer向一个Acceptor的集合发送提案,同时,集合中每个Acceptor都可能会接收到该提案 ,当足够多的Acceptor批准这个提案时,我们就认为该提案被选定了
• 在没有失败和消息丢失的情况下,如果我们希望即使在只有一个提案提出的情况下,也可以选出一个提案,那么就要需要满足以下条件:

P1:一个Acceptor必须批准它接受到的第一个提案 --- 使得安全性第1条和活性第一条成立,只要有提案被提出来,那么就会有提案被选定

A. 当假设每个Acceptor最多只能批准一个提案,上面这个需求引出另一个问题:如果多个提案被不同Proposer提出,可能会导致每个Acceptor都批准它收到的第一个提案,但是没有一个是多数人都批准的

所以假设A不成立,即表明一个Acceptor必须能够批准不止一个提案,因此这里使用一个全局的编号来唯一标识每一个Acceptor批准的提案

B. 当假设每个Acceptor能批准多个提案 --- 使得安全性第2条成立,只有一个提案能够被选定

根据以上的条件,我们允许多个提案被选定,同时要保证所有被选定的提案都具有相同的value值,因此引出以下定理

P2:如果编号M0,value值为V0的提案,即(M0,V0)被选定,那么所有比编号M0更高的,且被选定(chosen)的提案,其值必须是V0 --- 使得安全性第3条成立,一个提案被选定后,那么提案的值将不会再改变
(这里P2是对于Chosen的一个提案要求,我们可以将此阶段看成,当一个旅游地点(泰国)被3个或3个以上的导游确定后,之后被3个或3个以上导游选定的地点只能是泰国)

以下将从Chosen阶段->Accpet阶段->Propersser阶段进行推演

• Accept阶段:如果要想让让支持安全性第3条的p2成立,那么必须把它落实在acceptor的accept上,那就引出下面的P2a

P2a:如果一个编号为M0,value值为v0的提案(M0,V0)被选定,那么所有比编号M0更高的,且被Acceptor accept的提案,其value值都是V0

• 为了同时保证p1和p2a,我们对p2a进一步限制,从而引出p2b

P2b:如果一个提案(M0,V0)被选定后,那么之后任何Proposer产生的编号更高的提案,其Value值都为V0
(这里P2b是对于Proposer的proposser要求,我们可以将此阶段看成,当一个已经被3个或3个以上导游同意沟通的员工,他得到导游反馈后向导游进行沟通的地点是从反馈中选取的最新的地点(泰国),而不是自己之前的中国长城)

因此 p2,p2a,p2b分别是从Chosen,Accept,proposal三个阶段对安全性条件3的一个限制,从而保证了一旦一个提案(地点)被选定,那么之后提出的提案(地点),都是同一个

最后,p2c来具体规定proposer如何产生一个proposal

P2c:对于产生的每个提案(M0,V0).需要满足如下条件:
1.要么S中没有Accept批准过编号小于M0的任何提案
2.要么S中的所有Acceptor批准的所有编号小于M0的提案中,编号最大的那个提案Value值为V0

(此阶段就可以认为,当被3个或3个以上导游同意进行沟通的员工,他第二阶段向导游进行沟通时,如果之前任意一个导游都没和员工沟通同意过地点,那么此员工将用自己原本打算的地点进行沟通,如果导游已经合其他员工进行过沟通同意旅游地点,如:泰国,那么他将舍弃自己原本的地点(中国长城),而使用导游反馈的最新的地点(泰国)进行沟通)

活性: --- 当选举过程从一阶段变成二阶段后,如果出现死锁的情况下,活性是不能够被保证的.

我们很容易构建这样一个场景，两个proposer 持续发送比对方的更高提案编号，并且最终它们两者没有一个被选中。例如：proposer -pn提出 pn1完成了phase 1。另一个proposer ?-qn接着批准了qn2 > pn1完成了phase 1。proposer -pn在phase 2的以pn1标记的accept request会被所有acceptor拒绝，因为acceptor已经承诺不接受任何number小于qn2的提案。因此proposer-qn开始用新的pn3 > pn2来开始并完成phase 1，而这又导致了Proposer ?qn2在phase 2的accept被忽略。如此反复进行。