Paxos
Paxos
节点角色
- Proposer：用于接收客户端的请求，客户端的请求到达 Proposer 之后，它会将这个请求封装为提案，然后把这个提案广播给所有的 Acceptor。
- Acceptor：决定是否批准提案，会给 Proposer 返回一个类似于 yes or no 的响应。Proposer 根据响应情况决定是否要执行下一阶段。
- Learner：用于获得一个已达成共识的提案，然后将它输入到状态机。
提案
- Value：提案的值
- Number：提案编号
prepare 阶段
- prepare(N)请求：Proposer 提出一个提案，编号为 N（编号是递增的），向所有的 Acceptor 广播，注意这里只发送编号没有内容。当 Proposer 收到集群中大多数的 Acceptor 的同意之后，它拥有本轮提出提案的所有权，可以进入 Accept 阶段。
- promist(n, value)返回：Acceptor 在收到 prepare 请求时，如果 N 大于该 Acceptor 此前接收的所有提案编号就接收（并承诺不再接收比 N 小的提议），并且如果该 Acceptor 存在已经同意的提案（经过第二阶段 Accept 的提案），返回这个提案的编号和内容，否则返回空值表示接收即可。
accept 阶段
- accept(N,value)请求：Proposer 收到多数派的响应，从 prepare 响应中选取提案编号最大的 value 作为本次提交的值。如果响应中不包含任何提案，那么 value 就由 Proposer 决定。
- accepted（N）返回：Acceptor 在接收到一个编号为 N 的提案的 Accept 请求时，如果在此期间没有任何编号大于 N 的提案，就接受提案内容否则就拒绝。当 Proposer 收到超过半数的 Acceptor 的响应后，提案达成共识，否则 Proposer 会重新进入第一阶段，递增提案编号，重新发出 Prepare 请求。
存在的问题
活锁
效率问题
一个提案要达成共识的话，需要经过两轮的协商，即四轮的消息交互。
Multi paxos 的优化
- 引入 leader，只能由 leader 发起提案，减少活锁的概率。
- 优化 prepare 阶段，在没有提案冲突的情况下，优化成一阶段。
参考
