Paxos 實現(xiàn)日志復制同步

這篇文章以一種易于理解的方式來解釋 Multi-Paxos 的機制。

Multi-Paxos 的是為了創(chuàng)建日志復制

一種實現(xiàn)方式是用一組基礎 Paxos 實例，每條記錄都有一個獨立的 Paxos 實例，要想這么做只需要為每個 Prepare 和 Accept 請求增加一個小標索引（index），用來選擇特定的記錄，所有的服務器為日志里的每條記錄都保有獨立的狀態(tài)。

上圖展示了一個請求的完整周期。

從客戶機開始，它向服務器發(fā)送所需執(zhí)行的命令，它將命令發(fā)送至其中一臺服務器的 Paxos 模塊。

這臺服務器運行 Paxos 協(xié)議，讓該條命令（shl）被選擇作為日志記錄里的值。這需要它與其他服務器之間進行通信，讓所有的服務器都達成一致。

服務器等待所有之前的日志被選定后，新的命令將被應用到狀態(tài)機。

這時服務器將狀態(tài)機里的結(jié)果返回給客戶端。

這是個基本機制，后面會作詳細介紹。

Multi-Paxos 的問題

本頁介紹了 Multi-Paxos 所需解決的一些基本問題，讓 Multi-Paxos 在實際中得以正確運行。

• 對于一個請求，如何決定該使用哪條日志記錄？
• 第二個問題關于性能。如果用之前的基礎 Paxos 中描述的方式，運行會很慢。所以引入了 領導者（leader） 來降低 提議者（proposer） 之間的沖突。還可以消除幾乎絕大多數(shù)的 準備階段（Prepare） 的請求，只需要處理一輪 RPC 請求。
• 這個問題關于完整復制。如何保證所有的服務器最終都有每天記錄，每個服務器都知道被選定的日志記錄是什么。
• 客戶端協(xié)議。會介紹客戶端在服務器崩潰時，如何還能正常工作。
• 最后一個問題就是配置的變更。如何安全地給 Multi-Paxos 集群增加或移除服務器。

這里需要注意的是，基礎 Paxos 已經(jīng)有非常完整地描述，而且分析也證明它是正確的。非常易于理解。但是 Multi-Paxos 確不是這樣，它的描述很抽象，有很多選擇處理方式，沒有一個是很具體的描述。而且，Multi-Paxos 并沒有為我們詳細的描述它是如何解決這些問題的。

這篇文章以一種易于理解的方式來解釋 Multi-Paxos 的機制。現(xiàn)在我們還沒有實現(xiàn)它，也還沒有證明它的正確性，所以后續(xù)解釋可能會有 bug 。但希望這些內(nèi)容可以對解決問題、構(gòu)建可用的 Multi-Paxos 協(xié)議有所幫助

選擇日志記錄

第一個問題是當接收到客戶端請求時如何選擇日志槽，我們以上圖中的例子來闡述如何做到這點。假設我們的集群里有三臺服務器，所以 “大多數(shù)” 指的是 2 。這里展示了當客戶端發(fā)送命令（jmp）時，每臺服務器上日志的狀態(tài)，客戶端希望這個請求值能在日志中被記錄下來，并被狀態(tài)機執(zhí)行。

當接收到請求時，服務器 S1 上的記錄可能處于不同的狀態(tài)，服務器知道有些記錄已經(jīng)被選定（1-mov，2-add，6-ret），在后面我會介紹服務器是如何知道這些記錄已經(jīng)被選定的。服務器上也有一些其他的記錄（3-cmp），但此時它還不知道這條記錄已經(jīng)被選定。在這個例子中，我們可以看到，實際上記錄（3-cmp）已經(jīng)被選定了，因為在服務器 S3 上也有相同的記錄，只是 S1 和 S3 還不知道。還有空白記錄（4-，5-）沒有接受任何值，不過其他服務器上相應的記錄可能已經(jīng)有值了。

現(xiàn)在來看看發(fā)生些什么：

