版權聲明：本文為博主原創文章，未經博主允許不得轉載。 https://blog.csdn.net/feilengcui008/article/details/50843779

上一篇文章推導了基本Paxos算法，并引出了在實際使用中其存在的問題，然后說明了leader-based分布式一致算法的優勢。這篇文章分析一下選主的本質，選出一個主對整個算法的影響，以及采用選主會存在的問題以及基本Paxos協議是怎么樣保證這些問題不會影響一致性的。

1.為什么選主

至于為什么選主？個人認為有如下原因：

• 避免并發決議導致的livelock和新丟失的問題

• 可以采用一定方法在選主時(raft)，選主中或者選主后保證leader上有最新的達成多數派(達成多數派應該用多數派已經將值寫入持久化日志來判定)，這樣可以優化針對同一個項的讀請求，不然每次客戶端讀請求也需要走一遍基本Paxos

• 選出leader可以保證在一個leader的統治期間內只有這一個leader可以接收客戶端請求，發起決議(至于腦裂的問題，后面會分析)，

2.不同的選主算法，其本質是什么？

前面說了在一個leader統治期間內，不可能存在多個leader同時對一個項達成多數派(如果一個leader也沒有自然滿足，包括腦裂后面會分析到也是滿足的)，但是對于選主本身來說，實際上其本質上就是一個分布式一致性問題，并且可能有多個proposer并發提出選主決議，所以可以使用基本Paxos來解決，這就回到了基本的Paxos算法了！所以我們需要為每次選主決議編號，比如raft算法的term，這個實際上就對應基本Paxos算法的proposal id。

3.選主后對整個算法造成什么影響？

前面提到了”選出leader可以保證在一個leader的統治期間內只有這一個leader可以接收客戶端請求，發起決議”。這樣實際上基本Paxos的第一階段prepare就沒有必要了，因為對于下一個項來說，在這個leader統治期內，在達成多數派之前，不可能有其他人提出決議并達成多數派，所以可以直接使用客戶端的值進入第二階段accept。

4.選主可能會導致的問題？

最大的問題應該是腦裂了，也就是說可能存在多個分區多個leader接收客戶端響應，但是由于多數派的限制，只能最多有一個分區能達成多數派。我們假設最簡單的情況，A/B/C/D/E五臺機器，兩個分區P1有三臺A/B/C和P2有兩臺D/E，那么可能的情況是：

(1).P1有leader；P2沒有leader

(2).P1有leader；P2也有leader

顯然由于多數派的限制，只有P1可能達成決議

5.新的leader選出來后的操作

一般來說，新的leader選出來后，我們需要對leader進行日志恢復，以便leader決定下一次客戶端請求的時候該用哪個日志槽位或者說哪個項吧，這里也是不同的算法差異較大的地方，比如raft，viewstamped replication，zab以及lamport 《Paxos Made Simple》里面第三節描述的方法。在lamport論文的描述中，還是采用基本的Paxos，對未明確知道達成多數派的項重新走一遍基本Paxos算法，具體可以參照原論文，細節還是挺多。對于raft來說，由于其保證日志是連續的，且保證在選主的時候只選擇具有最新的日志的機器，所以選主之后，新的leader上的日志本身就是最新的。

下一篇會著重分析在新的leader選舉后，新leader怎么恢復日志記錄以及怎么確定已提交的日志，這一點還是通過對比lamport在《Paxos Made Simple》第三節提到的方法以及raft中的實現來說明。

總結

以上是生活随笔為你收集整理的Distributed Systems-leader based分布式一致性协议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。