一致性協議

Paxos是一個一致性協議。什麼叫一致性？一致性有很多種，從強到弱分了很多等級，如線性一致性、因果一致性、最終一致性，等等。什麼是一致？這裡舉個例子，三臺機器，每臺機器的磁碟儲存為128位元組，如果三臺機器這128位元組資料都完全相同，那麼可以說這三臺機器是磁碟資料是一致的，更為抽象地說，就是多個副本確定同一個值，大家記錄下來同一個值，那麼就達到了一致性。

Paxos能達到什麼樣的一致性級別？這是一個較為複雜的問題。因為一致性往往不取決於客觀存在的事實，如3臺機器雖然擁有相同的資料，但是資料的寫入是一個過程，有時間的先後，而更多的一致性取決於觀察者，觀察者看到的並未是最終的資料。這裡就先不展開講，先暫且認為Paxos保證了寫入的最終一致性。

為何說是一個協議而不是一個演算法，可以這麼理解，演算法是設計出來服務於這個協議的，如同法律是協議，那麼演算法就是各種機構的執行者，使得法律的約束能得到保證。

Paxos的協議其實很簡單，就三條規定。我認為這三條規定也是Paxos最精髓的內容，各個執行者奮力去保護這個協議，使得這個協議的約束生效，自然就得到了一致性。

分散式環境

為何要設計出這麼一套協議，其他協議不行麼？如最容易想到的，一個值A，往3臺機器都寫一次，這樣一套簡單的協議，能不能達到一致性的效果？這裡就涉及到另外一個概念，Paxos一致性協議是在特定的環境下才需要的，這個特定的環境稱為非同步通訊環境。而恰恰，幾乎所有的分散式環境都是非同步通訊環境，在計算機領域面對的問題，非常需要Paxos來解決。

非同步通訊環境指的是訊息在網路傳輸過程中，可能發生丟失、延遲、亂序現象。在這種環境下，上面提到的三寫協議就變得很雞肋了。訊息亂序是一個非常惡劣的問題，這個問題導致大部分協議在分散式環境下都無法保證一致性，而導致這個問題的根本原因是網路包無法控制超時，一個網路包可以在網路的各種裝置交換機等停留數天，甚至數週之久，而在這段時間內任意發出的一個包，都會跟之前發出的包產生亂序現象。無法控制超時的原因更多是因為時鐘的關係，各種裝置以及交換機時鐘都有可能錯亂，無法判斷一個包的真正到達時間。

非同步通訊環境並非只有Paxos能解決一致性問題，經典的兩階段提交也能達到同樣的效果，但是分散式環境裡面，除了訊息網路傳輸的惡劣環境，還有另外一個讓人痛心疾首的，就是機器的當機，甚至永久失聯。在這種情況下，兩階段提交將無法完成一個一致性的寫入，而Paxos，只要多數派機器存活就能完成寫入，並保證一致性。

至此，總結一下Paxos就是一個在非同步通訊環境，並容忍在只有多數派機器存活的情況下，仍然能完成一個一致性寫入的協議。

提議者

前面講了這麼多都是協議協議，在分散式環境當中，協議作用就是每臺機器都要扮演一個角色，這個角色嚴格遵守這個協議去處理訊息。在Paxos論文裡面這個角色稱之為Acceptor，這個很好理解。大家其實更關心另外一個問題，到底誰去發起寫入請求，論文裡面介紹發起寫入請求的角色為提議者，稱為Proposer。Proposer也是嚴格遵守paxos協議，通過與各個Acceptor的協同工作，去完成一個值的寫入。在Paxos裡面，Proposer和Acceptor是最重要的兩個角色。

確定一個值

既然說到寫入資料，到底怎麼去寫？寫一次還是寫多次，還是其他？這也是我一開始苦惱的問題，相信很多人都會很苦惱。

這裡先要明確一個問題，Paxos到底在為誰服務？更確定地說，到底在為什麼資料服務？還是引上面的例子，Paxos就是為這128位元組的資料服務，Paxos並不關心外面有多少個提議者，寫入了多少資料，寫入的資料是不是一樣的，Paxos只會跟你說，我確定了一個值，當這個值被確定之後，也就是這128位元組被確定了之後，無論外面寫入什麼，這個值都不會改變再改變了，而且三臺機確定的值肯定是一樣的。

