RAFT 論文中文翻譯(2)

本篇博客爲著名的 RAFT 一致性算法論文的中文翻譯，論文名爲《In search of an Understandable Consensus Algorithm (Extended Version)》(尋找一種易於理解的一致性算法)

9 實現和評價

我們已經爲 RAMCloud 實現了 Raft 算法作爲存儲配置信息的複製狀態機的一部分，並且幫助 RAMCloud 協調故障轉移。這個 Raft 實現包含大約 2000 行 C++ 代碼，其中不包括測試、註釋和空行。這些代碼是開源的。同時也有大約 25 個其他獨立的第三方的基於這篇論文草稿的開源實現，針對不同的開發場景。同時，很多公司已經部署了基於 Raft 的系統。

這一章會從三個方面來評估 Raft 算法：可理解性、正確性和性能。

9.1 可理解性

爲了比較 Paxos 和 Raft 算法的可理解性，我們針對高層次的本科生和研究生，在斯坦福大學的高級操作系統課程和加州大學伯克利分校的分佈式計算課程上，進行了一次學習的實驗。我們分別拍了針對 Raft 和 Paxos 的視頻課程，並準備了相應的小測驗。Raft 的視頻講課覆蓋了這篇論文除了日誌壓縮之外的所有內容；Paxos 課程包含了足夠的資料來創建一個等價的複製狀態機，包括單決策 Paxos，多決策 Paxos，重新配置和一些實際系統需要的性能優化（例如領導人選舉）。小測驗測試一些對算法的基本理解和解釋一些示例。每個學生都是看完第一個視頻，回答相應的測試，再看第二個視頻，回答相應的測試。大約有一半的學生先進行 Paxos 部分，然後另一半先進行 Raft 部分，這是爲了說明兩者獨立的區別從第一個算法處學來的經驗。我們計算參加人員的每一個小測驗的得分來看參與者是否對 Raft 的理解更好。

因素	消除偏見的手段	複習材料
相同的講課質量	使用相同的講師。Paxos 的講義是基於之前在幾所大學中使用的材料的並且做了改進。Paxos 的講義要長 14%	視頻
相同的測試難度	用難度給問題分組，在測試中成對出現	測驗
公平的打分	使用紅字標題。隨機順序打分，兩個測驗交替進行。	紅字標題

表-1：考慮到的可能造成偏見的因素，以及解決方案和對應的複習材料

我們儘可能的使得 Paxos 和 Raft 的比較更加公平。這個實驗偏愛 Paxos 表現在兩個方面：43 個參加者中有 15 個人在之前有一些 Paxos 的經驗，並且 Paxos 的視頻要長 14%。如表-1 總結的那樣，我們採取了一些措施來減輕這種潛在的偏見。我們所有的材料都可供審查。

圖-14：表示了 43 個學生在 Paxos 和 Raft 的小測驗中的成績的散點圖。在對角線之上的點表示在 Raft 獲得了更高分數的學生。

參加者平均在 Raft 的測驗中比 Paxos 高 4.9 分（總分 60，那麼 Raft 的平均得分是 25.7，而 Paxos 是 20.8）；圖-14 展示了每個參與者的得分。一對 t -測試表明，擁有 95% 的可信度，真實的 Raft 分數分佈至少比 Paxos 高 2.5 分。

我們也建立了一個線性迴歸模型來預測一個新的學生的測驗成績，基於以下三個因素：他們使用的是哪個小測驗，之前對 Paxos 的經驗，和學習算法的順序。模型顯示，對小測驗的選擇會產生 12.5 分的差別在對 Raft 的好感度上。這顯著的高於之前的 4.9 分，因爲很多學生在之前都已經有了對於 Paxos 的經驗，這相當明顯的幫助 Paxos，對 Raft 就沒什麼太大影響了。但是奇怪的是，模型預測對於先進行 Paxos 小測驗的人而言，Raft 的小測驗得分會比 Paxos 低 6.3 分；我們不知道爲什麼，但這在統計學上是這樣的。

圖-15：通過一個 5 分制的問題，參與者（左邊）被問哪個算法他們覺得在一個高效正確的系統裏更容易實現，右邊被問哪個更容易向學生解釋。

