paxos算法
1 paxos算法是什么
“The Paxos algorithm, when presented in plain English, is very simple”
Paxos 算法的发明人 Leslie Lamport 是分布式系统的奠基人之一，轶事颇多，从 Paxos 这个名字也能窥得一斑：Paxos 是 Lamport 为了引出分布式系统共识问题，所虚拟的一个古希腊城邦。在最初的相关论文 The Part-Time Parliament 发表于 1998 年后，很多人都表示理解不能。于是 Lamport 在 2001 年，又使用相对简练的语言和逻辑，将其主干思想重新阐述了一遍，便有了 Paxos made simple https://lamport.azurewebsites.net/pubs/paxos-simple.pdf
2 paxos算法讲解
2.1 三个角色
角色：proposer（提案者）、acceptor（批准者）、learner（学习者）；三种角色只是逻辑上的划分，一个节点可以同时充当这三类角色；
- proposer：生成全局唯一且递增的proposalID（key），并提出议案，也就是value(value可以是任何操作，比如修改某个变量为某个值,paxos协议中统一将这些操作抽象为value，不同的proposer可以提出不同甚至矛盾的value）形成key-value；
- acceptor：集群中acceptor有N个，acceptor之间完全独立对等，proposer提出的value必须获得超过半数（N/2 + 1）个acceptor批准后才能通过；
- learner：不参与选举，只是学习被批准的value；
重点：Paxos中proposer和acceptor是算法的核心角色，paxos就是在一个由多个proposer和多个acceptor构成的系统中如何让多个acceptor针对多个proposer提出的多种提案达成一致的过程
2.2 两个阶段
阶段：prepare（准备）阶段、accept（选举）阶段、learn阶段（此阶段已经达成共识）
- Prepare阶段：Proposer向Acceptors发出Prepare请求，Acceptors针对收到的Prepare请求进行Promise承诺。
- Accept阶段：Proposer收到多数Acceptors承诺的Promise后，向Acceptors发出Propose请求，Acceptors针对收到的Propose请求进行Accept处理。
- Learn阶段：Proposer在收到多数Acceptors的Accept之后，标志着本次Accept成功，决议形成，将形成的决议发送给所有Learners
2.3 流程演示
2.3.1 prepare（准备）阶段
- proposer生成全局唯一且递增的proposalID，向paxos集群的所有机器发送prepare（准备）请求，这里不携带value，只带key，，即proposalID；
- acceptor收到prepare请求后，判断proposalID是否比之前accept的所有提案的key值大，
- 如果是，则在本地持久化key，可标记为max-key；回复请求，并带上已经accept的提案中key值最大的value，如果此时还没有已经accept的提案，则返回value为空；并作出promise，不会accept任何小于max-key的提案
- 如果否，则不回复或回复error
2.3.2 accept（选举）阶段
- proposer发送给acceptor prepare请求一段时间后，proposer收集到一些回复，
- 如果收到的回复数 > 一半的acceptor数量，且所有回复的value都为空时，则proposer发出accept请求，并带上自己指定的value
- 如果收到的回复数 > 一半的acceptor数量，且有的回复value不为空时，则proposer发出accept请求，并带上回复中的proposalID最大的value，作为自己的提案内容
- 如果收到的回复数 <= 一半的acceptor数量，则尝试更新生成更大的proposalID，再转到prepare（准备）阶段执行
- acceptor收到accept请求后，判断：
- 若收到的key >= max-key （一般情况下是等于），则回复提交成功，并持久化key和value
- 若收到的key < max-key 则不回复或回复提交失败
- 经过一段时间后proposer收到一些accept请求的回复，并统计
- 若回复成功的数量 > acceptor数量一半时，这表示提交value成功，此时可以发一个广播给所有的proposer、learner，通知他们commit的value
- 若回复成功的数量 <= acceptor数量一半时，则尝试更新更大的proposalID转到prepare（准备）阶段执行
- 若收到提交失败时，则尝试更新更大的proposalID转到prepare（准备）阶段执行