當 jmp 請求到達 S1 后，它會找到第一個沒有被選定的記錄（3-cmp），然后它會試圖讓 jmp 作為該記錄的選定值。為了讓這個例子更具體一些，我們假設服務器 S3 已經(jīng)下線。所以 Paxos 協(xié)議在服務器 S1 和 S2 上運行，服務器 S1 會嘗試讓記錄 3 接受 jmp 值，它正好發(fā)現(xiàn)記錄 3 內(nèi)已經(jīng)有值（3-cmp），這時它會結(jié)束選擇并進行比較，S1 會向 S2 發(fā)送接受（3-cmp）的請求，S2 會接受 S1 上已經(jīng)接受的 3-cmp 并完成選定。這時（3-cmp）變成粗體，不過還沒能完成客戶端的請求，所以我們返回到第一步，重新進行選擇。找到當前還沒有被選定的記錄（這次是記錄 4-），這時 S1 會發(fā)現(xiàn) S2 相應記錄上已經(jīng)存在接受值（4-sub），所以它會再次放棄 jmp ，并將 sub 值作為它 4- 記錄的選定值。所以此時 S1 會再次返回到第一步，重新進行選擇，當前未被選定的記錄是 5- ，這次它會成功的選定 5-jmp ，因為 S1 沒有發(fā)現(xiàn)其他服務器上有接受值。

當下一次接收到客戶端請求時，首先被查看的記錄會是 7- 。

在這種方式下，單個服務器可以同時處理多個客戶端請求，也就是說前一個客戶端請求會找到記錄 3- ，下一個客戶端請求就會找到記錄 4- ，只要我們?yōu)椴煌恼埱笫褂貌煌挠涗?#xff0c;它們都能以并行的方式獨立運行。不過，當進入到狀態(tài)機后，就必須以一定的順序來執(zhí)行命令，命令必須與它們在日志內(nèi)的順序一致，也就是說只有當記錄 3- 完成執(zhí)行后，才能執(zhí)行記錄 4- 。

提高效率

下一個需要解決的就是效率問題。在之前描述過的內(nèi)容中存在兩個問題：

第一個問題就是當有多個 提議者（proposer） 同時工作時，仍然會有可能存在競爭沖突的情況，有些請求會被要求重新開始，可能大家還會記得在 基礎 Paxos 里介紹過的死鎖情況。同樣的狀況也可以在這里發(fā)生，當集群壓力過大時，這個問題會非常明顯，如果有很多客戶端并發(fā)的請求集群，所有的服務器都試圖在同一條記錄上進行值的選定，就可能會出現(xiàn)系統(tǒng)失效或系統(tǒng)超負荷的情況。

第二個問題就是每次客戶端的請求都要求兩輪的遠程調(diào)用，第一輪是提議的準備（Prepare）請求階段，第二輪是提議的接受（Accept）請求階段。

為了讓事情更有效率，這里會做兩處調(diào)整。首先，我們會安排單個服務器作為活動的 提議者（proposer） ，所有的提議請求都會通過這個服務器來發(fā)起。我們稱這個服務器為 領導者（leader） 。其次，我們有可能可以消除幾乎所有的準備（Prepare）請求，為了達到目的，我們可以為 領導者（leader） 使用一輪提議準備（Prepare），但是準備的對象是完整的日志，而不是單條記錄。一旦完成了準備（Prepare），它就可以通過使用接受（Accept）請求，同時創(chuàng)建多條記錄。這樣就不需要多次使用準備（Prepare）階段。這樣就能減少一半的 RPC 請求。

領導者（leader）選舉

選舉領導者的方式有很多，這里只介紹一種由 Leslie Lamport 建議的簡單方式。這個方式的想法是，因為服務器都有它們自己的 ID ，讓有最高 ID 的服務器作為領導者。可以通過每個服務器定期（每 T ms）向其他服務器發(fā)送心跳消息的方式來實現(xiàn)。這些消息包含發(fā)送服務器的 ID ，當然同時所有的服務器都會監(jiān)控它們從其他服務器處收到的心跳檢測，如果它們沒有能收到某一具有高 ID 的服務器的心跳消息，這個間隔（通常是 2T ms）需要設置的足夠長，讓消息有足夠的通信傳遞時間。所以，如果這些服務器沒有能接收到高 ID 的服務器消息，然后它們會自己選舉成為領導者。也就是說，首先它會從客戶端接受到請求，其次在 Paxos 協(xié)議中，它會同時扮演 提議者（proposer） 和 接受者（acceptor） 兩種角色。如果機器能夠接收到來自高 ID 的服務器的心跳消息，它就不會作為領導者，如果它接收到客戶端的請求，那么它會拒絕這個請求，并告知客戶端與 領導者（leader） 進行通信。另外一件事是，非 領導者（leader） 服務器不會作為 提議者（proposer） ，只會作為 接受者（acceptor） 。這個機制的優(yōu)勢在于，它不太可能出現(xiàn)兩個 領導者（leader） 同時工作的情況，即使這樣，如果出現(xiàn)了兩個 領導者（leader） ，Paxos 協(xié)議還是能正常工作，只是不是那么高效而已。

