Consensus Protocol（一致性協議）

Consul使用共識協議來提供一致性（由CAP定義）。共識協議基於“Raft：尋找可理解的共識演算法”。有關Raft的直觀解釋，請參閱資料的祕密生活。

Raft Protocol Overview（Raft協議概述）

Raft是一種基於Paxos的共識演算法。與Paxos相比，Raft被設計為具有更少的狀態和更簡單，更易理解的演算法。

討論Raft時需要了解一些關鍵術語：

Log -  Raft系統中的主要工作單元是日誌條目。一致性問題可以分解為複製日誌。日誌是有序的條目序列。如果所有成員就條目及其訂單達成一致，我們認為日誌是一致的。

FSM  - 有限狀態機。 FSM是有限狀態的集合，它們之間具有轉換。在應用新日誌時，允許FSM在狀態之間轉換。應用相同的日誌序列必須導致相同的狀態，這意味著行為必須是確定性的。

Peer Set - 對等集是參與日誌複製的所有成員的集合。出於Consul的目的，所有伺服器節點都位於本地資料中心的對等集中。

Quorum - 法定人數是來自同伴集的大多數成員：對於一組大小為n，法定人數至少需要（n / 2）+1個成員。例如，如果對等集中有5個成員，我們將需要3個節點來形成仲裁。如果法定數量的節點因任何原因不可用，則群集將變為不可用，並且不能提交新日誌。

Committed Entry

Leader - 在任何給定時間，對等集選擇單個節點作為領導者。領導者負責攝取新的日誌條目，複製到關注者，以及管理何時認為條目被提交。

Raft是一個複雜的協議，這裡不再詳述（對於那些需要更全面的治療的人，本文提供了完整的規範）。但是，我們將嘗試提供可用於構建心理模型的高階描述。

Raft節點總是處於以下三種狀態之一：關注者，候選者或領導者。所有節點最初都是作為關注者開始的。在此狀態下，節點可以接受來自領導者的日誌條目並投票。如果在一段時間內沒有收到任何條目，則節點會自我提升到候選狀態。在候選狀態中，節點請求來自其對等體的投票。如果候選人獲得了法定人數的票數，那麼它將被提升為領導者。領導者必須接受新的日誌條目並複製給所有其他關注者。此外，如果陳舊讀取不可接受，則還必須對領導者執行所有查詢。

一旦叢集具有領導者，它就能夠接受新的日誌條目。客戶端可以請求領導者附加新的日誌條目（從Raft的角度來看，日誌條目是不透明的二進位制blob）。然後，領導者將條目寫入持久儲存，並嘗試複製到法定數量的關注者。一旦認為日誌條目已提交，它就可以應用於有限狀態機。有限狀態機是特定於應用程式的;在Consul的案例中，我們使用MemDB來維護叢集狀態。 Consul的寫入塊直到它被提交和應用為止。當與查詢的一致模式一起使用時，這實現了寫後語義的讀取。

顯然，允許複製日誌以無限制的方式增長是不可取的。 Raft提供了一種機制，通過該機制可以快照當前狀態並壓縮日誌。由於FSM抽象，恢復FSM的狀態必然導致與舊日誌的重放相同的狀態。這允許Raft在某個時間點捕獲FSM狀態，然後刪除用於達到該狀態的所有日誌。這是在沒有使用者干預的情況下自動執行的，可以防止無限制的磁碟使用，同時還可以最大限使用MemDB的一個優點是，它允許Consul繼續接受新的事務，即使在舊狀態被快照時，也可以防止任何可用性問題。

達成一致性是容錯的，直到法定人數可用。如果法定數量的節點不可用，則無法處理日誌條目或關於對等成員資格的原因。例如，假設只有2個對等體：A和B.仲裁大小也是2，這意味著兩個節點必須同意提交日誌條目。如果A或B失敗，則現在無法達到法定人數。這意味著群集無法新增或刪除節點或提交任何其他日誌條目。這導致不可用。此時，需要手動干預才能刪除A或B，並在引導模式下重新啟動剩餘節點。

