案例：投票选出最新的报价
单个Processor的情况
Processor：小明
Acceptor：审批人1；审批人2；审批人3；
Learner：记录者
业务背景：选出最新的报价
步骤：
- 小明：发起两个prepare请求，里面带一个编号，分别给审批人1和审批人2。这一步的目的是看看是否能得到审批人的认可。
- 审批人：如果之前没有接收到prepare请求或者已接收到的prepare请求的编号小于当前prepare请求的编号，那么就承诺此编号1。
- 小明：获取到多数（超过半数）审批人的认可后，分别发起accept请求，并且附带最新报价“1.5”。
- 审批人：判断编号accept请求中的编号（1）是否小于已承诺的编号（1）
如果小于：则放弃accept请求中的值
1. 如果大（等）于：同意最新报价“1.5”，并且发送给小明和记录者
2. 记录者：记录最新报价“1.5”
多个Processor的情况
Processor：小明；小红；
Acceptor：审批人1；审批人2；审批人3；
Learner：记录者
业务背景：选出最新的报价
步骤：
1. 小明：发起prepare请求，附带编号：1
1.1 发给审批人1：审批人1发现自己从没有接收过请求，所以承认了编号：1，（并承诺再也不会接受编号小于1的请求）
1.2 发给审批人2：审批人2发现自己已经接收了编号为2的请求，因此不会接受编号为1的请求，因为：2>1
2. 小红：发起prepare请求，附带编号：2
2.1 发给审批人2：审批人2发现自己从没有接收过请求，所以承认了编号：2（并承诺再也不会接受编号小于2的请求）
2.2 发给审批人3：审批人3发现自己从没有接收过请求，所以承认了编号：2（并承诺再也不会接受编号小于2的请求）
3. 小红：发起accept请求，附带值：2.5
3.1 发给审批人2：审批人2并未发现编号大于2的请求，因此接受值：2.5
3.2 发给审批人3：审批人3并未发现编号大于2的请求，因此接受值：2.5
4. 小明：发起prepare请求，附带编号：3
4.1 发给审批人1：审批人1发现自己已经接收过请求，但是之前接收到的编号（1）小于当前的编号（3），因此承诺编号：3
4.2 发给审批人2：审批人1发现自己已经接收过请求，但是之前接收到的编号（2）小于当前的编号（3），3>2，因此承诺编号：3；
5. 小明：发起accept请求，附带值：5.5
5.1 发给审批人1：审批人1并未发现编号大于3的请求，因此接受值：5.5
5.2 发给审批人2：审批人2并未发现编号大于3的请求，因此接受值：5.5
最后
1. 审批人1：5.5
2. 审批人2：5.5
3. 审批人3：2.5
由于多数原则，返回值：5.5
死锁的情况（multi-paxos）
Processor：小明；小红；
Acceptor：审批人1；审批人2；审批人3；
Learner：记录者
步骤：
- 小明发起prepare请求给审批人1和审批人2，附带编码：1，并得到审批人的承诺
- 小红发起prepare请求给审批人1和审批人2，附带编码：2，并得到审批人的承诺
- 小明发起accept请求给审批人1和审批人2，附带值：1.5，被审批人忽略，因为：2>1
- 小明发起prepare请求给审批人1和审批人2，附带编码：3，并得到审批人的承诺
- 小明发起accept请求给审批人1和审批人2，附带值：2.5，被审批人忽略，因为：3>2
- ... ... 然后不断循环，形成死锁