應該注意的是，實際上大多數(shù)系統(tǒng)都不會采用這種選舉方式，它們會采用基于租約的方式（lease based approach），這比上述介紹的機制要復雜的多，不過也有其優(yōu)勢。

減少準備（Prepare）的 RPC 請求

另一個提高效率的方式就是減少準備請求的 RPC 調(diào)用次數(shù)，我們幾乎可以擺脫所有的準備（Prepare）請求。為了理解它的工作方式，讓我們先來回憶一下為什么我們需要準確請求（Prepare）。首先，我們需要使用提議序號來阻止老的提議，其次，我們使用準備階段來檢查已經(jīng)被接受的值，這樣就可以使用這些值來替代原本自己希望接受的值。

第一個問題是阻止所有的提議，我們可以通過改變提議序號的含義來解決這個問題，我們將提議序號全局化，代表完整的日志，而不是為每個日志記錄都保留獨立的提議序號。這么做要求我們在完成一輪準備請求后，當然我們知道這樣做會鎖住整個日志，所以后續(xù)的日志記錄不需要其他的準備請求。

第二個問題有點討巧。因為在不同接受者的不同日志記錄里有很多接受值，為了處理這些值，我們擴展了準備請求的返回信息。和之前一樣，準備請求仍然返回 接受者（acceptor） 所接受的最高 ID 的提議，它只對當前記錄這么做，不過除了這個， 接受者（acceptor） 會查看當前請求的后續(xù)日志記錄，如果后續(xù)的日志里沒有接受值，它還會返回這些記錄的標志位 noMoreAccepted 。

最終如果我們使用了這種領導者選舉的機制，領導者會達到一個狀態(tài)，每個 接受者（acceptor） 都返回 noMoreAccepted ，領導者知道所有它已接受的記錄。所以一旦達到這個狀態(tài)，對于單個 接受者（acceptor） 我們不需要再向這些 接受者（acceptor） 發(fā)送準備請求，因為它們已經(jīng)知道了日志的狀態(tài)。

不僅如此，一旦從集群大多數(shù) 接受者（acceptor） 那獲得 noMoreAccepted 返回值，我們就不需要發(fā)送準備的 RPC 請求。也就是說， 領導者（leader） 可以簡單地發(fā)送接受（Accept）請求，只需要一輪的 RPC 請求。這個過程會一直執(zhí)行下去，唯一能改變的就是有其他的服務器被選舉成了 領導者（leader） ，當前 領導者（leader） 的接受（Accept）請求會被拒絕，整個過程會重新開始。

復制的完整性

這個問題的目的是讓所有的 接受者（acceptor） 都能完全接受到日志的最新信息。現(xiàn)在算法并沒有提供完整的信息。例如，日志記錄可能沒有在所有的服務器上被完整復制，所選擇的值只是在大多數(shù)服務器上被接受。但我們要保證的就是每條日志記錄在每臺服務器上都被完全復制。第二個問題是，現(xiàn)在只有 提議者（proposer） 知道某個已被選定的特定值，知道的方式是通過收到大多數(shù) 接受者（acceptor） 的響應，但其他的服務器并不知道記錄是否已被選定。例如， 接受者（acceptor） 不知道它們存儲的記錄已被選定，所以我們還想通知所有的服務器，讓它們知道已被選定的記錄。提供這種完整信息的一個原因在于，它讓所有的服務器都可以將命令傳至它們的狀態(tài)機，然后通過這個狀態(tài)機執(zhí)行這些命令。所以這些狀態(tài)機可以和領導者服務器上的狀態(tài)機保持一致。如果我沒有這么做，他們就沒有日志記錄也不知道哪個日志記錄是被選定的，也就無法在狀態(tài)機中執(zhí)行這些命令。

