陳康^1,2,3，黃劍¹，劉建楠⁴

1. 清華信息科學與技術國家實驗室（籌），清華大學計算機科學與技術系，北京 100084； 2. 深圳清華大學研究院，廣東 深圳 518057；3. 天津大學計算機科學與技術學院，天津 300072；4. 中國石油天然氣股份有限公司慶陽石化分公司，甘肅 慶陽 745002

摘要：分布式協商的目的是在分布式環境下在一組進程之間決定一個共同的值，這是在分布式系統中最基本的問題。分布式協商問題的目標非常簡單，但是在面對節點出錯、網絡出錯、網絡時延等環境的時候，協議設計以及處理起來十分困難。討論分布式協商問題的基本形式，在不同的系統假設下的基本結果以及分布式協商在構建穩固的分布式大數據系統中的作用。

關鍵詞：分布式協商；副本狀態機；網絡錯誤；安全性；活躍性

中圖分類號：TP338.8 ?????????文獻標識碼：A

doi: 10.11959/j.issn.2096-0271.2016039

論文引用格式：陳康，黃劍，劉建楠.?面向大數據的粒計算理論與方法研究進展[J]. 大數據, 2016, 2(4): 24-35.

LIANG J Y, HUANG J,LIU J N,.?Distributed consensus: fundamental building block for distributed reliable big data system,?2016, 2(4): 24-35.

Distributed consensus: fundamental building block for distributed reliable big data system

CHEN Kang^1,2,3，HUANG Jian¹，LIU Jiannan⁴

1. Tsinghua National Laboratory for Information Scienceand Technology (TNLIST), Department of Computer Science and Technology,Tsinghua University, Beijing 100084, China

2.Research Institute of Tsinghua University in Shenzhen,Shenzhen 518057, China

3. Technology Innovation Center at Yinzhou, Yangtze DeltaRegion Institute of Tsinghua University, Zhejiang,Ningbo 315000, China

4.Petro China Co. Ltd. Qingyang Petrochemical Company, Qingyang 745002, China

Abstract:The goal of distributed consensus is quite simple i.e. how to decide a value among a group of coordinated processes in the distributed environment. However, the problem is turned out to be very difficult while facing the different distributed environment. The even harder problem is that some consensus protocols are hard to be implemented in practical systems. Some results of distributed consensus algorithms underdifferent distributed environment assumptions were reviewed. In addition, some practicalsystems based on consensus for achieving high reliability were discussed.

Key words: distributed consensus, replicated state machine,network error, safety, liveness

1 ?引言

隨著云計算以及大數據的發展，為了系統的可靠性與性能，將應用系統構建在分布式環境中成為了一個不得不做出的選擇。并行處理系統為大數據處理提供大規模并行的處理能力，能夠處理更多的數據以及進行更復雜的計算。另外一個方面，分布式環境也帶來了系統的可靠性，一個基本的想法是如果系統中有多個計算資源的話，某一小部分計算資源失效不應影響系統的總體運行。這在單機系統中由于計算資源有限的關系不可能實現。在分布式環境下，實現可靠性最常用以及最基本的結構是進行副本復制。在分布式文件系統^[1]中，可以通過使用副本的方式將一個邏輯的數據塊復制到多個其他物理節點中，這樣在某一個物理節點損壞不能工作時，分布式文件系統仍可以繼續工作。副本容錯的方式不僅僅可以進行數據的容錯，也可以進行計算的容錯?？梢詫⑿枰蒎e的計算分布到不同的物理節點中，這樣即使一部分節點失效了，仍然可以保證計算繼續進行。

使用副本進行容錯最基本的要求是副本之間需要保持一致。在系統的實現上，可以通過名為副本狀態機（replicated state machine，RSM）的方式進行副本的復制，這是一種維持多個副本一致的機制。以數據的副本狀態機為例，基本的思想是，所有在數據上做的操作，在每一個副本上操作都一樣，并且順序也一樣。簡單地說，如果數據的初始值是一樣的，那么最終獲得的數據也是一樣的，這就是副本狀態機的基本思想。副本狀態機不僅可以應用在數據上，還可以應用在計算上。副本狀態機顧名思義是與狀態機相關的概念，在系統中計算或者數據會被表達為狀態機的形式。由于狀態機是整個計算機科學的理論基礎，因此使用狀態機的方式理論上就能夠完成所有的計算功能。

圖1是副本狀態機的基本結構。這里只畫出了兩個副本的狀態變化過程。實際中會使用5個或者更多的副本狀態機來達到極高的可靠性。上下兩個狀態機都是從一個狀態S0開始，即副本在多個服務器上的初始狀態是同樣的狀態。另外，還需要假設所有的狀態機都是確定性的狀態機。這里“確定性”的含義是給定一個狀態，如果給出相同的輸入的話，那么都會轉換到相同的唯一的一個狀態。這樣的話，每一次的狀態轉換都是確定性的，而不是不確定的。如果所有的狀態轉換的順序是一樣的，那么可以認為最終的狀態也是一樣的。這一點是很顯然的，使用數學歸納法就可以證明。

