paxos协议 对比_分布式一致性协议三部曲-深入理解一致性协议Paxos

CAP二阶段提交协议(2PC)协议详情改进缺陷参与者 还都处于锁定事务资源的状态中，而无法继续完成事务操。尽管协调者挂掉后可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题。三阶段提交(3PC)协议详情改进缺陷Paxos协议详情proxs的核心如何确定编号实例推演分析Paxos的落地中心化分布式一致性协议(Multi-Poxis, Zab, Raft)活锁优化多条数据记录同步优化Learn优化(数据确认)Leader模式"幽灵复现"问题Mutlti-Paxos下存在Leader切换情况，并且每个记录(Paxos实例)是完全独立的，因而是可能存在非顺序确认的，当然同一个Leader下日志是有顺序的，这个有点像多线程并发执行，同一个线程里的顺序是确定，线程之间的执行顺序谁知道呢？日志非顺序确认，就会出现客户端开始访问不到第7条记录，但是能访问到第20条记录，然后后面7确认后，客户端又能访问到第7条日志了。具体示例如下：去中心分布式一致性协议(PBFT)标准Paxos交互图带confirm的paxios交互图PBFT

从上面来看，一次提议需要5次交互，在中心化系统中，节点之间有专线连接，时延一般较低，可能还好。但在分布式系统中，节点之间可能分布在不同的个人设备上，时延往往较大，因而需要减少交互次数。PBFT实现上就是通过广播来减少交互次数的，即Acceptor不仅仅和proposer交互还和其他Acceptor交互。Basic-Paxos下，Accepter接收到的Accept消息是Proposer统计promise消息发出来的，在PBFT下，Acceptor之间互相广播promise消息，因而自己就可以统计自己收集到的promise消息，如果超过多数promise消息就可以直接accept并发出Accepted消息。

优化后的交互图

当然在PBFT里，这些交互过程名称有所变化。propose叫做pre-prepare, promise叫做prepare, accepted叫做commit, 当节点收到2/3*n+1各节点的commit即认为数据被confirm了，可以直接reply。

而区块链TenderMint里的PBFT协议里各个阶段的名字又不一样，propose这个名字是一样的，promise对应prevote, accepted对应precommit, 节点等到2/3*n+1个节点的precommit即认为数据被chosen(confirm), 执行commit将数据写入到区块里。

分布式一致性协议算是一个比较复杂的系统，需要多思考讨论，欢迎文章下面留言讨论

欢迎关注「一点码客」

更多关注微信公众号：jiuwenwang