Raft Paper 簡譯

  本文是對 Raft Paper 核心部分的意譯,不包括原文中的以下章節:<3 Paxos 的優缺點論述>、<4 Raft 的易理解性介紹>、<9 Raft 算法的易理解性調研與性能評估>、<10 其它相似算法>、<12 致謝> 等,而且省略了多處學術論文的例行套話,力求言簡意駭,突出重點。
  爲求簡明,本文中提到的「日誌」均指「可複製日誌」,「狀態機」均指「可複製狀態機」。
  原文連接:https://raft.github.io/raft.pdfgit

概要

  Raft 是一種用於管理日誌的一致性算法。它的用途與 (multi-)Paxos 算法同樣,運行效率與之至關,但它的結構與 Paxos 不一樣;這使得 Raft 比 Paxos 更容易理解,同時也爲構建實際的系統打下了更好的基礎。
  爲加強可理解性,Raft 對共識算法的核心要素進行了拆分,例如領導者選舉、日誌複製及安全性保證等;爲減小系統可能處於的狀態總數量,Raft 強制執行一種更嚴苛的一致性策略。
  Raft 還包含了一種用於改變集羣成員關係的新算法,它經過「聯合多數」策略以保證安全性。github

1. 引言

  共識算法的用途,是容許多臺機器組成的集羣,就像一個單點實體同樣運行,其中的部分機器出現故障,不影響整個集羣的可用性;它們是構建大規模、高可用的軟件系統的核心要素之一。
  Paxos 算法的難以理解與實現困難,促使了 Raft 的誕生。咱們的目標不止是算法的正確性,並且要更清楚地展現它爲何能工做。
  Raft 與現存的共識算法具備不少的類似性,但它有以下幾個新特徵:
  - 強化的領導者角色:相比其它共識算法,Raft 使用了一種強化的領導關係。例如,日誌條目只能從領導者單向複製到其它機器;這簡化了日誌複製的邏輯,並使得 Raft 易於理解。
  - 領導者選舉:Raft 使用隨機計時器觸發選舉。這使得選舉衝突的解決簡單而高效,而代價僅僅是在全部共識算法都必需的心跳機制之上,增長了少量的邏輯。
  - 集羣成員變動:Raft 使用了一種叫作「聯合一致性」的方法來執行成員變動。在變動過程當中,任何操做都必須同時獲得兩套成員配置(<新,新|舊> OR <新|舊,新>)中的多數成員的支持,方能生效;這使得集羣在變動期間仍能對外提供正常的服務。
  本文的剩餘部分,將依次介紹狀態機問題(原文第 2 部分)、Raft 共識算法細節(原文第 5 至 8 部分)。算法

2. 狀態機

狀態機.png
  對共識算法的研究,一般沒法脫離狀態機的範疇。集羣中的每臺機器的狀態機,經過執行相同的日誌序列,將運算獲得一致的最終狀態;同時,即便其中的部分機器宕機,集羣仍能正常運行。
  狀態機用於解決分佈式系統中的各類容錯問題,一般使用日誌來實現,如 Figure 1 所示。集羣中的每臺機器都有一份存儲指令的日誌,供其狀態機按序執行。因爲全部機器的日誌都徹底相同,所以狀態機的執行結果是肯定的,它們將運算出一致的最終狀態,並獲得相同的輸出序列。
  共識算法的職責,就是保證全部日誌的一致性。
  一臺機器上的共識模塊,負責接收客戶端的指令,並將其追加到本身的日誌中;以後,它與集羣中的其它機器的共識模塊通訊,確保全部機器最終都獲得了徹底相同的日誌(即便其中某些機器中途宕機);日誌複製完成以後,每臺機器的狀態機將按序執行接收到的指令;最後將結果返回給客戶端。如此,整個集羣就表現爲一個渾然一體的、高可用的狀態機。
  實際系統中的共識算法,一般具備以下特性:
  - 除了「拜點庭將軍問題」外,任何場景下都不會返回錯誤的結果,例如網絡分區、延遲、丟包、重複、亂序等。
  - 當集羣中半數以上的機器可用,且互相之間及與客戶端之間通訊正常時,整個集羣處於徹底可用狀態;當故障機器恢復時,可從新加入集羣。
  - 不依靠計時機制保證日誌的一致性,由於錯誤的時鐘或極端的延遲會帶來問題。
  - 在大多數場景下,一旦對集羣中的大多數機器的 RPC 調用成功返回,便可斷定本次指令執行成功;少數的慢速機器不影響整個集羣的效率。安全

5. Raft 共識算法

概覽.png
核心特性.png
  Raft 是一種用於管理日誌的算法,Figure 2 對其做了歸納性的展現,Figure 3 則列出了它的核心特性,這些內容將在以後的章節中逐一介紹。
  Raft 實現一致性的方式是:首先選舉出一個集羣領導者,而後讓它全權管理日誌。領導者從客戶端接收日誌條目(也就是客戶端請求執行的指令),以後將其複製到其餘機器上,以後通知其它機器在各自的狀態機中執行該日誌。強化的領導者角色大大簡化了日誌的管理,因爲日誌的單向流動原則,領導者能夠獨自決定新的日誌條目放在什麼位置而不須要和其餘機器協商。領導者若宕機或斷網,一個新的很快就會被選舉出來。
  經過使用強化的領導者角色,Raft 將共識問題分解成了三個相對獨立的子問題,將分別在以後的子章節中介紹:
  - 領導者選舉:第 5.2 部分。
  - 日誌複製:第 5.3 部分。
  - 安全性:第 5.4 部分,另外,在 5.2 部分中提到了一個在選舉時須要遵循的額外限制條件。網絡

  在介紹完共識算法以後,本章節還會涉及到系統可用性以及時序在其中扮演的角色等話題。分佈式

  發現一篇翻譯質量尚可的既存文章,後續部分請點擊此處查看;待往後時間充裕,再精修本文。性能

相關文章
相關標籤/搜索