圖1 副本狀態機的基本結構

副本狀態機是進行容錯的基本結構。例如，在通常提供的可靠性機制中總有一個選項被稱為雙機熱備份。雙機熱備份提供兩個完全一樣的運行副本，使得兩臺機器中的任意一臺出現了錯誤，另外一臺可以接管工作，完全掌控剩下的工作。雙機熱備份的基本思想在很多系統中都有體現。但是，雙機熱備份實際上并不能真正解決可靠性的問題。最基本的問題是如果雙機熱備份中的一個節點通過超時的機制判斷對方不在線的時候，并不能保證對方節點就一定不在線。因此，如果兩個節點都認為對方不在線，那么就會造成兩個節點同時服務的情況，很容易打破副本狀態機的條件，執行不同的操作，產生狀態的分叉，造成不一致。

那么，如何確保系統中有一致的節點各個狀態的視圖呢？在分布式系統中，通常的做法與投票決定一樣。對副本狀態機進行狀態轉換的每一個操作都進行投票，只有大多數都同意的操作才作為下一步的操作。如果有成員不知道當前的投票情況，那么就停止操作，等待將來其知道的時候再把操作補上。這樣可以避免出現狀態分叉的情況，同時也可以讓當系統中的一小部分成員出現錯誤的時候，分布式系統的工作可以繼續。由于在兩個成員組成的系統中，大多數成員的情況就完全包含了這兩個成員，因此原則上由兩個成員組成的系統只有兩個成員都正常工作時，才能夠保證上層系統繼續工作，也就是說失去了容錯的能力。因此，一個分布式容錯系統起碼要包含3 個成員（“大多數”為任意兩個成員），這樣即使有小部分成員出現了失敗，大部分成員可以繼續通過協商達成一致的結果，推動副本狀態機繼續執行。

在這樣進行容錯的系統中，分布式協商（distributed consensus）是一個基本的組成部分，用來讓一個副本狀態機決定下一步需要做什么樣的操作。抽象來說，分布式協商的目的是在一組分布式進程之間協商決定一個值，至于這個值的類型是什么反而不是很重要。分布式協商需要在組成系統的大數據進程都能夠正常工作的時候協商出一個值，這樣也就有了一定的容錯能力。

本文將探討各種不同的分布式協商協議、分布式協商在副本狀態機中的應用以及在實際系統中如何使用分布式協商系統來保證系統的可靠性。本文的目的是揭開分布式協商的神秘面紗，幫助開發者在理解分布式協商的基礎上完成可靠的分布式系統的構建。對于希望進一步深入了解分布式協商的研究人員來說，本文也將提供足夠的信息來幫助進一步的研究。

2? 副本狀態機與系統可靠性

在進入分布式協商討論之前，還需要看一下副本狀態機的結構以及在副本狀態機上完成系統容錯特性需要完成的工作。分布式協商是副本狀態機機制重要的一環，但是不是唯一的一環。了解了副本狀態機的總體結構之后，就知道分布式協商在副本狀態機中所處的位置，進而可以理解其在副本狀態機中的作用。副本狀態機的結構如圖1所示。為了保證副本狀態機的正確執行，仍然需要一些條件，下面就對這些條件展開討論。

在副本狀態機的條件中，初始狀態相同非常容易保證，這個與具體應用相關。例如，在進行文件系統副本備份的時候，初始狀態為一個空的磁盤，之后開始文件系統的操作；或者在進行數據庫備份的時候，初始狀態為空的數據庫；甚至是總體的計算機進行熱備份的時候，可以讓節點處于同樣的狀態。這在使用物理節點進行備份的時候不太容易做到，而軟件構建的虛擬機很容易做到這一點。本節討論的內容也是基于虛擬機的方式完成計算的容錯。

????在副本狀態機中的另外一個條件是保證所有的操作是確定性的，不會出現隨機的情況，這比保證初始狀態一致稍微困難一些，但是使用記錄/重放的方式可以達到目的。對于大多數的存儲應用，例如文件系統、數據庫等，最終的操作會轉化為底層磁盤的讀寫操作，即讀出一個數據塊或者寫入一個數據塊，操作也都是確定性的。對于計算容錯來說，最基本的單元是一條指令，指令的執行與具體的節點相關，例如讀入當前時鐘周期數的指令（x86下是rdtsc，用于讀取當前處理器的時鐘周期數），很難保證在非常精確的時刻讀入兩臺物理機器相同的時鐘周期數。在這個時候需要使用記錄/重放技術，在一臺物理機中讀出真正的數據，在另外一臺物理機中只是模擬執行一下，不去真正執行底層的指令。一個更為簡單直接的例子是獲取隨機數，只能是記錄一個隨機數，然后直接傳送給另外一個狀態機獲得相同的隨機數。