下面會通過四步來解釋這個過程：

• 第一步，在我們達成仲裁之前不會停止接受（Accept）請求的 RPC 。也就是說如果我們知道大多數(shù)服務器已經(jīng)選定了日志記錄，那么就可以繼續(xù)在本地狀態(tài)機中執(zhí)行命令，并返回給客戶端。但是在后臺會不斷重試這些 Accept RPC 直到獲得所有服務器的應答，由于這是后臺運行的，所以不會使系統(tǒng)變慢。這樣就能保證在本服務器上創(chuàng)建的記錄能同步到其他服務器上，這樣也就提供了完整的復制。但這并沒有解決所有問題，因為也可能有其他更早的日志記錄在服務器崩潰前只有部分已復制，沒有被完整復制。

• 第二步，每臺服務器需要跟蹤每個已知被選中的記錄，需要做到兩點：首先，如果服務器發(fā)現(xiàn)一條記錄被選定，它會為這條記錄設置 acceptedProposal 值為無窮大 ∞ 。這個標志表示當前的提議已被選定，這個無窮大 ∞ 的意義在于，永遠不會再覆蓋掉這個已接受的提議，除非獲得了另外一個有更高 ID 的提議，所以使用無窮大 ∞ 可以知道，這個提議不再會被覆蓋掉。除此之外，每臺服務器還會保持一個 firstUnchosenIndex 值：這個值是表示未被標識選定的最小下標位置。這個也是已接受提議值不為無窮大 ∞ 的最低日志記錄

• 第三步， 提議者（proposer） 為 接受者（acceptor） 提供已知被選定的記錄信息，它以捎帶的方式在接受請求中提供相關的信息。每條由 提議者（proposer） 發(fā)送給 接受者（acceptor） 的請求都包括首個未被選定值的下標索引位置 firstUnchosenIndex ，換句話說 接受者（acceptor） 現(xiàn)在知道所有記錄的提議序號低于這個值的都已經(jīng)被選定，它可以用這個來更新自己。為了解釋這個問題，我們用例子來進行說明，假設我們有一個 接受者（acceptor） 里的日志如上圖所示。在它接收到接受請求之前，日志的信息里知道的提議序號為 1、2、3、5 已經(jīng)被標記為了選定，記錄 4、6 有其他提議序號，所以它們還沒有被認定是已選定的。現(xiàn)在假設接收到接受請求

  Accept(proposal=3.4, index=8, value=v, firstUnchosenIndex=7)

  它的提議序號是 3.4 ，firstUnchosenIndex 的值為 7 ，這也意味著在 提議者（proposer） 看來，所有 1 至 6 位的記錄都已經(jīng)被選定， 接受者（acceptor） 使用這個信息來比較提議序號，以及日志記錄里所有已接受的提議序號，如果存在任意記錄具有相同的提議序號，那么就會標記為 接受者（acceptor） 。在這個例子中，日志記錄 6 有匹配的提議序號 3.4 ，所以 接受者（acceptor） 會標記這條記錄為已選定。之所以能這樣，是因為 接受者（acceptor） 知道相關信息。首先，因為 接受者（acceptor） 知道當前這個日志記錄來自于發(fā)送接受消息的同一 提議者（proposer） ，我們同時還知道記錄 6 已經(jīng)被 提議者（proposer） 選定，而且我們還知道， 提議者（proposer） 沒有比這個日志里更新的值，因為在日志記錄里已接受的提議序號值與 提議者（proposer） 發(fā)送的接受消息中的提議序號值相同，所以我們知道這條記錄在選定范圍以內(nèi)，它還是我們所能知道的， 提議者（proposer） 里可能的最新值。所以它一定是一個選定的值。所以 接受者（acceptor） 可以將這條記錄標記為已選定的。因為同時我們還接收到關于新記錄 8 的請求，所以在接收到接受消息之后，記錄 8 處提議序號值為 3.4 。

  這個機制無法解決所有的問題。問題在于 接受者（acceptor） 可能會接收到來自于不同 提議者（proposer） 的某些日志記錄，這里記錄 4 可能來自于之前輪次的服務器 S5 ，不幸的是這種情況下， 接受者（acceptor） 是無法知道該記錄是否已被選定。它也可能是一個已失效過時的值。我們知道它已經(jīng)被 提議者（proposer） 選定，但是它可能應該被另外一個值所取代。所以還需要多做一步。

