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执行实例，那么什么情况下使用新的序号？