4.2　Paxos演算法

首先，Paxos演算法解決的是非拜占庭將軍問題，也就是說僅僅是指分散式系統中的節點存在故障，但是不存在惡意節點的場景，在這種情況下如何達成共識。

1998年Lamport提出Paxos演算法，後續又增添多個改進版本的Paxos，形成Paxos協議家族。Paxos協議家族有一個共同的特點就是不易於工程實現，Google的分散式鎖系統Chubby作為Paxos實現曾經遭遇到很多坑。

除了經典Paxos（又名Basic Paxos），以下均為Paxos的變種，基於CAP定律，側重了不同方向。

·Cheap Paxos

·Egalitarian Paxos

·Fast Paxos

·Multi-Paxos

·Byzanetine Paxos

Paxos演算法實在是太晦澀難懂，上面所列的Paxos演算法分支就不詳細介紹了。如果要想了解一下經典Paxos演算法的最初描述，可以去看一下Lamport的論文《Paxos Made Simple》，在這個演算法模型中，使用到了如下的角色：

看到這些角色，有沒有覺得很像現代的議會制度。Paxos正是這樣的一個模型，當然在計算機中這些所謂的“人”一般就 是指節點，這些角色可以是不同的服務節點也可以是同一個服務節點兼任。提案發出後，就要爭取大多數的投票支援，當超過一半支援的時候，傳送一半結果給所有 人進行確認，也就是說Paxos能保證在超過一半的正常節點存在時，系統達成共識。提案過程還可以劃分不同的場景，如下所示：

（1）單個提案者+多個接收者

這種情況下，一致性容易達成，或者說肯定能達成，因為只有一個提案，要麼達成，要麼否決或者失敗。但是這種情況下，這個唯一的提案者如果出故障，則整個系統就失效了。

（2）多個提案者+單個接收者

這種情況下也容易達成共識，對於接收者，選擇一個作為決議即可，當然這種情況也屬於單點故障結構。

（3）多個提案者+多個接收者

這種情況，首先是避免了單點故障，但是問題也變得複雜了，既然提案和接收者都有多個，那以哪個為準呢？並沒有特別玄妙的辦法，既然多個在一起不好解決，那還是得回到單個提案者上去，只不過增加個規則選出那麼一個單個提案者來，大致可以有如下的兩個方案：

1）與第一種情況靠近，也就是想個辦法選出一個提案者出來，約定在某一個時間段內，只允許一個提案通過，可以設定一些競爭規則或者按照一個時間序列的排列選擇，總之最後會選出一個提案者。

2）與第二種情況靠近，允許有多個提案者，但是當節點收到多份提案後，通過某個規則選出一份提案，也就是仍然保持只接收一份，規則可以有各種，比如根據提案序號排列或者根據提案時間等。

實際上，在網路中，類似比特幣這種，必然是屬於多對多的這種情況，傳送轉賬交易的節點不止一個，礦工不止一個，接收區塊進行驗證的節點當然也不止一個，Paxos中為了解決這樣的問題，引入了稱為“兩階段提交”的方案。所謂兩階段，就是“準備”和“提交”兩個階段：準備階段解決大家對哪個提案進行投票的問題，提交階段解決確認最終值的問題。上述這個過程中，可能會一直有新的提案出現，因此類似於比特幣一樣，分隔一下時間，比如每隔10分鐘打包一次，而打包者只能有一個。

在提交階段，如果一個提案者在準備階段接收到大多數節點的回覆，則會發出確認訊息，如果再次收到大多數的回覆，則 保持原先的提案編號和內容；如果收到的訊息中有更新的提案，則替換為更新的提案內容；如果沒有收到大多數的回覆，則再次發出請求，等待其他節點的回覆確 認。當接收者發現提案號與自己目前保留的一致，則對提案進行確認。

就個人的理解，這種做法如果是在一個相對私有的環境中或者網路環境比較好的情況下，效果會比較明顯，實際上，所謂的收到大多數的回應，這也是節點自身的一個評估，因為節點並沒有更好的辦法去判斷，到底算不算是大多數了，尤其是節點總數還不固定的情況下。

來源：我是碼農，轉載請保留出處和連結！

本文連結：http://www.54manong.com/?id=97

'); (window.slotbydup = window.slotbydup || []).push({ id: "u3646208", container: s }); })(); '); (window.slotbydup = window.slotbydup || []).push({ id: "u3646147", container: s }); })();