最后一個條件就是操作的定序問題。這在文件系統和數據庫中最終會表現為所有的磁盤讀寫操作的順序。在計算容錯方面，最終表現為所有指令的執行順序。還有一個問題與定序相關，即對于外界請求的定序。對于外部請求進行不同的定序，非常有可能導致最終內部的執行流程是不相同的。多個節點進行定序很困難，因為缺乏全局的時鐘（這里所有的操作都要賦予一個自然數的序號）。為解決這個問題，最簡單也是最通用的做法是選取副本狀態機中的一個狀態機所在的節點作為負責定序的節點。所有的請求先在這個節點定出順序，之后其他的服務器按照相同的順序操作這些請求。當然，定序節點不應該是固定的，否則如果出現錯誤的話會導致不能繼續定序工作，如何可靠地選擇定序服務器也是一個非常困難的問題。

因為是在分布式環境下構建副本狀態機，還有一個需要解決的問題是系統成員的變化，被稱為配置更新（view change）。這與副本狀態機本身沒有關系，而是分布式系統特有的問題。一般來說，針對特定的分布式算法需要限定參與的成員。這里不是說成員必須是固定的，而是將情況進行簡化，首先考慮成員不變化的情況如何設計分布式算法來達到目的；之后再加上成員變化的情況。成員變化的情況包括增加成員以及減少成員。無論在哪種情況下，原有的分布式算法需要達到的目標在加入或者減少成員之后都應該保持不變。例如，在副本狀態機的情況下，原有的狀態機都決定在一個文件中寫入數據A，那么加入一個新的成員的時候，也需要保持這樣一個動作。這種成員變化的情況被稱為配置的更新，即配置包括了成員的組成，配置更新代表了成員組成的變化。另外還有一種情況也屬于配置更新，即參與成員的角色變化。關于角色的問題實際上是與具體的分布式算法相關的。前面在討論對于客戶端請求的排序上，由于一般通過排序節點完成排序工作，那么這個排序節點就是一個特殊的角色。排序節點的變化也就屬于配置更新的情況?？傊?#xff0c;配置代表了參與分布式算法中的成員以及成員的角色，其中任意一項發生了變化，都稱之為分布式系統的配置更新。分布式算法不僅要在成員固定的時候正確執行，也要在配置更新之前、配置更新進行中以及配置更新完成后都能夠正確執行。

綜上所述，為了使用副本狀態機的方法來構造穩固的分布式系統，需要滿足副本狀態機的基本條件以及需要對配置更新情況做出正確響應。副本狀態機的基本條件包括初始狀態相同、所有的狀態轉換都是確定性的，并且每一步的轉換都是相同的。其中，確定每一步轉換需要進行的處理動作是通過成員之間協商后確定下來的。這樣可以建立一個在大多數成員能夠正常工作的條件下推動副本狀態機執行的可靠機制。

3? 分布式協商

3.1 分布式協商的基本描述與理論結果

維持副本狀態機一致的最基本的問題就是讓一組狀態機（由一組服務器維護）共同決定某個步驟之后的下一個步驟應該執行哪一個操作。因此，核心問題是如何讓一組服務器就某一件事情（例如狀態機下一步需要做的狀態轉換）達成一致。這個問題被稱為分布式協商。一般意義下，可以說分布式協商是在一組服務器之間協商出一個值。這個值的含義是與具體的應用相關的，本文不再贅述。對于任何應用來說，分布式協商都有一些無意義的平凡協議。這些平凡協議在一組服務器之間決定一件事情或者決定一個值是直截了當的，只需要所有的服務器都預先確定一個值即可。在任何時刻如果要進行協商的話，只需要直接給出這個預定值即可。例如，不管協商的內容是什么，所有的服務器都給出一個固定的值0，顯然這也是完成了分布式協商，但并沒有什么意義。因此，分布式協商必須要滿足有意義這個條件。

實際上，一個分布式協商需要滿足的條件大致有以下幾點。

● 最后的協商結果只能是一個，協商完成后不能被更改。這是顯然的，否則算法就不能被稱為分布式協商，這本來就是分布式協商的定義。

● 避免平凡解的條件，即最后決定的值必須是某一個人提出的某一個值（可以稱之為提議），不能設置一個默認的值，否則這個算法就沒有實際的意義。

● 第三個條件比較隱晦，它涉及如果沒有人提出任何值，算法應該怎么辦，此時算法不能憑空造出一個值來讓成員進行確定；另外算法還沒有得出結論的時候，任何一個節點都不能獲知這個結論。

