Paxos算法可以說是一致性領域最著名的算法之一了。

這幾天仔細讀了幾遍 Leslie Lamport的論文 《Paxos Made Simple》 ，可以說對paxos有了簡單的理解，Lamport的證明過程簡單靈巧，用他論文的Abstract來說就是： The Paxos algorithm, when presented in plain English, is very simple。

強烈推薦感興趣的朋友去讀一下這篇論文。下面講解的內(nèi)容可能不完全跟論文思路相同，會有一點自己的語言和想法在里面。證明的過程會有所省略，因為這篇的目的不是把證明過程完完整整講清楚，是想讓大家更容易的對Paxos算法有一個初步的理解。想看證明過程的朋友不妨去看這篇論文，畢竟才11頁看起來很快。

The Problem

首先我們假設一個場景，這里有很多的進程，每個進程都可以propose（提議）一個value，共識算法是為了保證：

在眾多proposed value中，只有一個value會被選中。

如果沒有進程propose任何的value，那么最后不會有value被選中。

如果某一個value被選中了，那么所有的進程都應該可以知道這個value。

對于這個算法，有以下三個安全性需求（給出英文以防翻譯不當）：

只有一個被propose過的value，才可能被選中（Only a value that has been proposed may by chosen）。

只會有一個value被選中（Only a single value is chosen）。

只有當一個value確確實實被選中了，進程才會知道（A process never learns that a value has been chosen unless it actually has been）。

下面即將進入證明的過程，首先介紹以下會出現(xiàn)的三種角色：proposer, acceptor以及l(fā)earner。proposer的工作就是上文說過的propose value，并發(fā)送給acceptor；acceptor的工作就是接收從proposer那里發(fā)來的信息，根據(jù)情況給出反饋信息；learner的工作就是得知已經(jīng)被選中的value。

最后的目的就是保證：超過半數(shù)（the majority set）的acceptor選擇了同一個value，并且learner可以得知這個value被選中了。

Choosing a Value

這個部分論文中有詳細的推導過程，我們直接跳到推導的結果部分。其間新添加了一個參數(shù)：每個proposer發(fā)送的proposal（即發(fā)送給Acceptor，用來提議value的信息）中，都包括兩個參數(shù)。一個用來標識proposal的proposal number，另一個是所提議的value。所以proposal形如<proposal number, proposed value>。（ 為了避免混淆，下文統(tǒng)一稱proposal number為編號）

進過推導，最后得出的 proposer的算法如下：

proposer選擇一個新的編號n（注意是編號，不是proposal），發(fā)送request給acceptor，并要求它們回復以下兩點：(a). 承諾以后不會接收比n小的編號的proposal； (b). 回復曾經(jīng)接收過的，編號小于n中的所有proposal中編號最大的那個proposal。（翻譯過來有點繞嘴，給出英文原文：(b). The proposal with the highest number less than n that it has accepted, if any.）——這里我們把這樣的request起名叫做prepare request

如果proposer收到了超過半數(shù)的accepter的回復的話，他就可以提出一個proposal了。這個proposal = <proposal number n, Value v>。其中v是所有回復中，有最高編號的那個proposal的value值(上面b中提到的編號)。另外一種情況如果所有的回復都顯示，目前acceptor們都沒有接受過任何一個proposal，那么這種情況該proposer可以自己隨便選擇一個value發(fā)送給acceptor。—— 這里我們把這樣的request起名叫做accept request

然后是相應得出的acceptor的算法：

如果acceptor收到了一個新的prepare request，并且編號n大于它曾經(jīng)回復過的任何prepare request的編號的話。acceptor就會回復保證不會再接收編號小于n的任何proposal，并且回復曾經(jīng)收到的過prepare request中最大的編號（如果曾經(jīng)收到過的話）。

如果收到了accept request，并且其中的編號為n。acceptor在沒有回復過比n更大的編號的prepare request的情況下，會接受這個accept request。

至此，就是proposer和acceptor的算法。下面還有在此基礎上進一步的內(nèi)容。

Learning a Chosen Value

想要得知是否已經(jīng)有一個value被算法選擇出來了，learner需要去查詢是否有超過半數(shù)的acceptor已經(jīng)接受了某個proposal。最簡單的實現(xiàn)肯定是，所有的acceptor在接受了一個proposal之后，給所有的learner發(fā)送消息。這種情況下所有的learner都可以第一時間發(fā)現(xiàn)the chosen value。但是這樣做的信息數(shù)量太多了，需要優(yōu)化。

于是我們可以在所有的learner中選出一個負責人（Distinguished Learner），所有的acceptor都把消息發(fā)給它，然后它轉發(fā)給其他所有的learner。這種方法雖然效率很高，但是如果被選出的負責人fail了，系統(tǒng)就無從得知the chosen value了。

更一般性的實現(xiàn)就是，選出幾個負責人，他們一起從事上述的工作，雖然增加了一點消息數(shù)量，但是安全性得到了很大提升。（后面兩種實現(xiàn)都可以）

Progress

還有一點點問題需要解決，假設有兩個proposer不斷地發(fā)出proposal，每次都比對方的編號大1。這樣就會導致兩個人的所有proposal都不會被采納（原因看上面算法很容易分析）。

為了解決這個問題，我們需要同樣選出一個proposer中的負責人（Distinguished proposer），使得只有這個負責人去負責提出proposal，這樣就可以解決上述問題。

The Implementation

上面三部分就講完了整個paxos算法了。

所以我們假設的這個進程系統(tǒng)中，paxos算法一共需要三種角色：proposer，acceptor和learner（每個進程可以擔當多個角色）。并且需要選出一個或者多個leader來擔當負責人（Distinguished proposer/learner）。

但是在我講述這個算法的過程中有很多前提或者假設都被省略掉了，比如：

• 我們的系統(tǒng)是customary asynchronous, non-Byzantine model。
• 所有的角色都以任意的速度進行操作，有可能遭遇failure或者重啟。
• 所有的消息都經(jīng)過任意長的時間才會被接收到，而且可能出現(xiàn)重復甚至丟失，但是不會被損壞。

所以很慚愧的說我這篇文章是很不嚴謹?shù)?#xff0c;只是把論文中paxos算法簡明的講述了出來，如果有漏洞甚至理解錯誤的地方，希望大家不吝賜教。

https://zhuanlan.zhihu.com/p/25438477

總結

以上是生活随笔為你收集整理的Paxos算法小结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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