• 第四步， 接受者（acceptor） 接收的處理日志記錄來自于舊領導者（leader），所以它不確定記錄的值是否已被選定。當 接受者（acceptor） 響應接受請求時，它會返回自己的第一個為選定值的下標 firstUnchosenIndex ，當 提議者（proposer） 接收到響應時，會將自己的 firstUnchosenIndex 與響應里的 firstUnchosenIndex 作比較，如果 提議者（proposer） 的下標位置更大，這就表明 接受者（acceptor） 的某些狀態(tài)是不確定的，這時 提議者（proposer） 會將準確的內(nèi)容發(fā)送給 接受者（acceptor） ，這都可以通過一個新的 RPC 調(diào)用來完成。這是 Multi-Paxos 使用的第三種 RPC 調(diào)用，這個調(diào)用包括兩個參數(shù)，日志記錄的下標位置及該位置的值。這條消息可以讓某一特定位置的某一特定值被選定，不會再存在未知的情況，所以接受者只要將這個信息從消息中提取并更新它自己的日志記錄即可，然后返回它更新的 firstUnchosenIndex ，因為可能存在有多個未知狀態(tài)的情況，所以 提議者（proposer） 會發(fā)送多個 RPC 請求，直到最后 接受者（acceptor） 與 提議者（proposer） 的日志狀態(tài)達成一致。

這一系列機制可以保證最終，所有的服務器里的日志記錄都可以被選定，而且它們知道已被選定。在通常情況下，是不會有額外開銷的，額外的開銷僅存在與領導者被切換的情況，這個時間也非常短暫。

客戶端協(xié)議

Multi-Paxos 第五個問題是客戶端如何與系統(tǒng)進行交互的。如果客戶端想要發(fā)送一條命令，它將命令發(fā)送給當前集群的 領導者（leader） 。如果客戶端正好剛啟動，它并不知道哪個服務器是作為 領導者（leader） 的，這樣它會向任一服務器發(fā)送命令，如果服務器不是 領導者（leader） 它會返回一些信息，讓客戶端重試并向真正的 領導者（leader） 發(fā)送命令。一旦 領導者（leader） 收到消息， 領導者（leader） 會為命令確定選定值所處位置，在確定之后，就會將這個命令傳遞給它自己的狀態(tài)機，一旦狀態(tài)機執(zhí)行命令后，它就會將結(jié)果返回給客戶端。客戶端會一直向某一 領導者（leader） 發(fā)送命令，知道它無法找到這個 領導者（leader） 為止，例如， 領導者（leader） 可能會崩潰，此時客戶端的請求會發(fā)送超時，在此種情況下，客戶端會隨便選擇任意隨機選取一臺服務器，并對命令進行重試，最終集群會選擇一個新的 領導者（leader） 并重試請求，最終請求會成功得到應答。

但是這個重試機制存在問題。

如果 領導者（leader） 已經(jīng)成功執(zhí)行了命令，在響應前的最后一秒崩潰了？這時客戶端會嘗試在新 領導者（leader） 下重試命令，這樣就可能會導致相同的命令被執(zhí)行兩次，這是不允許發(fā)生的，我們需要保證的是每個命令都僅執(zhí)行一次。為了達到目的，客戶端需要為每條命令提供一個唯一的 ID ，這個 ID 可以是客戶端的 ID 以及一個序列號，這條記錄包含客戶端發(fā)送給服務器的信息，服務器會記錄這個 ID 以及命令的值，同時，當狀態(tài)機執(zhí)行命令時，它會跟蹤最近的命令的信息，即最高 ID 序號，在它執(zhí)行新命令之前，它會檢查命令是否已經(jīng)被執(zhí)行過，所以在 領導者（leader） 崩潰的情況下，客戶端會以新的 領導者（leader） 來重試，新的 領導者（leader） 可以看到所有已執(zhí)行過的命令，包括舊 領導者（leader） 崩潰之前已執(zhí)行的命令，這樣它就不會重復執(zhí)行這條命令，只會返回首次執(zhí)行的結(jié)果。