因為上述條件的任何一個條件在任何時刻都不能違反，因此這些條件往往被稱為安全性（safety）條件。整個算法需要滿足一個必須能夠結束的條件，即分布式協商最終應當得出結論，選擇一個值，而不是由于算法陷入無限循環中。

這個條件是最終必須要得出結果的條件。由于系統網絡可能出現數據到達時延、數據丟失等，任何一個算法都不可能在確定的一段時間內完成協商工作，只能保證最終得出結論。這樣的條件也常常被稱為活躍性（liveness）條件。

分布式協商是否能夠達成與網絡條件有著密切的關系。有一個著名的結論發表于1985年，被稱為FLP不可能性定理。Fischer、Lynch、Patterson 3位科學家指出，在異步通信模式下，即使只有一個參與者發生了失敗，也沒有任何算法能夠保證完成分布式協商，此為結論1。

這雖然是一個令人沮喪的結論，但是實際系統并不是運行在這樣一個嚴酷的環境下。實際系統或多或少是一個同步的系統，例如集群環境下，大部分的數據分組都可以在給定的時間內到達。即使是分布在互聯網上的節點，也可以合理假設為到一定超時時間之后，數據分組已經丟失。這樣，可以對上述條件進行加強，即在一個更加合理的半異步的模型下，一致性協商是可以達到的，并由明確的算法達到這個協商的目的。半異步模型保證了雖然網絡數據分組可以丟棄分組，可以有時延，但是在一段足夠長的時間內，大部分節點之間的網絡是正常通信，并且在超時之前將數據分組分發給對應的進程。半異步模型是一個更加合理的模型，實際系統中如果需要系統工作，那么在構建系統的時候還是需要底層網絡比較可靠的支持，起碼需要保證在大部分的時間內大部分的網絡可以正常工作。在這種模型下，有一個著名的Paxos算法^[2]能夠解決分布式協商的問題。Paxos算法指出，具有f個可能錯誤節點的半異步通信模式下，總數為2f+1個節點是可以達成分布式協商的，此為結論2。可以看到，這里的條件就是讓大部分的節點可以正常工作。

最后一個有意思的結論是如果將錯誤模型進行更改，允許節點“故意”出錯，破壞分布式協商的過程，這樣的模型被稱為拜占庭通信模式^[3]。在拜占庭通信模式下，具有f個可能錯誤的節點，總數為3f+1個節點是可以達成分布式協商的，此為結論3。

以上3個結論即為在實際系統中會使用到的結論，其中結論1和結論3主要具有理論意義，能夠指出滿足假設前提下進行協商的極限。結論2是一個明確的算法，能夠直接用來構架可靠的副本狀態機。

3.2 實際系統中的分布式協商協議

實際系統往往是前面所說的半異步的通信模型，因此分布式協商是可以在大多數成員之間達成的。當前實際系統中使用的協議包括著名的由圖靈獎得主Lamport提出的Paxos協議、Yahoo研究院提出的ZooKeeper協議（ZooKeeper Atomic Broadcast協議，簡稱ZAB協議）^[4]以及Stanford大學研究人員提出的專用于教學的Raft協議^[5]。

上述3個協議的核心結構都是相同的。

圖2是分布式協商協議中核心的協商結構，上述3個協商協議的核心部分都是基于這樣的一個結構來完成的。在這個核心結構中，客戶端（client）將請求發送給一個領導者（le ad er）。領導者是唯一的，用以對并發的客戶端請求進行定序，保證輸入到副本狀態機中的操作是有序的。唯一的領導者也是上述3個協議的活躍性的保證，能夠保證最終協商完成。領導者將客戶端的請求發送給所有其他副本狀態機中的成員，這些成員被稱為追隨者（follower）。這些追隨者都復制領導者的操作，把發過來的操作加入本地的日志隊列中。如果大多數的追隨者都同意領導者發過來的一條操作（一個值），那么領導者將提交這個值，將其作為分布式協商的最后結論。

圖2 分布式協商中的核心協商結構

在這個核心結構的外圍，需要一些輔助的模塊，包括兩個非常重要的功能，一個是領導者的選擇（leader election）；另外一個是如何進行配置更新（成員增加或者減少）。這3個協議在不同的層面上完成了分布式協商，并推動上層的副本狀態機的執行。Paxos協議是純粹的分布式協商協議；ZAB協議考慮了領導者的選擇算法，將其集成到協議中；Raft協議則更進一步將配置更新的協議也加入到其中，完善了分布式協商的外圍工作。需要注意的是，雖然3個協議共享了類似的協商核心結構，但是具體的協商過程各不相同。

