目錄

• Basic Paxos
• • 三個角色
  • 達(dá)成共識的方法
  • 對于Basic Paxos的總結(jié)
• Multi-Paxos
• • 領(lǐng)導(dǎo)者
  • 優(yōu)化 Basic Paxos 執(zhí)行
• reference

Paxos 算法包含 2 個部分：
1、Basic Paxos ： 描述多節(jié)點之間如何就某個值達(dá)成共識
2、Multi-Paxos ： 描述執(zhí)行多個Basic Paxos實例，對一系列值達(dá)成共識

Basic Paxos

三個角色

該算法中存在三個角色：提議者、接受者、學(xué)習(xí)者，關(guān)系如下：

提議者：提議一個值，用于投票表決。在大多數(shù)場景中，往往是集群中收到客戶端請求的節(jié)點時提議者。這樣對于業(yè)務(wù)代碼就沒有侵入性，不需要再業(yè)務(wù)代碼中實現(xiàn)算法邏輯。
接受者：對每個提議的值進(jìn)行投票，并存儲接受的值。一般來說，集群中的所有節(jié)點都是接受者，參與共識協(xié)商，并接受和存儲數(shù)據(jù)
注意：一個節(jié)點可以擔(dān)任多個角色，如下：

學(xué)習(xí)者：被告知投票的結(jié)果，接受達(dá)成共識的值，存儲保存，不參與投票的過程。一般來說，學(xué)習(xí)者是數(shù)據(jù)備份節(jié)點，比如“Master - Slave”模型中的Slave，被動接受數(shù)據(jù)，容災(zāi)備份。
三個角色代表三種功能：

• 1、提議者代表接入和協(xié)調(diào)功能，收到客戶端請求后，發(fā)起二階段提交，進(jìn)行共識協(xié)商
• 2、接受者代表協(xié)商和存儲數(shù)據(jù)，對提議的值進(jìn)行投票，并接受達(dá)成共識的值，存儲保存
• 3、學(xué)習(xí)者代表存儲數(shù)據(jù)，不參與共識協(xié)商，只接受達(dá)成共識的值，存儲保存

達(dá)成共識的方法

分為準(zhǔn)備階段和接受階段。
這里假設(shè)兩個客戶端作為提議者和3個節(jié)點作為接受者，
客戶端1的想要對節(jié)點中的Key為X的數(shù)據(jù)將Value設(shè)置為3，客戶端2的想要對節(jié)點中的Key為X的數(shù)據(jù)將Value設(shè)置為5。
提議者發(fā)送給接受者的信息我們稱為提案，結(jié)構(gòu)為[n,v]，n為提案編號（相當(dāng)于事務(wù)ID，后發(fā)起的提案編號越大），v為提議值（寫入db的值）
準(zhǔn)備階段
在準(zhǔn)備階段，兩個提議者分別向所三個接受者發(fā)送包含提案編號的準(zhǔn)備請求，準(zhǔn)備請求中只包含提案編號。并假設(shè)接受者節(jié)點收到準(zhǔn)備請求的時序圖如下：

接下來是各個接受者節(jié)點對于先收到的準(zhǔn)備請求的響應(yīng)。由于之前沒有通過任何提案，A,B,C都會返回“尚無提案”的響應(yīng)。
但是有所不同的是，A,B會告訴提議者，不再響應(yīng)提案編號 <= 1的準(zhǔn)備請求，C會告訴提議者，不再響應(yīng)提案編號 <= 5的準(zhǔn)備請求.
也就是說每個節(jié)點之后接受比當(dāng)前提案編號大的請求。

接下來是各個接受者第二次收到準(zhǔn)備請求的響應(yīng)。
A,B收到的請求，編號為5 >= 1 ，并且此時兩個節(jié)點沒有通過任何提案，所以返回“尚無提案”響應(yīng)，并不再響應(yīng)提案編號 <= 5的準(zhǔn)備請求.
C收到的請求，編號為1 < 5 ,所以丟棄該準(zhǔn)備請求，不做響應(yīng)。

接受階段
兩個提議者節(jié)點在收到大多數(shù)節(jié)點的準(zhǔn)備響應(yīng)之后，會分別發(fā)送接受請求。
對于客戶端1來說，根據(jù)響應(yīng)中提案編號最大的提案的值，設(shè)置接受請求中的值。（客戶端1只有來自A,B的準(zhǔn)備響應(yīng)），因為響應(yīng)均為”尚無提案“，所以客戶端1會將自己的提議值：3，作為提案值，然后發(fā)送接受請求[n, v] : [1,3];
對于客戶端2來說，根據(jù)響應(yīng)中提案編號最大的提案的值，設(shè)置接受請求中的值。（客戶端2來自A,B,C的準(zhǔn)備響應(yīng)），因為響應(yīng)均為”尚無提案“，所以客戶端1會將自己的提議值：7，作為提案值，然后發(fā)送接受請求[n, v] : [5,7];

三個接受者節(jié)點收到兩個提議者的接受請求，會進(jìn)行處理：
對于A,B,C節(jié)點來說，它們對于請求[1,3]，都不會接受，因為提案編號 < 5（最小提案編號）。
它們對于請求[5,7]都會接受，因為提案編號 >= 5,通過提案之后，將提案值：7作為X的Value。

