幾種常見的分佈式一致性協議介紹

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 過時，接 收方必定不能繼續使用頒發者的承諾。

最後

我對這些分佈式協議目前瞭解的還不夠透徹，後面再進行研究