几种常见的分布式一致性协议介绍

Zab

把节点分两种，Leader（主）和Follower（从）。 有一个主节点，全部写操做所有经过节点进行处理，若是一个从节点收到了一个写操做请求，就会转给主节点处理。 其余节点都是从节点，能够经过从节点进行读操做。 主节点经过选举得出，主节点失踪后，其余从节点自动开始选举新的主节点。

使用

• Zookeeper

参考

• Architecture of ZAB – ZooKeeper Atomic Broadcast protocol

Raft

Raft将一致性的问题分解为了三个问题：

• Leader Election：在Leader故障的时候，选出一个新的Leader。
• Log Replication：Leader须要让日志完整地复制到集群内的全部服务器
• Safety：若是某个服务器在特定的index提交了一个日志，那么不能有其它的服务器在相同的index提交日志，同一时刻只能保证有一个Leader。

1. 发现主节点失踪一段时间后，向全部从节点向其余从节点发消息，让他们选本身为新的主节点；
2. 还没参加选举的节点若是收到其余节点的选举请求，就选举本身收到的第一个节点，后面谁再请求本身支持选举，就告诉他们我已经支持另外一个节点了
3. 若是一个节点发现另外一个节点获得的支持比本身多，也就开始无条件支持那个节点选举，同时让支持本身的节点也去支持它
4. 若是一轮没选出来获得大多数节点支持的主节点，就开始下一轮选举，直到一个节点获得了大部分节点支持，成为新的主节点；

使用

• Redis使用了类Raft的算法
• TIDB

参考

• Understanding the Raft consensus algorithm: an academic article summary
• The Secret Lives of Data - Raft动画演示
• Raft 官网
• Raft 实现日志复制同步
• Redis Cluster Specification

Gossip

Gossip协议如其名，流行病协议，一个节点有状态须要更新到网络的其它节点的时候，它会随机的选择周围的几个节点散播消息，收到消息的节点会重复这个过程，直到网络中全部的节点都收到了消息。这个过程须要必定的时间，消息之间的传递具备必定的延迟性。可是理论上全部的节点都会收到全部的消息，所以它是一个最终一致性消息。

使用

• ElasticSearch在寻找Node时候使用了类Gossip的协议

参考

• P2P 网络核心技术：Gossip 协议
• Zen discovery

额外

Lease

Lease 是由颁发者授予的在某一有效期内的承诺。颁发者一旦发 出 lease，则不管接受方是否收到，也不管后续接收方处于何种状态，只要 lease 不过时，颁发者一 定严守承诺；另外一方面，接收方在 lease 的有效期内可使用颁发者的承诺，但一旦 lease 过时，接 收方必定不能继续使用颁发者的承诺。

最后

我对这些分布式协议目前了解的还不够透彻，后面再进行研究