Paxos協議最為簡單，是一個純粹的分布式協商協議。Paxos協議只考慮一次協商，不考慮多次協商，這雖然與副本狀態機的要求有差距，但是這還是一個非常基本的問題，能夠用來協商副本狀態某一次具體的操作。Paxos協議基于投票的思想，一旦某個提議（包含某一個值）被大多數成員接受，那么這個提議的值就作為協商的結果。但是，由于分布式系統的特點，這樣一個協商完成的結果不見得被其他成員知道，投票過程可能會繼續。分布式協商需要保證的是：如果一個值已經被協商完成，被“固定”在系統中，那么無論如何進一步地投票，最終的投票結果就是已經完成協商的值。核心思想就是在進行值的提議的時候，必須要詢問足夠的但盡可能少的成員，將可能已經完成協商的值作為值的提議。Paxos協議只解決一次協商問題，但是副本狀態機需要多次協商，那么就需要為每一次協商執行一次Paxos算法。Paxos本身不完成定序的問題，多個Paxos協議可以并行執行，通過標記可以相互獨立運行。

ZAB協議沒有在單個的分布式協商基礎上進行討論。由于使用了副本狀態機，ZAB協議考慮多個協商共同進行的情況。ZAB協議包含了一個領導者選舉的算法。領導者選舉過程中，所有成員都互相交換信息，看看當前自己的內部狀態是不是能夠跟上最新的副本狀態機的狀態。包含最新信息的成員自動成為領導者。新領導者被選出之后，為了保證所有操作的有序性，新領導者需要將前面一個領導者（已經失效）遺留的操作都提交一遍。這個過程就是錯誤恢復的過程，能夠保證所有操作的有序性。之后，整個協議將進入上述分布式協商的基本結構中，快速將操作同步到所有的跟隨節點。

Raft協議與ZAB協議非常相像，都是盡量讓新的領導者幫助完成上一個領導者尚未完成的工作。并且，Raft協議是一個更加完整的協議，因為其加入了配置更新的協議。Raft協議的第一個部分是關于領導者選舉的，在一個隨機的超時時間范圍內進行投票，獲得足夠多投票的成員自動成為領導者。之后，協議進入上述的分布式協商的基本結構中。領導者會復制自己的整個狀態給所有的跟隨者，并且在大部分的跟隨節點完成復制之后提交對應的日志。這是將上述的分布式協商基本結構與狀態恢復的過程結合在一起，在新的領導者完成提交的同時，“順便”將前一個領導者的協商值的提議一起提交。Raft協議的完整性體現在對于配置更新方面的支持。通過兩個階段轉換的方式，Raft協議可以正確完成配置更新，并不影響正常分布式協商的正確性。為了能夠維護整個系統的長期穩定運行，配置更新協議也是必不可少的。

3個協議的最大的區別在于對領導者進行轉換時處理，即從一個舊的領導者換成新的領導者時需要做什么樣的工作。在Paxos協議中，新的領導者將觀察自己保存的狀態，嚴格按照協議執行，不破壞已經決定的值。這個過程不涉及多個執行中的Paxos協議，因此領導者在進行轉換的時候，沒有其他信息幫助提交多個值，只能盡可能去保護現有的可能已經選定的值。ZAB協議和Raft協議不是一個單純的一次性的分布式協商協議，這兩個協議是與副本狀態機緊密結合在一起的。在這兩個協議中，如果發生了領導者的轉換，那么就必須考慮如何處理上一個領導者遺留的尚未提交的協商值。因此，這兩個協議都對新的領導者的選擇作出了限制，即新的領導者必須知道一些必要的關于當前系統狀態的信息。在ZAB協議中，新的領導者選舉出來之后，需要確定在獲得的支持成員中有最新的一個請求作為出發點，之后將自己的請求接到最新請求的后面，作為下一個請求。ZAB協議保證必須讓新的領導者幫助提交上一個領導者工作時產生的請求，只有全部提交完成之后，新的領導者才能工作，領導者才真正成為領導者。在Raft協議中，也對新的領導者選擇做出了限制，為了保證正確性，需要保證在選出新的領導者的時候，必須要從之前的已經完成提交的最后一條請求對應的成員節點中去選擇，而不是去任意選擇一個成員節點。這樣的限制使得在投票選出新的領導者時，每一個成員都需要看一下領導者的候選節點具有的信息是否比自己的信息要更新一點，如果是的話則同意候選節點，否則將拒絕候選節點。通過這種方式，新當選的領導者不必進行幫助前一個領導者提交提議的過程，而是可以直接進入自己提議的過程，并且在這個基礎上“順便”幫助前一個領導者提交遺留在系統中的提議。這也是Raft協議和ZAB協議最大的不同。