結(jié)果就是，只要客戶端不崩潰，就能獲得 exactly once 的保證，每個客戶端命令僅被集群執(zhí)行一次。如果客戶端出現(xiàn)崩潰，就處于 at most once 的情況，也就是說客戶端的命令可能執(zhí)行，也可能沒有執(zhí)行。但是如果客戶端是活著的，這些命令只會執(zhí)行一次。

配置變更

最后的一個問題在配置變更的情況。

這里說的系統(tǒng)配置信息指的是參與共識性協(xié)議的服務器信息，通常也就是服務器的 ID ，服務器的網(wǎng)絡地址。這些配置的重要性在于，它決定了仲裁過程，當前仲裁的大多數(shù)代表什么。如果我們改變服務器數(shù)量，那么結(jié)果也會發(fā)生變化。我們有對配置提出變更的需求，例如如果服務器失敗了，我們可能需要切換并替代這臺服務器，又或我們需要改變仲裁的規(guī)模，我們希望集群更加可靠（比如從 5 臺服務器提升到 7 臺）。

這些變更需要非常小心，因為它會改變仲裁的規(guī)模。

另外一點就是需要保證在任何時候都不能出現(xiàn)兩個不重疊的多數(shù)派，這會導致同一日志記錄選擇不同值的情況。假設我們將集群內(nèi)服務器從 3 臺提升到 5 臺時，在某些情況下，有些服務器會相信舊的配置是有效的，有些服務器會認為新配置是有效的。這可能會導致最上圖最左側(cè)的兩臺服務器還以舊的配置信息進行仲裁，選擇的值是（v1），而右側(cè)的三臺服務器認為新配置是有效的，所以 3 臺服務器構(gòu)成了大多數(shù)，這三臺服務器會選擇一個不同的值（v2）。這是我們不希望發(fā)發(fā)生的。

Paxos 配置變更解決方案

Leslie Lamport 建議的 Paxos 配置變更方案是用日志來管理這些變更，當前的配置作為日志的一條記錄存儲，并與其他的日志記錄一同被復制同步。所以上圖中 1-C1、3-C2 表示兩個配置信息，其他的用來存儲普通的命令。這里有趣的是，配置所使用每條記錄是由它的更早的記錄所決定的。這里有一個系統(tǒng)參數(shù) ? 來決定這個更早是多早，假設 ? 為 3，我們這里有兩個配置相關的記錄，C1 存于記錄 1 中，C2 存于記錄 3 中，這也意味著 C1 在 3 條記錄內(nèi)不會生效，也就是說，C1 從記錄 4 開始才會生效。C2 從記錄 6 開始才會生效。所以當我們選擇記錄 1、2、3 時，生效的配置會是 C1 之前的那條配置，這里我們將其標記為 C0 。這里的 ? 是在系統(tǒng)啟動時配置好的參數(shù)，這個參數(shù)可以用來限制同時使用的配置信息，也就是說，我們是無法在 i+? 之前選擇使用記錄 i 中的配置的。因為我們無法知道哪些服務器使用哪些配置，也無法知道大多數(shù)所代表的服務器數(shù)量。所以如果 ? 的值很小時，整個過程是序列化的，每條記錄選擇的配置都是不同的，如果 ? 為 3 ，也就意味著同時有三條記錄可以使用相同的配置，如果 ? 大很多時，事情會變得更復雜，我們需要長時間的等待，讓新的配置生效。也就是說如果 ? 的值是 1000 時，我們需要在 1000 個記錄之后才能等到這個配置生效。

Paxos 總結(jié)

參考

參考來源:

2013 Paxos lecture, Diego Ongaro

2013 Raft user study

Wiki: Byzantine fault tolerance

結(jié)束

轉(zhuǎn)載于:https://www.cnblogs.com/richaaaard/p/6297104.html

總結(jié)

以上是生活随笔為你收集整理的Paxos 实现日志复制同步（Multi-Paxos）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。