為什么需要一致性
數據不能存在單個節點（主機）上，否則可能出現單點故障。
多個節點（主機）需要保證具有相同的數據。
一致性算法就是為了解決上面兩個問題。
一致性算法的定義
一致性就是數據保持一致，在分布式系統中，可以理解為多個節點中數據的值是一致的。
一致性的分類
強一致性
說明：保證系統改變提交以后立即改變集群的狀態。
模型：
Paxos
Raft（muti-paxos）
ZAB（muti-paxos）
弱一致性
說明：也叫最終一致性，系統不保證改變提交以后立即改變集群的狀態，但是隨著時間的推移最終狀態是一致的。
模型：
DNS系統
Gossip協議
一致性算法實現舉例
Google的Chubby分布式鎖服務，采用了Paxos算法
etcd分布式鍵值數據庫，采用了Raft算法
ZooKeeper分布式應用協調服務，Chubby的開源實現，采用ZAB算法
Paxos算法
概念介紹
Proposal提案，即分布式系統的修改請求，可以表示為[提案編號N，提案內容value]
Client用戶，類似社會民眾，負責提出建議
Propser議員，類似基層人大代表，負責幫Client上交提案
Acceptor投票者，類似全國人大代表，負責為提案投票，不同意比自己以前接收過的提案編號要小的提案，其他提案都同意，例如A以前給N號提案表決過，那么再收到小于等于N號的提案時就直接拒絕了
Learner提案接受者，類似記錄被通過提案的記錄員，負責記錄提案
Basic Paxos算法
步驟
Propser準備一個N號提案
Propser詢問Acceptor中的多數派是否接收過N號的提案，如果都沒有進入下一步，否則本提案不被考慮
Acceptor開始表決，Acceptor無條件同意從未接收過的N號提案，達到多數派同意后，進入下一步
Learner記錄提案
在這里插入圖片描述

Basic Paxos算法
節點故障
若Proposer故障，沒關系，再從集群中選出Proposer即可
若Acceptor故障，表決時能達到多數派也沒問題
潛在問題-活鎖
假設系統有多個Proposer，他們不斷向Acceptor發出提案，還沒等到上一個提案達到多數派下一個提案又來了，就會導致Acceptor放棄當前提案轉向處理下一個提案，于是所有提案都別想通過了。
Multi Paxos算法
根據Basic Paxos的改進：整個系統只有一個Proposer，稱之為Leader。
步驟
若集群中沒有Leader，則在集群中選出一個節點并聲明它為第M任Leader。
集群的Acceptor只表決最新的Leader發出的最新的提案
其他步驟和Basic Paxos相同

Multi Paxos算法
算法優化
Multi Paxos角色過多，對于計算機集群而言，可以將Proposer、Acceptor和Learner三者身份集中在一個節點上，此時只需要從集群中選出Proposer，其他節點都是Acceptor和Learner，這就是接下來要討論的Raft算法
Raft算法
說明：Paxos算法不容易實現，Raft算法是對Paxos算法的簡化和改進
概念介紹
Leader總統節點，負責發出提案
Follower追隨者節點，負責同意Leader發出的提案
Candidate候選人，負責爭奪Leader

Raft算法中的角色
步驟：Raft算法將一致性問題分解為兩個的子問題，Leader選舉和狀態復制
Leader選舉
每個Follower都持有一個定時器

2.當定時器時間到了而集群中仍然沒有Leader，Follower將聲明自己是Candidate并參與Leader選舉，同時將消息發給其他節點來爭取他們的投票，若其他節點長時間沒有響應Candidate將重新發送選舉信息

集群中其他節點將給Candidate投票

獲得多數派支持的Candidate將成為第M任Leader（M任是最新的任期）

在任期內的Leader會不斷發送心跳給其他節點證明自己還活著，其他節點受到心跳以后就清空自己的計時器并回復Leader的心跳。這個機制保證其他節點不會在Leader任期內參加Leader選舉。

當Leader節點出現故障而導致Leader失聯，沒有接收到心跳的Follower節點將準備成為Candidate進入下一輪Leader選舉

若出現兩個Candidate同時選舉并獲得了相同的票數，那么這兩個Candidate將隨機推遲一段時間后再向其他節點發出投票請求，這保證了再次發送投票請求以后不沖突

狀態復制
Leader負責接收來自Client的提案請求（紅色提案表示未確認）

提案內容將包含在Leader發出的下一個心跳中

Follower接收到心跳以后回復Leader的心跳

Leader接收到多數派Follower的回復以后確認提案并寫入自己的存儲空間中并回復Client

Leader通知Follower節點確認提案并寫入自己的存儲空間，隨后所有的節點都擁有相同的數據

若集群中出現網絡異常，導致集群被分割，將出現多個Leader

被分割出的非多數派集群將無法達到共識，即腦裂，如圖中的A、B節點將無法確認提案

當集群再次連通時，將只聽從最新任期Leader的指揮，舊Leader將退化為Follower，如圖中B節點的Leader（任期1）需要聽從D節點的Leader（任期2）的指揮，此時集群重新達到一致性狀態

ZAB算法
說明：ZAB也是對Multi Paxos算法的改進，大部分和raft相同
和raft算法的主要區別：
對于Leader的任期，raft叫做term，而ZAB叫做epoch
在狀態復制的過程中，raft的心跳從Leader向Follower發送，而ZAB則相反。
Gossip算法
說明：Gossip算法每個節點都是對等的，即沒有角色之分。Gossip算法中的每個節點都會將數據改動告訴其他節點（類似傳八卦）。有話說得好：“最多通過六個人你就能認識全世界任何一個陌生人”，因此數據改動的消息很快就會傳遍整個集群。
步驟：
集群啟動，如下圖所示（這里設置集群有20個節點）

某節點收到數據改動，并將改動傳播給其他4個節點，傳播路徑表示為較粗的4條線

收到數據改動的節點重復上面的過程直到所有的節點都被感染

總結

以上是生活随笔為你收集整理的分布式一致性算法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。