對于Basic Paxos的總結(jié)

根據(jù)提案編號的大小，接受者保證三個承諾，具體來說：

如果準(zhǔn)備請求的提案編號，小于等于接受者已經(jīng)響應(yīng)的準(zhǔn)備請求的提案編號，那么接受者將承諾不響應(yīng)這個準(zhǔn)備請求；

如果接受請求的提案編號，小于接受者已經(jīng)響應(yīng)的準(zhǔn)備請求的提案編號，那么接受者將承諾不通過這個提案；

如果接受者之前有通過提案，那么接受者將承諾，會在準(zhǔn)備請求的響應(yīng)中，包含已經(jīng)通過的最大編號的提案信息。

Multi-Paxos

Basic Paxos 只能就單個值（Value）達(dá)成共識，一旦遇到為一系列的值實現(xiàn)共識的時候，它就不管用了。
它具有兩個缺點：
1、如果多個提議者同時提交提案，可能出現(xiàn)因為提案編號沖突，在準(zhǔn)備階段沒有提議者接收到大多數(shù)準(zhǔn)備響應(yīng)，協(xié)商失敗，需要重新協(xié)商
2、2 輪 RPC 通訊（準(zhǔn)備階段和接受階段）往返消息多、耗性能、延遲大。

可以通過通過引入領(lǐng)導(dǎo)者和優(yōu)化 Basic Paxos 執(zhí)行來解決這兩個問題。

領(lǐng)導(dǎo)者

領(lǐng)導(dǎo)者節(jié)點作為唯一提議者，就不會存在多個提議者同時提交提案的情況，也就不存在提案沖突了。
模型結(jié)構(gòu)如下：

如何選舉領(lǐng)導(dǎo)者需要我們在Multi-Paxos自己實現(xiàn)。
在Chubby中，主節(jié)點是通過執(zhí)行 Basic Paxos 算法，進(jìn)行投票選舉產(chǎn)生的，并且在運行過程中，主節(jié)點會通過不斷續(xù)租的方式來延長租期（Lease）。比如在實際場景中，幾天內(nèi)都是同一個節(jié)點作為主節(jié)點。如果主節(jié)點故障了，那么其他的節(jié)點又會投票選舉出新的主節(jié)點，也就是說主節(jié)點是一直存在的，而且是唯一的。
所有的讀請求和寫請求都由主節(jié)點來處理。當(dāng)主節(jié)點從客戶端接收到寫請求后，作為提議者，執(zhí)行 Basic Paxos 實例，將數(shù)據(jù)發(fā)送給所有的節(jié)點，并且在大多數(shù)的服務(wù)器接受了這個寫請求之后，再響應(yīng)給客戶端成功：

當(dāng)主節(jié)點接收到讀請求后，處理就比較簡單了，主節(jié)點只需要查詢本地數(shù)據(jù)，然后返回給客戶端就可以了：

缺點就是所有寫請求都在主節(jié)點處理，限制了集群處理寫請求的并發(fā)能力，約等于單機(jī)。

優(yōu)化 Basic Paxos 執(zhí)行

下面兩個圖是 Basic Paxos 以及有領(lǐng)導(dǎo)者的優(yōu)化執(zhí)行。

圖1 Basic Paxos

圖2 優(yōu)化之后

可以看到，當(dāng)領(lǐng)導(dǎo)者處于穩(wěn)定狀態(tài)時，省掉準(zhǔn)備階段，直接進(jìn)入接受階段。這是因為領(lǐng)導(dǎo)者節(jié)點上的命令時最新的，不需要通過準(zhǔn)備請求來發(fā)現(xiàn)之前被大多數(shù)節(jié)點通過的提案，領(lǐng)導(dǎo)者可以獨立指定提案中的值。 如何理解領(lǐng)導(dǎo)者處于穩(wěn)定狀態(tài)？領(lǐng)導(dǎo)者節(jié)點上，序列中的命令是最新的，不再需要通過準(zhǔn)備請求來發(fā)現(xiàn)之前被大多數(shù)節(jié)點通過的提案，領(lǐng)導(dǎo)者可以獨立指定提案中的值。準(zhǔn)備階段的意義，是發(fā)現(xiàn)接受者節(jié)點上，已經(jīng)通過的提案的值。如果在所有接受者節(jié)點上，都沒有已經(jīng)通過的提案了，這時，領(lǐng)導(dǎo)者就可以自己指定提案的值了，那么，準(zhǔn)備階段就沒有意義了，也就是可以省掉了。

本質(zhì)上而言，“當(dāng)領(lǐng)導(dǎo)者處于穩(wěn)定狀態(tài)時，省掉準(zhǔn)備階段，直接進(jìn)入接受階段”這個優(yōu)化機(jī)制，是通過減少非必須的協(xié)商步驟來提升性能的。這種方法非常常用，也很有效。比如，Google 設(shè)計的 QUIC 協(xié)議，是通過減少 TCP、TLS 的協(xié)商步驟，優(yōu)化 HTTPS 性能。

reference

《分布式協(xié)議與算法實戰(zhàn).韓健》

總結(jié)

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

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