核心思想
分布式系统架构下如何让整体尽快达成一致观点，也就是多个不同观点收敛到一个观点的过程。
难点
- 可能会发生少数节点故障，但绝不是大面积故障，不然系统也没法正常工作。
- 由于存在单点故障，因此不可能将观点由某一台机器的统一。共享内存达到一致性的方案不可取。因此，只能是点对点通信。
一些概念
- 算法中有三个角色Proposor，Acceptor，Learner
- 算法有两个阶段，一是预提案，二是正式提案。正式提案的内容也就是观点，预提案不带观点
一些疑惑
- 为什么要有两段提交
一方面，第一次预提交后可能被告知已经有观点了，此时他不应该提出自己的观点，而应该尽快收敛，支持最新的观点。另一方面，进行预加锁。 - 怎么保证Proposal编号唯一
假设有K台Server运行paxos算法，那么他们初始编号为0…k-1。以后编号每次增加k，从而保证全局唯一递增。 - Acceptor为什么只接受最大编号的提案（包括预提案和最终提案）
要收敛就得定个收敛的方向。编号越大，提案越新，方便所有观点向一个方向（编号最大）收敛。 - 预提案为什么要获取大多数接受后才开始正式提案
尽可能保证正式提案能够通过，没有过半的预提案没有意义。毕竟只要多数（过半）认为提案通过，那么该观点就达成一致。 - 正式提案时为什么提案内容也就是观点要选择预提案回复中编号最大的观点
为了尽快形成多数派，达成观点一致 - 正式提案被半数以上Acceptor接受后，就可以确定最终被接受的提案就是该观点
如果有后来编号更大的提案N来更新当前多数派观点，那么该提案在预提案中获得多数派认可。由于已经有多数派接受了当前观点，那么提案N的预提案对于每一个Acceptor来说都是晚于当前观点的正式提案的，不然当前观点的正式提案不会接受。那么提案N的预提案必会收到当前观点的Proposal回复，他的正式提案也将会是响应当前观点。这也是为什么要有两段提交的原因。 - Acceptor是否会因为编号最新的正式提案修改之前接受的观点
会，为了更快的收敛观点。 - 如何确定能最终收敛
根据Fischer-Lynch-Paterson结论，在一个多进程异步系统中，只要有一个进程不可靠，那么就不存在一个协议，此协议能保证有限时间内使所有进程达成一致。因此paxos算法存在活锁问题，即有可能一直没法收敛。比如，预提案一直没法得到过半Acceptor接受，总是会有因为失败重新生成更大编号的Proposor来阻止通过预提案。同样，即使通过了预提案，后面也会有其他更大编号的预提案发起导致无法通过正式提案。但这种事发生的可能性比较小。特别是第二段提交降低了这种概率（见疑惑1）。理论上虽然可能永远不收敛， 大专栏 paxos算法学习总结但概率很小，实际上好用就行。毕竟是做工程嘛！ - 如何确保收到预提案Acceptor的回复后，你能拿到编号最大的被接受的正式提案
无法保证也无需保证，目的是尽快收敛，收敛到任一观点都行
一些约束
- Acceptor总是会接受编号最大的预提案及正式提案
- Acceptor不接受提案时也应该回复一个拒绝消息（或者超时也是一种拒绝）
工作流程
Proposor工作流程
- 生成一个编号，向所有Acceptor发起预提案，此次不带提案内容
- 若没有获得过半Acceptor通过，则重新生成一个更大的编号并发起预提案
- 若通过，先检查返回结果里Acceptor接受的正式提案
- 若存在已被接受的正式提案，则第二阶段的正式提案内容为回复中编号最大的已被接受的提案内容
- 若不存在，第二阶段提案内容为自己选择
- 进行第二阶段提交，向所有Acceptor发起正式提案
- 若过半Acceptor接受则流程结束，提案内容被正式确定
- 若没过半的Acceptor接受则从2开始重新执行流程
Acceptor工作流程
- 若是收到预提案请求，根据之前的承诺，不接受小于编号XXX的请求（第一次没有承诺，均接受）来进行判断
- 此次编号小于XXX，则回复拒绝
- 此次编号大于XXX，则回复接受
- 若之前有接受过正式提案，还会回复正式提案的内容及编号
- 若没有则回复null
- 若是收到正式提案请求，也会根据之前的承诺，不接受小于XXX编号的请求，进行判断
- 此次编号小于XXX，则回复拒绝
- 此次编号大于等于XXX，则回复接受
最后的结论
当某正式提案被过半Acceptor接受后，整个系统最终会达成一致，共同赞成该提案的观点
提下Multi-Paxos
实际上在Basic-Paxos中如果一个Proposer A提交的协议每次都被其他Acceptor正常接受（即没有其他的人做Proposer），那么实际上Basic-Paxos中此Proposer A在下一轮的投票中也完全可以不需要发起Prepare阶段，直接进入Accept，直到有人也开始做Proposer打破了A的“统治”，A才需要再次发起Prepare提高自己的ProposalId，由此为了优化投票过程，我们只需要保证A的统治尽可能不被打破，很简单那就不让其他的节点随意具有发起投票的权力就可以了，只有一个节点具有，所以Leader的概念就有了，而非Multi-Paxos必须有Leader！ 具体做法是，收到来自其他节点的Accept，则进行一段时间的拒绝提交请求。这样就不会提高ProposalId，达到一种各个节点都想着不要去打破这种连续Accept的状态。当有一个节点在连续的Accept，那么其他节点必然持续不断的拒绝请求。这个Leader就这样无形的被产生出来了，我们压根没有刻意去“选举”，它就是来自于Multi-Paxos算法。