說到這估計肯定會有人懵了，說實話我當時也懵了。我要實現一個儲存服務啊，我要寫入各種各樣的資料啊，你給我確定這麼一個值，能有啥用？但先拋開這些疑問，大家先要明確這麼一個概念，Paxos就是用來確定一個值用的，而且大家這裡就先知道這麼個事情就可以了，具體Paxos協議是怎樣的，怎麼通過協議裡面三條規定來獲得這樣的效果的，怎麼證明的等等理論上的東西，都推薦去大家去看看論文，但是先看完本文再看，會得到另外的效果。

如下圖，有三臺機器（後面為了簡化問題，不做特別說明都是以三臺機器作為講解例子），每臺機器上執行這Acceptor來遵守paxos協議，每臺機器的Acceptor為自己的一份Data資料服務，可以有任意多個Proposer。當Paxos協議宣稱一個值被確定（Chosen）後，那麼Data資料就會被確定，並且永遠不會被改變。

Proposer只需要與多數派的Acceptor互動，即可完成一個值的確定，但一旦這個值被確定下來後，無論Proposer再發起任何值的寫入，Data資料都不會再被修改。Chosen value即是被確定的值，永遠不會被修改。

確定多個值

對我們來說，確定一個值，並且當一個值確定後是永遠不能被修改的，很明顯這個應用價值是很低的。雖然我都甚至還不知道確定一個值能用來幹嘛，但如果我們能有辦法能確定很多個值，那肯定會比一個值有用得多。我們先來看下怎麼去確定多個值。

上文提到一個三個Acceptor和Proposer各自遵守paxos協議，協同工作最終完成一個值的確定。這裡先定義一個概念，Proposer，各個Acceptor，所服務的Data共同構成了一個大的集合，這個集合所執行的paxos演算法最終目標是確定一個值，我們這裡稱這個集合為一個Paxos例項。

一個例項可以確定一個值，那麼多個例項自然可以確定多個值，很簡單的模型就可以構建出來，只要我們同時執行著多個例項，那麼我們就能完成確定多個值的目標。

這裡強調一點，每個例項必須是完全獨立，互不干涉的。意思就是說Acceptor不能去修改其他例項的Data資料，Proposer同樣也不能跨越例項去與其他例項的Acceptor互動。

如下圖，三臺機器每臺機器執行兩個例項，每個例項獨立運作，最終會產生兩個確定的值。這裡兩個實際可以擴充套件成任意多個。

至此，例項成為了我現在介紹Paxos的一個基本單元，一個例項確定一個值，多個例項確定多個值，但各個例項獨立，互不干涉。

然而比較遺憾的一點，確定多個值，仍然對我們沒有太大的幫助，因為裡面最可恨的一點是，當一個值被確定後，就永遠無法被修改了，這是我們不能接受的。大部分的儲存服務可能都需要有一個修改的功能。

有序確定多個值

我們需要轉換一下切入點，也許我們需要Paxos確定的值，並不一定是我們真正看到的資料。我們觀察大部分儲存系統，如LevelDB，都是以AppendLog的形式，確定一個操作系列，而後需要恢復儲存的時候都可以通過這個操作系列來恢復，而這個操作系列，正是確定之後就永遠不會被修改的。到這已經很豁然開朗了，只要我們通過Paxos完成一個多機一致的有序的操作系列，那麼通過這個操作系列的演進，可實現的東西就很有想象空間了，儲存服務必然不是問題。

如何利用Paxos有序的確定多個值？上文我們知道可以通過執行多個例項來完成確定多個值，但為了達到順序的效果，需要加強一下約束。

首先給例項一個編號，定義為i，i從0開始，只增不減，由本機器生成，不依賴網路。其次，我們保證一臺機器任一時刻只能有一個例項在工作，這時候Proposer往該機器的寫請求都會被當前工作的例項受理。最後，當編號為i的例項獲知已經確定好一個值之後，這個例項將會被銷燬，進而產生一個編號為i+1的例項。

基於這三個約束，每臺機器的多個例項都是一個連續遞增編號的有序系列，而基於Paxos的保證，同一個編號的例項，確定的值都是一致的，那麼三臺機都獲得了一個有序的多個值。