我們同時也在測驗之後調查了參與者，他們認爲哪個算法更加容易實現和解釋；這個的結果在圖-15 上。壓倒性的結果表明 Raft 算法更加容易實現和解釋（41 人中的 33個）。但是，這種自己報告的結果不如參與者的成績更加可信，並且參與者可能因爲我們的 Raft 更加易於理解的假說而產生偏見。

關於 Raft 用戶學習有一個更加詳細的討論，詳見[http://ramcloud.stanford.edu/ ̃ongaro/thesis.pdf](http://ramcloud.stanford.edu/ ̃ongaro/thesis.pdf)

9.2 正確性

在第5章，我們已經進行了一個[正式的說明](http://ramcloud.stanford.edu/ ̃ongaro/thesis.pdf)，和對一致性機制的安全性證明。這個正式說明通過 TLA+ 讓 表-2 中的信息非常清晰。它大約有 400 行並且充當了證明的主題。同時對於任何想實現的人也是十分有用的。我們非常機械的通過 TLA 證明系統證明了日誌完全特性（Log Completeness Property）。然而，這個證明依賴的約束前提還沒有被機械證明（例如，我們還沒有證明這個說明中的類型安全 type safety）。而且，我們已經寫了一個[非正式的證明](http://ramcloud.stanford.edu/ ̃ongaro/thesis.pdf)關於狀態機安全性質是完備的，並且是相當清晰的（大約 3500 個詞）。

9.3 性能

Raft 和其他一致性算法例如 Paxos 有着差不多的性能。在性能方面，最重要的關注點是，當領導人被選舉成功時，什麼時候複製新的日誌條目。Raft 通過很少數量的消息包（一輪從領導人到集羣大多數機器的消息）就達成了這個目的。同時，進一步提升 Raft 的性能也是可行的。例如，很容易通過支持批量操作和管道操作來提高吞吐量和降低延遲。對於其他一致性算法已經提出過很多性能優化方案；其中有很多也可以應用到 Raft 中來，但是我們暫時把這個問題放到未來的工作中去。

我們使用我們自己的 Raft 實現來衡量 Raft 領導人選舉的性能並且回答以下兩個問題。首先，領導人選舉的過程收斂是否快速？第二，在領導人宕機之後，最小的系統宕機時間是多久？

圖-16：發現並替換一個已經崩潰的領導人的時間。上面的圖考察了在選舉超時時間上的隨機化程度，下面的圖考察了最小超時時間。每條線代表了 1000 次實驗（除了 150-150 毫秒只試了 100 次），和相應的確定的選舉超時時間。例如，150-155 毫秒意思是，選舉超時時間從這個區間範圍內隨機選擇並確定下來。這個實驗在一個擁有 5 個節點的集羣上進行，其廣播時延大約是 15 毫秒。對於 9 個節點的集羣，結果也差不多。

爲了衡量領導人選舉，我們反覆的使一個擁有五個節點的服務器集羣的領導人宕機，並計算需要多久才能發現領導人已經宕機並選出一個新的領導人（見圖-16）。爲了構建一個最壞的場景，在每一的嘗試裏，服務器都有不同長度的日誌，意味着有些候選人是沒有成爲領導人的資格的。另外，爲了促成選票瓜分的情況，我們的測試腳本在終止領導人之前同步的發送了一次心跳廣播（這大約和領導人在崩潰前複製一個新的日誌給其他機器很像）。領導人均勻的隨機的在心跳間隔裏宕機，也就是最小選舉超時時間的一半。因此，最小宕機時間大約就是最小選舉超時時間的一半。

圖-16 上面的圖表表明，只需要在選舉超時時間上使用很少的隨機化就可以大大避免選票被瓜分的情況。在沒有隨機化的情況下，在我們的測試裏，選舉過程由於太多的選票瓜分的情況往往都需要花費超過 10 秒鐘。僅僅增加 5 毫秒的隨機化時間，就大大的改善了選舉過程，現在平均的宕機時間只有 287 毫秒。增加更多的隨機化時間可以大大改善最壞情況：通過增加 50 毫秒的隨機化時間，最壞的完成情況（1000 次嘗試）只要 513 毫秒。

圖-16 中下面的圖顯示，通過減少選舉超時時間可以減少系統的宕機時間。在選舉超時時間爲 12-24 毫秒的情況下，只需要平均 35 毫秒就可以選舉出新的領導人（最長的一次花費了 152 毫秒）。然而，進一步降低選舉超時時間的話就會違反 Raft 的時間不等式需求：在選舉新領導人之前，領導人就很難發送完心跳包。這會導致沒有意義的領導人改變並降低了系統整體的可用性。我們建議使用更爲保守的選舉超時時間，比如 150-300 毫秒；這樣的時間不大可能導致沒有意義的領導人改變，而且依然提供不錯的可用性。

10 相關工作

已經有很多關於一致性算法的工作被發表出來，其中很多都可以歸到下面的類別中：

• Lamport 關於 Paxos 的原始描述，和嘗試描述的更清晰的論文。
• 關於 Paxos 的更詳盡的描述，補充遺漏的細節並修改算法，使得可以提供更加容易的實現基礎。
• 實現一致性算法的系統，例如 Chubby，ZooKeeper 和 Spanner。對於 Chubby 和 Spanner 的算法並沒有公開發表其技術細節，儘管他們都聲稱是基於 Paxos 的。ZooKeeper 的算法細節已經發表，但是和 Paxos 有着很大的差別。
• Paxos 可以應用的性能優化。
• Oki 和 Liskov 的 Viewstamped Replication（VR），一種和 Paxos 差不多的替代算法。原始的算法描述和分佈式傳輸協議耦合在了一起，但是核心的一致性算法在最近的更新裏被分離了出來。VR 使用了一種基於領導人的方法，和 Raft 有很多相似之處。

Raft 和 Paxos 最大的不同之處就在於 Raft 的強領導特性：Raft 使用領導人選舉作爲一致性協議裏必不可少的部分，並且將儘可能多的功能集中到了領導人身上。這樣就可以使得算法更加容易理解。例如，在 Paxos 中，領導人選舉和基本的一致性協議是正交的：領導人選舉僅僅是性能優化的手段，而且不是一致性所必須要求的。但是，這樣就增加了多餘的機制：Paxos 同時包含了針對基本一致性要求的兩階段提交協議和針對領導人選舉的獨立的機制。相比較而言，Raft 就直接將領導人選舉納入到一致性算法中，並作爲兩階段一致性的第一步。這樣就減少了很多機制。

像 Raft 一樣，VR 和 ZooKeeper 也是基於領導人的，因此他們也擁有一些 Raft 的優點。但是，Raft 比 VR 和 ZooKeeper 擁有更少的機制因爲 Raft 儘可能的減少了非領導人的功能。例如，Raft 中日誌條目都遵循着從領導人發送給其他人這一個方向：附加條目 RPC 是向外發送的。在 VR 中，日誌條目的流動是雙向的（領導人可以在選舉過程中接收日誌）；這就導致了額外的機制和複雜性。根據 ZooKeeper 公開的資料看，它的日誌條目也是雙向傳輸的，但是它的實現更像 Raft。

和上述我們提及的其他基於一致性的日誌複製算法中，Raft 的消息類型更少。例如，我們數了一下 VR 和 ZooKeeper 使用的用來基本一致性需要和成員改變的消息數（排除了日誌壓縮和客戶端交互，因爲這些都比較獨立且和算法關係不大）。VR 和 ZooKeeper 都分別定義了 10 中不同的消息類型，相對的，Raft 只有 4 中消息類型（兩種 RPC 請求和對應的響應）。Raft 的消息都稍微比其他算法的要信息量大，但是都很簡單。另外，VR 和 ZooKeeper 都在領導人改變時傳輸了整個日誌；所以爲了能夠實踐中使用，額外的消息類型就很必要了。

Raft 的強領導人模型簡化了整個算法，但是同時也排斥了一些性能優化的方法。例如，平等主義 Paxos （EPaxos）在某些沒有領導人的情況下可以達到很高的性能。平等主義 Paxos 充分發揮了在狀態機指令中的交換性。任何服務器都可以在一輪通信下就提交指令，除非其他指令同時被提出了。然而，如果指令都是併發的被提出，並且互相之間不通信溝通，那麼 EPaxos 就需要額外的一輪通信。因爲任何服務器都可以提交指令，所以 EPaxos 在服務器之間的負載均衡做的很好，並且很容易在 WAN 網絡環境下獲得很低的延遲。但是，他在 Paxos 上增加了非常明顯的複雜性。

一些集羣成員變換的方法已經被提出或者在其他的工作中被實現，包括 Lamport 的原始的討論，VR 和 SMART。我們選擇使用共同一致（joint consensus）的方法因爲它對一致性協議的其他部分影響很小，這樣我們只需要很少的一些機制就可以實現成員變換。Raft 沒有采用 Lamport 的基於 α 的方法是因爲它假設在沒有領導人的情況下也可以達到一致性。和 VR 和 SMART 相比較，Raft 的重新配置算法可以在不限制正常請求處理的情況下進行；相比較而言，VR 需要停止所有的處理過程，SMART 引入了一個和 α 類似的方法，限制了請求處理的數量。和 VR、SMART 比較而言，Raft 的方法同時需要更少的額外機制來實現。

11 總結

算法的設計通常會把正確性，效率或者簡潔作爲主要的目標。儘管這些都是很有意義的目標，但是我們相信，可理解性也是一樣的重要。在開發者把算法應用到實際的系統中之前，這些目標沒有一個會被實現，這些都會必然的偏離發表時的形式。除非開發人員對這個算法有着很深的理解並且有着直觀的感覺，否則將會對他們而言很難在實現的時候保持原有期望的特性。

在這篇論文中，我們嘗試解決分佈式一致性問題，但是一個廣爲接受但是十分令人費解的算法 Paxos 已經困擾了無數學生和開發者很多年了。我們創造了一種新的算法 Raft，顯而易見的比 Paxos 要容易理解。我們同時也相信，Raft 也可以爲實際的實現提供堅實的基礎。把可理解性作爲設計的目標改變了我們設計 Raft 的方式；這個過程是我們發現我們最終很少有技術上的重複，例如問題分解和簡化狀態空間。這些技術不僅提升了 Raft 的可理解性，同時也使我們堅信其正確性。

12 鳴謝

這項研究必須感謝以下人員的支持：Ali Ghodsi，David Mazie`res，和伯克利 CS 294-91 課程、斯坦福 CS 240 課程的學生。Scott Klemmer 幫我們設計了用戶調查，Nelson Ray 建議我們進行統計學的分析。在用戶調查時使用的關於 Paxos 的幻燈片很大一部分是從 Lorenzo Alvisi 的幻燈片上借鑑過來的。特別的，非常感謝 DavidMazieres 和 Ezra Hoch，他們找到了 Raft 中一些難以發現的漏洞。許多人提供了關於這篇論文十分有用的反饋和用戶調查材料，包括 Ed Bugnion，Michael Chan，Hugues Evrard，Daniel Giffin，Arjun Gopalan，Jon Howell，Vimalkumar Jeyakumar，Ankita Kejriwal，Aleksandar Kracun，Amit Levy，Joel Martin，Satoshi Matsushita，Oleg Pesok，David Ramos，Robbert van Renesse，Mendel Rosenblum，Nicolas Schiper，Deian Stefan，Andrew Stone，Ryan Stutsman，David Terei，Stephen Yang，Matei Zaharia 以及 24 位匿名的會議審查人員（可能有重複），並且特別感謝我們的領導人 Eddie Kohler。Werner Vogels 發了一條早期草稿鏈接的推特，給 Raft 帶來了極大的關注。我們的工作由 Gigascale 系統研究中心和 Multiscale 系統研究中心給予支持，這兩個研究中心由關注中心研究程序資金支持，一個是半導體研究公司的程序，由 STARnet 支持，一個半導體研究公司的程序由 MARCO 和 DARPA 支持，在國家科學基金會的 0963859 號批准，並且獲得了來自 Facebook，Google，Mellanox，NEC，NetApp，SAP 和 Samsung 的支持。Diego Ongaro 由 Junglee 公司，斯坦福的畢業團體支持。

引用

1. BOLOSKY, W. J., BRADSHAW, D., HAAGENS, R. B., KUSTERS, N. P., AND LI, P. Paxos replicated state machines as the basis of a high-performance data store. In Proc. NSDI’11, USENIX Conference on Networked Systems Design and Implementation (2011), USENIX, pp. 141–154.
2. BURROWS, M. The Chubby lock service for loosely- coupled distributed systems. In Proc. OSDI’06, Sympo- sium on Operating Systems Design and Implementation (2006), USENIX, pp. 335–350.
3. CAMARGOS, L. J., SCHMIDT, R. M., AND PEDONE, F. Multicoordinated Paxos. In Proc. PODC’07, ACM Sym- posium on Principles of Distributed Computing (2007), ACM, pp. 316–317.
4. CHANDRA, T. D., GRIESEMER, R., AND REDSTONE, J. Paxos made live: an engineering perspective. In Proc. PODC’07, ACM Symposium on Principles of Distributed Computing (2007), ACM, pp. 398–407.
5. CHANG, F., DEAN, J., GHEMAWAT, S., HSIEH, W. C., WALLACH, D. A., BURROWS, M., CHANDRA, T., FIKES, A., AND GRUBER, R. E. Bigtable: a distributed storage system for structured data. In Proc. OSDI’06, USENIX Symposium on Operating Systems Design and Implementation (2006), USENIX, pp. 205–218.
6. CORBETT, J. C., DEAN, J., EPSTEIN, M., FIKES, A., FROST, C., FURMAN, J. J., GHEMAWAT, S., GUBAREV, A., HEISER, C., HOCHSCHILD, P., HSIEH, W., KAN- THAK, S., KOGAN, E., LI, H., LLOYD, A., MELNIK, S., MWAURA, D., NAGLE, D., QUINLAN, S., RAO, R., ROLIG, L., SAITO, Y., SZYMANIAK, M., TAYLOR, C., WANG, R., AND WOODFORD, D. Spanner: Google’s globally-distributed database. In Proc. OSDI’12, USENIX Conference on Operating Systems Design and Implemen- tation (2012), USENIX, pp. 251–264.
7. COUSINEAU, D., DOLIGEZ, D., LAMPORT, L., MERZ, S., RICKETTS, D., AND VANZETTO, H. TLA+ proofs. In Proc. FM’12, Symposium on Formal Methods (2012), D. Giannakopoulou and D. Me ́ry, Eds., vol. 7436 of Lec- ture Notes in Computer Science, Springer, pp. 147–154.
8. GHEMAWAT, S., GOBIOFF, H., AND LEUNG, S.-T. The Google file system. In Proc. SOSP’03, ACM Symposium on Operating Systems Principles (2003), ACM, pp. 29–43.
9. GRAY,C.,ANDCHERITON,D.Leases:Anefficientfault- tolerant mechanism for distributed file cache consistency. In Proceedings of the 12th ACM Ssymposium on Operating Systems Principles (1989), pp. 202–210.
10. HERLIHY, M. P., AND WING, J. M. Linearizability: a correctness condition for concurrent objects. ACM Trans- actions on Programming Languages and Systems 12 (July 1990), 463–492.
11. HUNT, P., KONAR, M., JUNQUEIRA, F. P., AND REED, B. ZooKeeper: wait-free coordination for internet-scale systems. In Proc ATC’10, USENIX Annual Technical Con- ference (2010), USENIX, pp. 145–158.
12. JUNQUEIRA, F. P., REED, B. C., AND SERAFINI, M. Zab: High-performance broadcast for primary-backup sys- tems. In Proc. DSN’11, IEEE/IFIP Int’l Conf. on Depend- able Systems & Networks (2011), IEEE Computer Society, pp. 245–256.
13. KIRSCH, J., AND AMIR, Y. Paxos for system builders. Tech. Rep. CNDS-2008-2, Johns Hopkins University, 2008.
14. LAMPORT, L. Time, clocks, and the ordering of events in a distributed system. Commununications of the ACM 21, 7 (July 1978), 558–565.
15. LAMPORT, L. The part-time parliament. ACM Transac- tions on Computer Systems 16, 2 (May 1998), 133–169.
16. LAMPORT, L. Paxos made simple. ACM SIGACT News 32, 4 (Dec. 2001), 18–25.
17. LAMPORT, L. Specifying Systems, The TLA+ Language and Tools for Hardware and Software Engineers. Addison- Wesley, 2002.
18. LAMPORT, L. Generalized consensus and Paxos. Tech. Rep. MSR-TR-2005-33, Microsoft Research, 2005.
19. LAMPORT, L. Fast paxos. Distributed Computing 19, 2 (2006), 79–103.
20. LAMPSON, B. W. How to build a highly available system using consensus. In Distributed Algorithms, O. Baboaglu and K. Marzullo, Eds. Springer-Verlag, 1996, pp. 1–17.
21. LAMPSON, B. W. The ABCD’s of Paxos. In Proc. PODC’01, ACM Symposium on Principles of Distributed Computing (2001), ACM, pp. 13–13.
22. LISKOV, B., AND COWLING, J. Viewstamped replica- tion revisited. Tech. Rep. MIT-CSAIL-TR-2012-021, MIT, July 2012.
23. LogCabin source code. logcabin/logcabin.
24. LORCH, J. R., ADYA, A., BOLOSKY, W. J., CHAIKEN, R., DOUCEUR, J. R., AND HOWELL, J. The SMART way to migrate replicated stateful services. In Proc. Eu- roSys’06, ACM SIGOPS/EuroSys European Conference on Computer Systems (2006), ACM, pp. 103–115.
25. MAO, Y., JUNQUEIRA, F. P., AND MARZULLO, K. Mencius: building efficient replicated state machines for WANs. In Proc. OSDI’08, USENIX Conference on Operating Systems Design and Implementation (2008), USENIX, pp. 369–384.
26. MAZIE` RES, D. Paxos made practical.http://www.scs.stanford.edu/~dm/home/papers/paxos.pdf , Jan. 2007.
27. MORARU, I., ANDERSEN, D. G., AND KAMINSKY, M. There is more consensus in egalitarian parliaments. In Proc. SOSP’13, ACM Symposium on Operating System Principles (2013), ACM.
28. Raft user study. http://ramcloud.stanford.edu/~ongaro/userstudy/.
29. OKI, B. M., AND LISKOV, B. H. Viewstamped replication: A new primary copy method to support highly-available distributed systems. In Proc. PODC’88, ACM Symposium on Principles of Distributed Computing (1988), ACM, pp. 8–17.
30. O’NEIL, P., CHENG, E., GAWLICK, D., AND ONEIL, E. The log-structured merge-tree (LSM-tree). Acta Informat- ica 33, 4 (1996), 351–385.
31. ONGARO, D. Consensus: Bridging Theory and Practice. PhD thesis, Stanford University, 2014 (work in progress).http://ramcloud.stanford.edu/~ongaro/thesis.pdf
32. ONGARO, D., AND OUSTERHOUT, J. In search of an understandable consensus algorithm. In Proc ATC’14, USENIX Annual Technical Conference (2014), USENIX.
33. OUSTERHOUT, J., AGRAWAL, P., ERICKSON, D., KOZYRAKIS, C., LEVERICH, J., MAZIE`RES, D., MI- TRA, S., NARAYANAN, A., ONGARO, D., PARULKAR, G., ROSENBLUM, M., RUMBLE, S. M., STRATMANN, E., AND STUTSMAN, R. The case for RAMCloud. Com- munications of the ACM 54 (July 2011), 121–130.
34. Raft consensus algorithm website. http://raftconsensus.github.io.
35. REED, B. Personal communications, May 17, 2013.
36. ROSENBLUM, M., AND OUSTERHOUT, J. K. The design and implementation of a log-structured file system. ACM Trans. Comput. Syst. 10 (February 1992), 26–52.
37. SCHNEIDER, F. B. Implementing fault-tolerant services using the state machine approach: a tutorial. ACM Com- puting Surveys 22, 4 (Dec. 1990), 299–319.
38. SHVACHKO, K., KUANG, H., RADIA, S., AND CHANSLER, R. The Hadoop distributed file system. In Proc. MSST’10, Symposium on Mass Storage Sys- tems and Technologies (2010), IEEE Computer Society, pp. 1–10.
39. VAN RENESSE, R. Paxos made moderately complex. Tech. rep., Cornell University, 2012.

---

本文的版權歸作者 羅遠航 所有，採用 Attribution-NonCommercial 3.0 License。任何人可以進行轉載、分享，但不可在未經允許的情況下用於商業用途；轉載請註明出處。

3