3個節點的Raft叢集可以容忍單個節點故障，而5個叢集可以容忍2個節點故障。建議的配置是為每個資料中心執行3或5個Consul伺服器。這可以最大限度地提高可用性，而不會大大降低效能。下面的部署表總結了潛在的群集大小選項以及每個選項的容錯能力。

在效能方面，Raft與Paxos相當。假設穩定的領導，提交日誌條目需要單程往返一半的叢集。因此，效能受磁碟I / O和網路延遲的約束。儘管Consul並非設計為高吞吐量寫入系統，但它應該按照每秒數百到數千個事務的順序處理，具體取決於網路和硬體配置。

Raft in Consul（Consul中的Raft）

只有Consul伺服器節點參與Raft並且是對等集的一部分。所有客戶端節點都將請求轉發給服務端。這種設計的部分原因是，隨著更多成員被新增到對等集中，仲裁的大小也會增加。這引入了效能問題，因為您可能正在等待數百臺計算機同意一個條目而不是少數條目。

入門時，單個Consul伺服器進入“bootstrap”模式。此模式允許它作為領導者自行選舉。選舉領導者後，可以以保持一致性和安全性的方式將其他伺服器新增到對等集。最後，一旦添加了幾個伺服器，就可以禁用載入程式模式。有關詳細資訊，請參閱本指南。

由於所有伺服器都作為對等集的一部分參與，因此他們都知道當前的領導者。當RPC請求到達非領導者伺服器時，請求將轉發給領導者。如果RPC是查詢型別，意味著它是隻讀的，則領導者將根據FSM的當前狀態生成結果。如果RPC是事務型別，意味著它修改狀態，則領導者生成新的日誌條目並使用Raft應用它。提交日誌條目並將其應用於FSM後，事務就完成了。

由於Raft複製的性質，效能對網路延遲很敏感。因此，每個資料中心選擇一個獨立的領導者並維護一個不相交的對等集。資料由資料中心分割槽，因此每個領導者僅負責其資料中心中的資料。收到遠端資料中心的請求後，請求將轉發給正確的領導者。此設計允許更低延遲的事務和更高的可用性，而不會犧牲一致性。

Consistency Modes（一致性模式）

雖然對複製日誌的所有寫入都通過Raft進行，但讀取更靈活。為了支援開發人員可能需要的各種權衡，Consul支援3種不同的讀取一致性模式。

三種讀取模式是：

default -  Raft利用領導租賃，提供領導者認為其角色穩定的時間視窗。但是，如果領導者與剩餘的同伴分開，則可以在舊領導者持有租約時選出新的領導者。這意味著有2個領導節點。由於舊的領導者無法提交新的日誌，因此不存在裂腦的風險。但是，如果舊的領導者為任何讀取提供服務，則這些值可能過時。預設一致性模式僅依賴於領導者租賃，將客戶端暴露給可能過時的值。我們做出這種權衡，因為讀取速度快，通常強烈一致，並且只在難以觸發的情況下過時。由於分割槽導致領導者下臺，因此陳舊讀取的時間視窗也是有限的。

consistent - 這種模式非常一致，沒有任何警告。它要求領導者與法定人數確認它仍然是領導者。這為所有伺服器節點引入了額外的往返。由於額外的往返，權衡總是一致讀取但延遲增加。

stale - 此模式允許任何伺服器為讀取服務，無論它是否是領導者。這意味著讀取可以是任意陳舊的，但通常在領導者的50毫秒內。權衡是非常快速和可擴充套件的讀取，但具有陳舊的值。此模式允許在沒有leader的情況下進行讀取，這意味著無法使用的群集仍然可以響應。

有關使用這些不同模式的更多文件，請參閱HTTP API。

Deployment Table（部署表）

下表顯示了各種群集大小的仲裁大小和容錯能力。 建議的部署是3或5臺伺服器。 由於在故障情況下資料丟失是不可避免的，因此非常不鼓勵單個伺服器部署。