深入浅出理解分布式一致性Paxos算法( 二 ) _Paxos算法

Acceptor： Acceptor收到accept请求后，分为两种情况：

Proposer： Proposer收到ok超过半数，则V被选定，否则重新发起Prepare请求。
第三阶段: Learn学习阶段
Learner: Proposer收到多数Acceptor的Accept后，决议形成，将形成的决议发送给所有Learner 。

文章插图

Paxos应用案例前面讲述了paxos算法细节，可能你还是不明白paxos算法在实际场景中有什么用处，我们现在讲个实际的使用案例。
我们以一个分布式的KV数据库为例，分析Paxos的应用场景。

文章插图

3个server组成一个分布式内存数据库，他们的状态必须保持同步，也就是每个server 节点都需要维护有顺序的操作日志，同时保持一致。

+---+-------------+|1|Put("a", 1)|+---+-------------+|2|Put("b", 2)|+---+-------------+|3|Put("c", 3)|+---+-------------+

多个客户端并发在发送请求的时候，服务端多个节点需要协商，选择其中一个大家都认可的数据(指令), 存入到操作表中，这里协商确定指令的过程就是Paxos 。
比如我们将paxos算法封装到下面的方法中：
Op doPaxos(int seq, Op v){...}以上面图示的例子详细分下这个过程：

Cient2向集群发送了请求Put("b", 2),假设这个请求最终到了server1上。
Client3向集群发送了请求Put("c", 3), 假设这个求情发到了server2上。
server2调用doPaxos函数进行协商，即询问集群中的所有server咱们的第2个操作能否为Put("c", 2)
此时server3也调用doPaxos函数进行协商，即询问集群中的所有server咱们的第2个操作能否为Put("c", 3)
这是Paxos只会选择其中1个提案，我们这里假设server2的议题最终被通过了，集群中所有server的状态表都新增Put("c", 2)
server3发现自己的提案没有选中，他会对自己的database进行Put("b", 2)操作，然后重新升级提案编号，再次调用doPaxos方法，直到自己的提案被通过。

总结Paxos算法还是挺难以理解的，如果对整个推导过程感兴趣的话，可以阅读Lamport的原文。
根据前面讲述的Paxos算法流程，不知道大家有没有发现一个问题，如果两个Propser依次提出编号递增的提案，最终回陷入死循环，进入死锁状态，如下图：