下面結合一個圖來詳細說明一下這個運作過程，以及存在什麼異常情況以及異常情況下的處理方式。

圖中A，B，C代表三個機器，紅色代表已經被銷燬的例項，根據上文約束，最大的例項就是當前正在工作的例項。A機器當前工作的例項編號是6，B機是5，而C機是3。為何會出現這種工作例項不一樣的情況？首先解釋一下C機的情況，由於Paxos只要求多數派存活即可完成一個值的確定，所以假設C出現當機或者訊息丟失延遲等，都會使得自己不知道3-5編號的例項已經被確定好值了。而B機比A機落後一個例項，是因為B機剛剛參與完成例項5的值的確定，但是他並不知道這個值被確定了。上面的情況與其說是異常情況，也可以說是正常的情況，因為在分散式環境，發生這種事情是很正常的。

下面分析一下基於圖示狀態的對於C機的寫入是如何工作的。C機例項3處理一個新的寫入，根據Paxos協議的保證，由於例項3已經確定好一個值了，所以無論寫入什麼值，都不會改變原來的值，所以這時候C機例項3發起一輪Paxos演算法的時候就可以獲知例項3真正確定的值，從而跳到例項4。但在工程實現上這個事情可以更為簡化，上文提到，各個例項是獨立，互不干涉的，也就是A機的例項6，B機的例項5都不會去理會C機例項3發出的訊息，那麼C機例項3這個寫入是無法得到多數派響應的，自然無法寫入成功。

再分析一下A機的寫入，同樣例項6無法獲得多數派的響應，同樣無法寫入成功。同樣假如B機例項5有寫入，也是寫入失敗的結果，那如何使得能繼續寫入，例項編號能繼續增長呢？這裡引出下一個章節。

例項的對齊（Learn）

上文說到每個例項裡面都有一個Acceptor的角色，這裡再增加一個角色稱為Learner，顧名思義就是找別人學習，她回去詢問別的機器的相同編號的例項，如果這個例項已經被銷燬了，那說明值已經確定好了，直接把這個值拉回來寫到當前例項裡面，然後編號增長跳到下一個例項再繼續詢問，如此反覆，直到當前例項編號增長到與其他機器一致。

由於約束裡面保證僅當一個例項獲知到一個確定的值之後，才能編號增長開始新的例項，那麼換句話說，只要編號比當前工作例項小的例項（已銷燬的），他的值都是已經確定好的。所以這些值並不需要再通過Paxos來確定了，而是直接由Learner直接學習得到即可。

如上圖所示，B機的例項5是直接由Learner從A機學到的，而C機的例項3-5都是從B機學到的，這樣大家就全部走到了例項6，這時候例項6接受的寫請求就能繼續工作下去。

狀態機

一個有序的確定的值，也就是日誌，可以通過定義日誌的語義進行重放的操作，那麼這個日誌是怎麼跟Paxos結合起來的呢？我們利用Paxos確定有序的多個值這個特點，再加上這裡引入的一個狀態機的概念，結合起來實現一個真正有工程意義的系統。

狀態機這個名詞大家都不陌生，一個狀態機必然涉及到一個狀態轉移，而Paxos的每個例項，就是狀態轉移的輸入，由於每臺機器的例項編號都是連續有序增長的，而每個例項確定的值是一樣的，那麼可以保證的是，各臺機器的狀態機輸入是完全一致的。根據狀態機的理論，只要初始狀態一致，輸入一致，那麼引出的最終狀態也是一致的。而這個狀態，是有無限的想象空間，你可以用來實現非常多的東西。

如下圖這個例子是一個狀態機結合Paxos實現了一個具有多機一致的KV系統。

例項0-3的值都已經被確定，通過這4個值最終引出(b, ‘jeremy’)這個狀態，而各臺機器例項系列都是一致的，所以大家的狀態都一樣，雖然引出狀態的時間有先後，但確定的例項系列確定的值引出確定的狀態。

下圖例子告訴大家Proposer，Acceptor，Learner，State machine是如何協同工作的。

一個請求發給Proposer，Proposer與相同例項編號為x的Acceptor協同工作，共同完成一值的確定，之後將這個值作為狀態機的輸入，產生狀態轉移，最終返回狀態轉移結果給發起請求者。