????上述的3個協議是當前在實際系統中使用最為廣泛的分布式協商協議，3個協議各有特點，可以使用在不同的場景下。3個協議要完成的目標是相同的，都是如何可靠地推動副本狀態機的執行。3個協議提出的背景各不相同，ZAB協議和Raft協議改進了Paxos協議中的難于理解的困難，特別是Raft協議一開始就是為了教學所提出的。Raft協議已經非常完善地描述了副本狀態機需要解決的問題以及相關的解決方案，值得初學者首先選擇進行閱讀理解。

4? 分布式協商協議的應用場景

第3節分析了分布式協商的含義以及在實際系統中的使用的分布式協商協議的情況。由于協議本身的復雜性，這部分內容需要感興趣的讀者花費較長的時間進行理解。但是，在實際系統中，遇到的問題更多的是如何使用分布式協商。分布式協商在實際的系統中具有廣泛的應用，對建立可靠的分布式系統起到決定性的作用。下面就以分布式協商系統在BigTable^[6]系統中的作用來闡述分布式協商系統如何應用于大規模的大數據系統中來保證系統的可靠性。

????將BigTable系統視作一個分布式數據庫，并且這個數據庫是經過排序的，即按照數據記錄的主鍵進行排序。圖3是BigTable系統進行數據查找的流程。

圖3 BigTable系統中的數據查表的流程

從圖3可以看出，在分布式環境下，BigTable的數據表被組織成類似于分布式環境下的“B+樹”的形式。根的數據表和第一級的元數據表用來進行路由工作，之后再依據獲得的用戶數據表的位置來真正讀寫用戶的數據表。由于表格中的數據太大了，在BigTable中使用了按照行進行分割的方式，被稱為數據分表。任何一個客戶端，如果需要訪問BigTable中的數據分表，首先需要經過元數據表的路由才可以訪問到具體的數據分表。整個路由表的根的指針放置在名為Chubby^[7]的系統中，這是進行路由啟動部分的數據。Chubby基于副本狀態機以及Paxos協議^[8]建立了一個穩固的分布式協同系統，為其上的應用程序提供基礎服務。

在維護系統可靠性方面，兩個特別典型的問題需要解決，一個問題是如何得知整個系統中當前能夠正常執行的節點的數目；另外一個問題是如何協調正常執行的節點之間的數據訪問。

????（1）維護系統正常工作節點的狀態信息

關于節點是否正常工作的信息是進行容錯的一個基礎性問題，只有得知系統中的哪些節點在正常工作，哪些節點已經出現了錯誤，才可能進行后續的修復工作。實際上在分布式系統中是非常有必要進行這樣的狀態維護的，這樣不僅可以協調系統的容錯恢復功能，也可以給管理員提供建議信息，為自動以及手動維護提供依據。這件事情雖然看起來非常簡單，但是如果系統的規模達到了數千臺機器，那么進行節點狀態維護就變得極為復雜，用人工的辦法根本沒有辦法實現。

維護節點正常工作一般的做法是通過節點之間的心跳。但是，節點之間的心跳會出現信息不準確的問題，即雙方都不能探測到對方的存在，但是仍然不能確信對方確實下線，這有信息不一致的問題。這里一個最典型的情況就是引言中討論的雙機熱備份的問題。在雙機熱備份問題中，一臺機器為主要的副本，另外一臺機器是備份的副本。在這里，關鍵的問題是主要副本與備份副本之間的網絡情況會造成雙方都無法確信對方是否真的不在線。

使用分布式協商就不會出現上面的不一致的問題。分布式協商就像一個委員會，對于某一個節點是否在線的問題可以由委員會的大多數成員來決定。這樣就可以判斷雙機熱備份的情況下，哪一臺是主要副本，哪一臺是備份副本。類似地，在BigTable系統中，集群中的成員是否正常工作的信息都保存在一個名為Chubby的系統中。每一個Chubby實例包含了5個成員，這5個成員分布在不同的地理位置，這就保證了在絕大多數的情況下大多數成員可以正常工作。在這5個成員之間組成了文件系統的副本狀態機，每一個集群中的服務器的信息都保存在這個文件系統中的某一個文件中。服務器如果在線的話，會按固定的時間間隔更新對應的描述自身文件的信息。其他的服務器包括Chubby中的成員可以檢測對應文件的有效性，如果無效的話，可以認為對應的服務器已經下線。當然，即使Chubby中的信息指示的對應的服務器已經下線了，這并不代表著對應服務器確實出現了錯誤。為了保證正確性，BigTable中某一個數據分表最多由一個服務器負責，否則就會出現數據的不一致。只有Chubby能夠通過一致性協商的方式確定某個服務器是否下線，即使此時對應的服務器還在正常工作，由于其在一定的時間內不能成功更新在Chubby中關于自身的信息，這臺服務器依據協議的規定，應當自動解除自己對數據分表的負責工作，等待整個系統安排重新上線。這樣，可以保證在任何一個時間點，對于任何一個數據分表來說，最多只有一臺服務器負責，避免數據出現不一致的情況。

