Nomad使用共識協議來提供一致性(由CAP定義)。共識協議的基礎是“Raft:尋找一種可以理解的共識算法”。有關Raft的可視化解釋，請參見數據的秘密生命。

高級主題!這個頁面涵蓋了Nomad內部的技術細節。您不需要知道這些細節就可以有效地操作和使用Nomad。對于那些希望了解這些細節而不需要通過源代碼進行深入研究的人來說，這些細節在這里都有文檔說明。

Raft 協議概觀

---

Raft是一種基于Paxos的共識算法。與Paxos相比，Raft具有更少的狀態和更簡單、更容易理解的算法。

在討論Raft時，有幾個關鍵術語需要知道:

• 日志?- Raft系統的主要工作單元是日志條目。一致性問題可以分解為一個復制日志。日志是條目的有序序列。如果所有成員都同意條目及其順序，我們就認為日志是一致的。

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

• 對等組?- 對等組是參與日志復制的所有成員的集合。對于Nomad來說，所有服務端節點都位于本地區域的對等節點組中。

• 法定人數?- 法定人數的大部分成員從一個對等組:一組大小n,法定人數至少需要?(n / 2)+ 1?成員。例如，如果對等組中有5個成員，則需要3個節點來形成仲裁。如果由于任何原因，節點數量不可用，則集群不可用，并且不能提交新的日志。

• 提交條目?- 當條目持久存儲在法定人數上的節點時，就認為提交了條目。一旦提交了一個條目，就可以應用它。

• 領導者?- 在任何給定的時間，對等組只能選擇某一個節點作為領導者。領導者負責吸收新的日志條目，復制到追隨者中，并在認為提交了一個條目時進行管理。

Raft是一種復雜的協議，不會在這里詳細介紹(對于那些希望得到更全面了解的人，此文提供了完整的規范)。然而，我們將試圖提供一個高層次的描述，這可能對構建心理模型有用。

Raft節點總是處于以下三種狀態之一:追隨者、候選人或領導者。所有節點一開始都是追隨者。在這種狀態下，節點可以接受來自領導者的日志條目并進行投票。如果在一段時間內沒有收到條目，節點會自動提升到候選人狀態。在候選人狀態中，節點請求同伴的投票。如果一位候選人獲得法定人數的選票，那么他就被提升為領導者。領導者必須接受新的日志條目，并復制到所有其他追隨者。此外，如果不能接受陳舊的讀取，所有查詢也必須在領導者上執行。

Raft節點總是處于以下三種狀態之一:追隨者、候選人或領導者。所有節點一開始都是追隨者。在這種狀態下，節點可以接受來自領導者的日志條目并進行投票。如果在一段時間內沒有收到條目，節點會自動提升到候選人狀態。在候選人狀態中，節點請求同伴的投票。如果一位候選人獲得法定人數的選票，那么他就被提升為領導者。領導者必須接受新的日志條目，并復制到所有其他追隨者。此外，如果不能接受陳舊的讀取，所有查詢也必須在領導者上執行。

顯然，不希望允許復制日志以無限制的方式增長。Raft提供了一種機制，可以對當前狀態進行快照，并對日志進行壓縮。由于FSM抽象，恢復FSM的狀態必須與重放舊日志的狀態相同。這允許Raft在某個時間捕獲FSM狀態，然后刪除用于達到該狀態的所有日志。這是在沒有用戶干預的情況下自動執行的，可以防止無限的磁盤使用，同時還可以減少重放日志的時間。使用MemDB的優點之一是，它允許Nomad繼續接受新事務，即使舊的狀態被刪除，從而防止出現任何可用性問題。

在法定人數可用的范圍內，共識是容錯的。如果節點法定人數不可用，則不可能處理日志條目或考慮對等成員關系。例如，假設只有兩個對等節點:A和b。法定人數也是2，這意味著兩個節點必須同意提交一個日志條目。如果A或B失敗，現在就不可能達到法定人數。這意味著集群無法添加或刪除節點或提交任何其他日志條目。這導致了不可用。此時，需要手動干預以刪除A或B，并在引導模式下重新啟動剩余節點。

3個節點的Raft集群可以容忍單個節點故障，而5個節點的集群可以容忍2個節點故障。建議的配置是每個區域運行3個或5個Nomad服務器。這可以在不犧牲性能的情況下最大化可用性。下面的部署表總結了可能的集群大小選項和每個選項的容錯。

就性能而言，Raft與Paxos類似。假設具有穩定的領導能力，提交日志條目需要往返于集群的一半。因此，性能受磁盤I/O和網絡延遲的限制。

Nomad中的Raft

---

只有Nomad服務端節點參與到Raft中，并且是對等組的一部分。所有的客戶端節點將請求轉發給服務端。Nomad中的客戶端只需要知道它們的分配并從服務端查詢該信息，而服務端需要維護集群的全局狀態。

由于所有服務端都作為對等組的一部分參與，所以它們都知道當前的領導者。當RPC請求到達非領導者服務端時，請求被轉發給領導者。如果RPC是查詢類型(即只讀)，則領導者根據FSM的當前狀態生成結果。如果RPC是事務類型，意味著它修改狀態，那么領導者生成一個新的日志條目，并使用Raft應用它。一旦提交了日志條目并將其應用到FSM，事務就完成了。

由于Raft復制的特性，性能對網絡延遲很敏感。因此，每個區域選擇一個獨立的領導者并維護一個獨立的對等組。數據按區域劃分，所以每個領導者只對其區域中的數據負責。當接收到遠程區域的請求時，將該請求轉發給正確的領導者。這種設計允許更低的延遲事務和更高的可用性，而不會犧牲一致性。

一致性模式

盡管所有對復制日志的寫入都要通過Raft執行，但是讀取更靈活。為了支持開發人員可能需要的各種權衡，Nomad為讀取支持兩種不同的一致性模式。

這兩種讀取模式是:

• 默認模式?- Raft利用領導者租約，提供了一個時間窗口，讓領導者扮演穩定的角色。然而，如果一個領導者從其他領導者中分離出來，新領導者可能會被選舉出來，而老領導者則會持有租約。這意味著有兩個領導者節點。不存在腦裂的風險，因為以前的領導者將無法提交新的日志。但是，如果以前的領導者為任何讀取提供服務，那么這些值可能已經過時了。默認的一致性模式僅依賴于領導者租約，將客戶端暴露在潛在的舊值中。我們之所以這樣做，是因為讀起來很快，通常非常一致，而且只在難以觸發的情況下才會過時。陳舊讀取的時間窗口也是有限制的，因為領導者將因為分區而退休。

• 陳舊模式 - 這種模式允許任何服務端為讀服務，而不管它是否是領導者。這意味著讀取可以任意陳舊，但通常在領導者的50毫秒內。這種權衡是非?？焖俸涂缮炜s的讀取，但是使用陳舊的值。這種模式允許在沒有領導者的情況下讀取，這意味著不可用的集群仍然能夠響應。

部署表

---

下面是一個表，顯示了各種集群大小的法定人數大小和故障容忍度。建議部署3個或5個服務器。單個服務器部署非常不受歡迎，因為在故障場景中數據丟失是不可避免的

?

?

服務器法定人數故障容忍數

1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3

總結

以上是生活随笔為你收集整理的Nomad技术手册：共识协议（Consensus Protocol）的全部內容，希望文章能夠幫你解決所遇到的問題。

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