分散式系統理論基礎5：選舉、多數派和租約

本文轉自： https://www.cnblogs.com/bangerlee/p/5767845.html

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視

https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章首發於我的個人部落格：

www.how2playlife.com

該系列博文會告訴你什麼是分散式系統，這對後端工程師來說是很重要的一門學問，我們會逐步瞭解分散式理論中的基本概念，常見演算法、以及一些較為複雜的分散式原理，同時也需要進一步瞭解zookeeper的實現，以及CAP、一致性原理等一些常見的分散式理論基礎，以便讓你更完整地瞭解分散式理論的基礎，為後續學習分散式技術內容做好準備。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

選舉(election)是分散式系統實踐中常見的問題，通過打破節點間的對等關係，選得的leader(或叫master、coordinator)有助於實現事務原子性、提升決議效率。 多數派(quorum)的思路幫助我們在網路分化的情況下達成決議一致性，在leader選舉的場景下幫助我們選出唯一leader。租約(lease)在一定期限內給予節點特定權利，也可以用於實現leader選舉。

下面我們就來學習分散式系統理論中的選舉、多數派和租約。

選舉(electioin)

一致性問題(consistency)是獨立的節點間如何達成決議的問題，選出大家都認可的leader本質上也是一致性問題，因而如何應對當機恢復、網路分化等在leader選舉中也需要考量。

Bully演算法 ^[1]是最常見的選舉演算法，其要求每個節點對應一個序號，序號最高的節點為leader。leader當機後次高序號的節點被重選為leader，過程如下：

(a). 節點4發現leader不可達，向序號比自己高的節點發起重新選舉，重新選舉訊息中帶上自己的序號

(b)(c). 節點5、6接收到重選資訊後進行序號比較，發現自身的序號更大，向節點4返回OK訊息並各自向更高序號節點發起重新選舉

(d). 節點5收到節點6的OK訊息，而節點6經過超時時間後收不到更高序號節點的OK訊息，則認為自己是leader

(e). 節點6把自己成為leader的資訊廣播到所有節點

回顧 《分散式系統理論基礎 - 一致性、2PC和3PC》就可以看到，Bully演算法中有2PC的身影，都具有提議(propose)和收集反饋(vote)的過程。

在一致性演算法 Paxos、ZAB ^[2]、Raft ^[3]中，為提升決議效率均有節點充當leader的角色。ZAB、Raft中描述了具體的leader選舉實現，與Bully演算法類似ZAB中使用zxid標識節點，具有最大zxid的節點表示其所具備的事務(transaction)最新、被選為leader。

多數派(quorum)

在網路分化的場景下以上Bully演算法會遇到一個問題，被分隔的節點都認為自己具有最大的序號、將產生多個leader，這時候就需要引入多數派(quorum) ^[4]。多數派的思路在分散式系統中很常見，其確保網路分化情況下決議唯一。

多數派的原理說起來很簡單，假如節點總數為2f+1，則一項決議得到多於 f 節點贊成則獲得通過。leader選舉中，網路分化場景下只有具備多數派節點的部分才可能選出leader，這避免了多leader的產生。

多數派的思路還被應用於副本(replica)管理，根據業務實際讀寫比例調整寫副本數V _w、讀副本數V _r，用以在可靠性和效能方面取得平衡 ^[5]。

租約(lease)

選舉中很重要的一個問題，以上尚未提到：怎麼判斷leader不可用、什麼時候應該發起重新選舉？最先可能想到會通過心跳(heart beat)判別leader狀態是否正常，但在網路擁塞或瞬斷的情況下，這容易導致出現雙主。

租約(lease)是解決該問題的常用方法，其最初提出時用於解決分散式快取一致性問題 ^[6]，後面在分散式鎖 ^[7]等很多方面都有應用。

租約的原理同樣不復雜，中心思想是每次租約時長內只有一個節點獲得租約、到期後必須重新頒發租約。假設我們有租約頒發節點Z，節點0、1和2競選leader，租約過程如下：

(a). 節點0、1、2在Z上註冊自己，Z根據一定的規則(例如先到先得)頒發租約給節點，該租約同時對應一個有效時長；這裡假設節點0獲得租約、成為leader

(b). leader當機時，只有租約到期(timeout)後才重新發起選舉，這裡節點1獲得租約、成為leader

租約機制確保了一個時刻最多隻有一個leader，避免只使用心跳機制產生雙主的問題。在實踐應用中，zookeeper、ectd可用於租約頒發。

小結

在分散式系統理論和實踐中，常見leader、quorum和lease的身影。分散式系統內不一定事事協商、事事民主，leader的存在有助於提升決議效率。

本文以leader選舉作為例子引入和講述quorum、lease，當然quorum和lease是兩種思想，並不限於leader選舉應用。

最後提一個有趣的問題與大家思考，leader選舉的本質是一致性問題，Paxos、Raft和ZAB等解決一致性問題的協議和演算法本身又需要或依賴於leader，怎麼理解這個看似“蛋生雞、雞生蛋”的問題？ ^[8]

[1] Elections in a Distributed Computing System, Hector Garcia-Molina, 1982

[2] ZooKeeper’s atomic broadcast protocol: Theory and practice, Andre Medeiros, 2012

[3] In Search of an Understandable Consensus Algorithm, Diego Ongaro and John Ousterhout, 2013

[4] A quorum-based commit protocol, Dale Skeen, 1982

[5] Weighted Voting for Replicated Data, David K. Gifford, 1979

[6] Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency, Cary G. Gray and David R. Cheriton, 1989

[7] The Chubby lock service for loosely-coupled distributed systems, Mike Burrows, 2006

[8] Why is Paxos leader election not done using Paxos?