????（2）協調成員節點之間的數據訪問

另一個問題是協調正常執行節點之間的數據訪問。在單機多線程環境中，有共享數據訪問的問題。共享數據訪問是內存中設置了共享變量，有兩個以及兩個以上的線程訪問（讀/寫）這些共享變量，其中至少有一個訪問是寫入數據。這樣的情況會產生數據訪問沖突。

在多線程環境中，解決數據訪問沖突一般使用保護鎖的方法。任何一個線程在訪問共享數據之前，首先要獲得一個鎖，之后再訪問數據，最后釋放鎖?；コ怄i的語義使得任何一個時刻只有一個線程可以訪問共享的數據，其他的線程只能等待。同樣的機制可以擴展到分布式環境中。在分布式環境中，一般建立鎖的機制是使用鎖服務器?；コ怄i在進行訪問協調的時候起到了非常重要的作用，如果互斥鎖發生了失敗，會造成整個分布式系統無法工作。

在分布式環境中，需要建立非常穩固的鎖機制，將可能產生的鎖失效的概率降到最低。副本狀態機此時起到非常重要的作用。在Chubby中，互斥鎖被建立到副本狀態機中，表現形式為文件系統命名空間中的在文件以及目錄這樣的有名對象上所實現的鎖。在分布式環境中需要對共享資源進行訪問的時候，首先要訪問鎖服務器，只有在成功獲得鎖的情況下，才可能訪問對應的共享資源。但是在分布式環境中的鎖服務機制與傳統的單機環境的鎖服務機制不同。在單機環境中，不需要考慮出錯的情況，因為一旦出錯，那就是整個節點的錯誤，不僅僅是鎖的問題。因此，單機中沒有獲得鎖的線程原則上只能進行無限的等待。但是，在分布式環境中這樣做是不允許的，因為數據分組會在網絡中進行時延，也可能進行分組丟棄。訪問鎖的情況可能會被延遲，獲得鎖的服務器可能會失效。如果獲得互斥鎖的服務器發生了失敗，那么對應的鎖將永遠不能釋放，這就造成了很大的問題。因此，在分布式環境中，對于鎖的訪問必須要加上超時機制?；镜姆绞绞窃讷@得鎖之后，默認情況下只能擁有這個互斥鎖一段時間，超過了這段時間鎖將自動被鎖服務器釋放，便于其他的服務器進行下一步的工作。如果一個服務器獲得了鎖，并且希望將來繼續使用這個鎖，那么這個服務器必須要進行續租的操作，延長獲得鎖的時間。

將上述的原理應用在實際工作的系統中，還需要考慮網絡時延以及時間測量的誤差，確保在訪問共享資源時，最多只有一個節點進行訪問，其他節點都被排除在外，這樣才算是正確的互斥鎖的語義。如果時延的數據分組沒有到達，或者沒有獲得響應，對應的服務器只能認為延長請求失效，退出對于對應共享資源的控制，避免對數據造成不一致的操作。這樣鎖的協議會比較復雜，也是分布式與單機環境的區別。BigTable中有許多對共享資源的訪問，其中就有對于底層的分布式文件系統的文件的訪問。另外，也有對于數據分表的再拆分以及數據分表的合并的過程，也有對于共享日志的分配以及恢復操作等?？梢哉f，任何一個分布式系統，對于共享資源的訪問是無可避免的操作，因此分布式的互斥鎖的機制是無可避免的分布式的系統功能。建立一個穩固的分布式鎖的環境是建立高可靠的分布式系統的關鍵組成部分。

通過BigTable的具體機制可以看到，通過分布式協商以及副本狀態機，Chubby建立了一個非常穩固的、由副本狀態機推動的復制的文件系統。雖然文件系統的語義非?；A，不能夠提供高層的語義信息，但是Chubby提供了最基本的存儲模型。在這個模型的基礎之上，Chubby完成了整個系統的完整的活躍信息描述，協調了BigTable對于共享數據分表資源的訪問。實際上，Chubby成為了Google(谷歌)內部的分布式大數據系統的基礎，為難于實現的可靠性問題提供了基石。在這個基礎之上，建立上層應用系統的可靠性難度將大大降低。

5? 結束語

