paxos作者论文 The Part-Time Parliament 翻译1 翻译2
paxos作者论文 Paxos Made Simple 翻译1 翻译2 翻译3
文章 深入浅出Paxos算法协议 还不错
三个约束:
决议(value)只有在被 proposers 提出后才能被批准(未经批准的决议称为“提案(proposal)”)
在一次 Paxos 算法的执行实例中,只批准(choose)一个 value;
learners 只能获得被批准(choose)的 value。
proposal 由全局唯一递增的编号 + value 组成
acceptors 只能 accept 一个proposal,不能choose一个proposal
为了满足只choose一个 value 的约束,要求被“多数派majority” accept的 proposal里的value 成为被choose的value。这是因为两组“多数派”至少有一个公共的 acceptor,如果每个 acceptor 只能accept一个 value,约束2就能保证。
如果只有一个proposal,这个proposal应该能被choose,所以
P1:acceptor必须accept收到的第一个proposal
在P1下,如果每个acceptor只能accept一个proposal,可能出现一半acceptor接受valueA,另一半接受valueB的情况,此时无法形成多数派,所以每个acceptor可以accept 多个proposal,每个Paxos实例能choose多个proposal,此时要满足约束2,需要:
P2:一旦一个具有 value v 的提案被choose,那么之后choose的提案必须具有 value v。
满足P1和P2,就能保证至少有一个proposal被choose,且多个proposal被choose时,他们具有相同的value,即满足约束2
满足P2a,就能满足P2
P2a:一旦一个具有 value v 的proposal被choose,那么之后任何 acceptor 再次accept的proposal必须具有 value v。
由于网络延迟,可能出现一个具有valueA的proposal已经被多数派choose了,但某个acceptor先收到并accept的是序号更大的具有valueB的proposal。需要对P2a进行强化:
满足P2b,就能满足P2a
P2b:一旦一个具有 value v 的proposal被choose,那么以后任何 proposer 提出的proposal必须具有 value v。
满足P2c,就能满足P2b 数学归纳法证明
P2c:如果一个编号为 n 的proposal具有 value v,那么存在一个多数派,要么他们中所有人都没有accept编号小于 n的任何proposal,要么他们已经accept的所有编号小于 n 的proposal中编号最大的那个proposal具有 value v。
要满足P2c的约束,proposer提出一个proposal前,首先要和足以形成多数派的acceptors进行通信,获得他们进行的最近一次 accept 的proposal(prepare过程),之后根据回收的信息决定这次proposal的value。当被多数派accept后,proposal获得 choose,由acceptor将这个消息告知learner。这个简略的过程经过进一步细化后就形成了Paxos算法。
为了维护P2c的不变性,一个proposer在产生编号为n的proposal时,必须要知道某一个将要或已经被多数派accept的编号小于n的最大编号的proposal。获取那些已经被accept的proposal很简单,但是预测未来会被accept的那些却很困难。在这里,为了避免让proposer去预测未来,我们通过限定不会有那样的accept情况来控制它。换句话说,proposer会请求acceptors不要再accept任何编号小于n的proposal:
满足P1a,就能满足P1
P1a:当且仅当acceptor没有回应过编号大于n的prepare请求时,acceptor accept 编号为n的proposal。
choose一个决议分为两个阶段:
prepare阶段:
proposer选择一个编号n并将prepare请求发给一个多数派;
acceptor收到prepare消息后,如果proposal的编号大于它已经回复的所有prepare消息(回复消息表示accept),则acceptor将已accept的具有最大编号的proposal回复给proposer,并承诺不再回复小于n的proposal;
批准阶段:
当一个proposer收到了多数派对prepare的回复后,向多数派(两个多数派不一定要相同)发送accept请求,包括编号n和根据P2c决定的value。
在不违背自己向其他proposer的承诺的前提下,acceptor收到accept请求后即accept这个请求。
这个过程在任何时候中断都可以保证正确性。例如如果一个proposer发现已经有其他proposers提出了编号更高的提案,则有必要中断这个过程。因此为了优化,在上述prepare过程中,如果一个acceptor发现存在一个更高编号的提案,则需要通知proposer,提醒其中断这次提案。
决议的发布
一个显而易见的方法是当acceptors批准一个value时,将这个消息发送给所有learners。但是这个方法会导致消息量过大。
由于假设没有拜占庭错误,learners可以通过别的learners获取已经通过的决议。因此acceptors只需将批准的消息发送给指定的某一个learner,其他learners向它询问已经通过的决议。这个方法降低了消息量,但是指定learner失效将引起系统失效。
因此acceptors需要将accept消息发送给learners的一个子集,然后由这些learners去通知所有learners。
但是由于消息传递的不确定性,可能会没有任何learner获得了决议批准的消息。当learners需要了解决议通过情况时,可以让一个proposer重新进行一次提案。注意一个learner可能兼任proposer。
实现状态机
Multi-Paxos
Fast-Paxos
如果用序号来标识不同的paxos执行实例,那么什么情况下使用新的序号?