Poxos算法詳解（二）

經過上篇文章的學習，你應該知道，Basic Paxos 只能就單個值（Value）達成共識，一旦遇到爲一系列的值實現共識的時候，它就不管用了

蘭伯特並沒有把 Multi-Paxos 講清楚，只是介紹了大概的思想，缺少算法過程 的細節和編程所必須的細節（比如缺少選舉領導者的細節）。這也就導致每個人實現的 Multi-Paxos 都不一樣。不過從本質上看，大家都是在蘭伯特提到的 Multi-Paxos 思想上補充細節，設計自己的 Multi-Paxos 算法，然後實現它（比如 Chubby 的 Multi-Paxos 實 現、Raft 算法、ZAB 協議等）。

蘭伯特提到的 Multi-Paxos 是一種思想，不是算法。而 Multi-Paxos 算法是一個統稱，它是指基於 Multi-Paxos 思想，通過多個 Basic Paxos 實例實現一系列值的共識的算法（比如 Chubby 的 Multi-Paxos 實現、Raft 算法等）。

Basic Paxos 是通過二階 段提交來達成共識的。在第一階段，也就是準備階段，接收到大多數準備響應的提議者，才 能發起接受請求進入第二階段（也就是接受階段）：

而如果我們直接通過多次執行 Basic Paxos 實例，來實現一系列值的共識，就會存在這樣 幾個問題：

• 如果多個提議者同時提交提案，可能出現因爲提案衝突，在準備階段沒有提議者接收到 大多數準備響應，協商失敗，需要重新協商。你想象一下，一個 5 節點的集羣，如果 3 個節點作爲提議者同時提案，就可能發生因爲沒有提議者接收大多數響應（比如 1 個提 議者接收到 1 個準備響應，另外 2 個提議者分別接收到 2 個準備響應）而準備失敗，需 要重新協商。
• 2 輪 RPC 通訊（準備階段和接受階段）往返消息多、耗性能、延遲大。你要知道，分佈 式系統的運行是建立在 RPC 通訊的基礎之上的，因此，延遲一直是分佈式系統的痛點， 是需要我們在開發分佈式系統時認真考慮和優化的。

領導者（Leader）

我們可以通過引入領導者節點，也就是說，領導者節點作爲唯一提議者，這樣就不存在多個 提議者同時提交提案的情況，也就不存在提案衝突的情況了：

PS: 在論文中，蘭伯特沒有說如何選舉領導者，需要我們在實現 MultiPaxos 算法的時候自己實現。 比如在 Chubby 中，主節點（也就是領導者節點）是通過執 行 Basic Paxos 算法，進行投票選舉產生的。

優化 Basic Paxos 執行

我們可以採用“當領導者處於穩定狀態時，省掉準備階段，直接進入接受階段”這個優化機 制，優化 Basic Paxos 執行。也就是說，領導者節點上，序列中的命令是新的，不再需 要通過準備請求來發現之前被大多數節點通過的提案，領導者可以獨立指定提案中的值。這 時，領導者在提交命令時，可以省掉準備階段，直接進入到接受階段：

和重複執行 Basic Paxos 相比，Multi-Paxos 引入領導者節點之後，因爲只有領導 者節點一個提議者，只有它說了算，所以就不存在提案衝突。另外，當主節點處於穩定狀態 時，就省掉準備階段，直接進入接受階段，所以在很大程度上減少了往返的消息數，提升了 性能，降低了延遲。

Chubby 的 Multi-Paxos 實現

既然蘭伯特只是大概的介紹了 Multi-Paxos 思想，那麼 Chubby 是如何補充細節，實現 Multi-Paxos 算法的呢？

首先，它通過引入主節點，實現了蘭伯特提到的領導者（Leader）節點的特性。也就是 說，主節點作爲唯一提議者，這樣就不存在多個提議者同時提交提案的情況，也就不存在提 案衝突的情況了。

另外，在 Chubby 中，主節點是通過執行 Basic Paxos 算法，進行投票選舉產生的，並且 在運行過程中，主節點會通過不斷續租的方式來延長租期（Lease）。比如在實際場景中， 幾天內都是同一個節點作爲主節點。如果主節點故障了，那麼其他的節點又會投票選舉出新 的主節點，也就是說主節點是一直存在的，而且是唯一的。

其次，在 Chubby 中實現了蘭伯特提到的，“當領導者處於穩定狀態時，省掉準備階段， 直接進入接受階段”這個優化機制。

後，在 Chubby 中，實現了成員變更（Group membership），以此保證節點變更的時 候集羣的平穩運行。

在 Chubby 中，爲了實現了強一致性，讀操作也只能在主節點上執 行。 也就是說，只要數據寫入成功，之後所有的客戶端讀到的數據都是一致的。具體的過 程，就是下面的樣子:

• 所有的讀請求和寫請求都由主節點來處理。當主節點從客戶端接收到寫請求後，作爲提 議者，執行 Basic Paxos 實例，將數據發送給所有的節點，並且在大多數的服務器接受 了這個寫請求之後，再響應給客戶端成功：
  
• 當主節點接收到讀請求後，處理就比較簡單了，主節點只需要查詢本地數據，然後返回 給客戶端就可以了：
  

Chubby 的 Multi-Paxos 實現，儘管是一個閉源的實現，但這是 Multi-Paxos 思想在實際 場景中的真正落地，Chubby 團隊不僅編程實現了理論，還探索瞭如何補充細節。其中的 思考和設計非常具有參考價值，不僅能幫助我們理解 Multi-Paxos 思想，還能幫助我們理 解其他的 Multi-Paxos 算法（比如 Raft 算法）。