本文對現有的保證可靠性的副本狀態機進行了詳細的討論，包括副本狀態機需要滿足的條件、基本的執行流程以及副本狀態機在實現可靠分布式系統中的作用。副本狀態機需要滿足的條件為初始狀態相同、狀態轉換函數必須是確定性的以及轉換操作與過程必須使用分布式協商算法。在此基礎上，詳細分析了現有的分布式協商算法的協議，包括Paxos協議、ZAB協議以及Raft協議。這些協議各有特點，并有不同的分布式系統的實現。Paxos協議是單次的分布式協商，雖然簡單，但是需要配合許多其他的組件才能夠真正構成副本狀態機的工作機制。ZAB協議和Raft協議是完整的分布式副本狀態機的協議，能夠直接推動副本狀態機的執行，其中Raft協議還繼續提供了配置更新的協議，完善了在實際系統中的各個細節。在分析完成常用的分布式協商協議的基礎之上，還分析了如何通過副本狀態機構造可靠的分布式系統。需要提供的主要模塊是完成整個系統的節點狀態的監測與維護以及協調正常工作節點之間的工作。可以看到，分布式協商技術能夠提供可靠性的基本模塊，是建立可靠性系統的基礎。通過本文的分析，讀者可以對分布式協商有一個基本概念，為建立可靠的分布式系統提供基礎的模型。

本文對現有的保證可靠性的副本狀態機進行了詳細的討論，包括副本狀態機需要滿足的條件、基本的執行流程以及副本狀態機在實現可靠分布式系統中的作用。副本狀態機需要滿足的條件為初始狀態相同、狀態轉換函數必須是確定性的以及轉換操作與過程必須使用分布式協商算法。在此基礎上，詳細分析了現有的分布式協商算法的協議，包括Paxos協議、ZAB協議以及Raft協議。這些協議各有特點，并有不同的分布式系統的實現。Paxos協議是單次的分布式協商，雖然簡單，但是需要配合許多其他的組件才能夠真正構成副本狀態機的工作機制。ZAB協議和Raft協議是完整的分布式副本狀態機的協議，能夠直接推動副本狀態機的執行，其中Raft協議還繼續提供了配置更新的協議，完善了在實際系統中的各個細節。在分析完成常用的分布式協商協議的基礎之上，還分析了如何通過副本狀態機構造可靠的分布式系統。需要提供的主要模塊是完成整個系統的節點狀態的監測與維護以及協調正常工作節點之間的工作?？梢钥吹?#xff0c;分布式協商技術能夠提供可靠性的基本模塊，是建立可靠性系統的基礎。通過本文的分析，讀者可以對分布式協商有一個基本概念，為建立可靠的分布式系統提供基礎的模型。

?

參考文獻：

[1] GHEMAWAT S, GOBIOFF H, LEUNG S T. TheGoogle file system[J]. ACM SIGOPS Operating Systems Review, 2003, 37(5):29-43.

[2] LAMPORT L. Paxos made simple[J].ACMSIGACT News, 2001, 32(4): 51-58.

[3] LAMPORT L, PEASE M, SHOSTAK R. Thebyzantine generals problem [J]. ACM Transactions on Programming Languages andSystems, 1982, 4(3): 382-401.

[4] HUNT P, KONAR M, JUNQUEIRA F P,et al.ZooKeeper: wait-free coordination for internet-scale systems [C]// The2010USENIX Annual Technical Conference,June 22-2 5, 2 010, Boston, MA,USA.[S.l.:s.n.], 2010: 1-14.

[5] ONGARO D , OUSTERHOUT J . In search ofan understandable consensus algorithm[C]// The 2014 USENIX Annual TechnicalConference, June 19-20, 2014, Philadelphia , PA, USA. [S.l.:s.n.], 2014: 305-319.

[6] CHANG F, DEAN J, GHEMAWAT S, et al. Bigtable: a distributed storage system for structured data[J]. ACM Translations on ComputerSystems, 2008, 26( 2 ):205-218.

[7] BURROWS M. The Chubby lock service forloosely-coupled distributed systems[C]//The 7th Symposium on Operating Systems Designand Implementation, November6-8, 2006, Seattle, WA, USA. New York: ACM SIGOPS,2006: 335-350.

[8] CHANDRA T D , GRIESEMER R , REDSTONE J. Paxos made live: an engineering perspective [C]//The 26^th AnnualACM Symposium on Principles of Distributed Computing, August 12-15,2007,Portland, Oregon, USA. New York: ACM Press, 2007: 398-407.

陳康（1976-），男，博士，清華大學計算機科學與技術系、深圳清華大學研究院、浙江清華長三角研究院鄞州創新中心副教授，主要研究方向為分布式系統、存儲系統。

黃劍（1993 -），男，清華大學計算機科學與技術系碩士生，主要研究方向為文件存儲器和分布式系統。

劉建楠（1963-），男，就職于中國石油天然氣股份有限公司慶陽石化分公司，主要從事企業經營和信息化管理工作。

總結

以上是生活随笔為你收集整理的【2016年第4期】分布式协商：建立稳固分布式 大数据系统的基石的全部內容，希望文章能夠幫你解決所遇到的問題。

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