什么是paxos
paxos是一个共识算法。通过投票的方式使得分布式系统数据最终达到一致。 paxos中分为一下几种角色：
- proposer：接受client端发起的请求，然后向集群中的所有节点发起投票请求。
- accepter：propser角色发起投票的接受者和决策者。
- learner：提议接收者，对所有通过的提议进行bankup(备份)。
简单的说由proposer接受到client的请求后由propsoer向集群所有节点发起投票，投票由所有accepter节点进行投票，本次投票通过数满足大多数原则，accepter通知proposer投票通过并同时通知learner节点将本次投票进行备份。
paxos流程
- client发起请求
- proposer接收到client的请求，对本次请求产生一个当前投票的id，投票id全局递增。发送给accepter，注意，此时并不关心投票的内容，只关心投票id。
- accepter接收到proposer的投票请求，若投票id是最新的则所有accepter节点对本轮投票请求进行投票。并将投票结果返回给proposer。
- 超过1/2的accepter节点通过，则本轮投票通过。
- 超过1/2的accepter节点不通过，则拒绝本轮投票。
- proposer接收到投票结果，若通过则重新将请求消息发送给所有accepter节点进行二次投票。若投票结果不通过则通知client投票结束。
- accepter节点对投票内容进行二次投票。
- 超过1/2的accepter节点通过，则本轮投票通过。投票结果返回给proposer同时通知learner节点对本次投票进行记录备份。
- 超过1/2的accepter节点不通过，则本轮投票不通过。投票结果返回给proposer。
paxos从诞生到现在演化了几个版本，basic paxos和mutli paxos，mutli paxos可以看作是basic paxos的优化版本。
basic paxos基本流程
正常通过的基本流程：
上图看出，proposer的投票请求得到所有acceptor节点的同意。后proposer再次向所有acceptor发起消息内容投票。通过后accpetor同时通知proposer和learner。
部分accepter节点掉线，但是投票满足大多数原则的基本流程：
上图看出，3个acceptor节点中第三个节点挂掉，但是投票结果满足大多数原则，所以依然能保证流程顺利进行。
proposer失败的基本流程：
上图看出，当投票返回后proposer挂掉，client重新请求到另外一个proposer节点，产生的新投票id由之前的prepare(1)变为prepare(2)。
basice praxos的弊端：
1.上述流程中可看出，praxos的流程需要进行两轮投票，过程繁琐，效率低。
2.发迸发场景下很容易由于投票id的递增，投票id请求不断的被拒绝而导致活锁。如下图所示。
mutli paxos
由于basic paxos以上的两个弊端，而诞生出mutli paxos。 mutli paxos优化的地方，或者说特点：
- 基于basic paxos的多proposer节点，增加了proposer的选举机制，只有唯一的leader proposer，所有的请求都经过leader proposer。避免了活锁的风险。
- 基于basic paxos的分布投票合并为一步。即proposer发起的投票请求中既包含投票id也包含投票内容，避免了两轮rpc请求，提高了效率。
mutli paxos基本流程
上图中上半部分为是未选出leader proposer节点的流程，下半部分是leader proposer节点存在并为超过任期的流程。
未选出leader proposer节点流程：
- proposer收到client请求后，向所有acceptor通知。
- 竞选leader通过后再发起真正的client消息请求投票。
leader proposer节点存在并在任期内流程：- 所有client请求消息经过leader proposer节点发起投票请求。
再一步简化，精简了角色
将proposer和acceptor合并，都是server的概念，由选举从集群中选出一个节点作为proposer，其他的节点作为acceptor进行工作。这个状态很接近raft一致性算法的思想。
