建議沒有閱讀前面文章的讀者可以先花少許時間閱讀一下

Master

開門見山，我們先明確一下Master的定義。Master是一個角色，這個角色的特點是，在我們選定的一些節點集合內，任一時刻，僅有一個節點成為Master或者沒有任何節點成為Master。這是一個非常嚴格的單點定義。

Master的應用非常廣泛。比如在分散式儲存裡面，我們希望讀取一個最新的值，那麼常見的做法是我們先選舉出一個Master，讀寫都經由Master來完成，那麼在Master上讀取到的就肯定是最新的。另外還比如一些仲裁模組，往往也希望有Master來協助。

Master選舉與Paxos的關係

如何選舉Master？由於Master具有嚴格的單點定義，那麼必須有一個強一致性的演算法才能完成選舉，當然我們這裡採用了Paxos。但Master選舉演算法自身也是一個通用性的演算法，它可以與任何強一致性演算法搭配來完成，而無需要求一定是Paxos。所以這裡我們希望設計一個與Paxos完全解耦的工程實現，也就是Master選舉只用到Paxos工程實現的API，而無需侵入Paxos演算法內部。

Paxos的工程應用

這個涉及到Paxos工程上API設計以及狀態機，這裡先不展開講，來看一張圖相信大家就懂了，圖片來自論文”Paxos Made Live”

Paxos的應用簡明來講就是由演算法確定一個操作系列，通過編寫這些操作系列的callback（也就是狀態機的狀態轉移函式），使得節點進行相同順序的callback，從而保證各個節點的狀態一致。

Master選舉租約演算法

BeMaster是一個操作，這個操作很簡單，就是提議自己成為Master，圖片裡面A節點希望自己成為Master。任何節點都可以發起這個操作嘗試將自己提升為Master，除了已經得知別人已被選為Master。當得知別人被選為Master後，必須等待timeout長度時間，才能發起BeMaster操作。而如果是獲知自己成為Master，那麼從BeMaster開始的timeout時間內可認為自己是Master，如圖示，T2-T3的時間窗內，視作Master的任期。

如何將上面所述的租約演算法與Paxos結合起來？

• BeMaster可以認為是一個Submit操作，其Value攜帶的就是自己的節點資訊。
• callback做兩件事情，第一：發現Value的節點非自己，則等待timeout時間再發起BeMaster。第二：發現Value的節點是自己，那麼將自己提升為Master，並在T(BeMaster) + timeout後過期。

演算法正確性如何保證？

• 一致性由Paxos保證，也就是隻要Value被Paxos選出來，那麼其包含的肯定是同一個節點資訊，不會出現選舉衝突。
• Master的單點性通過租約演算法保證。由於恆定T(BeMaster) < T(Know other as master)，那麼Master的過期時間肯定要比非Master節點認為Master過期的時間早，從而保證Master任期內，肯定不會出現其他節點嘗試來搶佔Master。

這裡給大家提一個問題，圖示裡面，為何Master任期的起始時間是從BeMaster算起，而不能是從BeMaster success算起？相信如果理解了Paxos演算法的讀者，應該可以很輕鬆回答這個問題。

一種答案：仔細看圖示裡面，nodeA發起了bemaster，但nodeC獲知提議成功的時間比nodeA還要早。這是paxos分散式演算法決定的，提議著未必能最早獲得結果。

Master續任

只需要在Master任期內成功成功完成一次BeMaster操作，即可延長Master任期，在正常情況下這樣不斷迭代下去，一般會使得Master非常的穩定。

上圖可以看到在多次的BeMaster選舉裡面，我們需要給每一個任期賦予一個version，這是為什麼？下面通過一個例子來解釋這個問題。

這個圖示情況是NodeA不斷的在續任，但NodeC可能與NodeA無法通訊或者其他原因，在獲知NodeA第二次續任成功後就再也收不到任何訊息了，於是當NodeC認為A的Master任期過期後，即可嘗試發起BeMaster操作。這就違背了演算法的保證了，出現了NodeA在任期內，但NodeC發起BeMaster操作的情況。

這裡問題的本質是，NodeC還未獲得最新的Master情況，所以發起了一次錯誤的BeMaster。version的加入是參考了樂觀鎖來解決這個問題。發起BeMaster的時候攜帶上一次的version，如果這個version已經不是最新，那麼這一次BeMaster自然會失效，從而解決問題。理解樂觀所的讀者應該可以很快腦補出version的作用，這裡就不詳細展開了。