Raft算法之成員關係變化

上一篇文章:Raft算法之日誌複製

Raft算法之成員關係變化

  有時候可能會遇到須要對集羣中的成員數量進行更新的操做，比較簡單的作法將更新操做分爲兩個階段進行，在第一個階段將所有的使用舊的配置文件的集羣C_old成員所有關閉，因此將不能對客戶端的請求進行處理。而後在第二個階段使用新的配置文件啓動集羣成員。一個很明顯的劣勢在於更新成員數量的時候有一段時間是沒法對客戶端請求進行處理的。
  Raft使用了一種新的方案對成員進行更新。在兩階段更新之間加入了一個配置轉換階段，稱爲聯合共識。引入聯合共識階段，集羣在進行成員關係變化的同時，不須要關閉集羣成員，從而能夠在更新成員數量的過程當中也能夠對客戶端的請求進行處理。
  在聯合共識階段具備如下幾點屬性:

• 日誌條目均複製到使用兩種配置的全部服務器。
• 來自任一配置的任何服務器均可以充當領導者.
• 選舉和日誌的提交須要分別來自新舊配置的大多數人接受。

  聯合共識容許集羣中的單個服務器在不一樣的時間從舊的配置轉換爲新的配置，從而不會影響安全性。而且在整個配置更新期間能夠繼續爲客戶端提供服務。

1 配置更新過程

1.1 理想狀況

  以向集羣中添加新的成員爲例，正常狀況下假設該過程不涉及客戶端發送的其餘的新的請求:
  假設舊的配置文件稱爲C_o,新的配置文件稱爲C_n,舊的集羣稱爲C_old,新添加的成員稱爲C_new.

• 當集羣C_old在正常運行過程當中(當前使用舊的配置文件C_o)，接收到來自客戶端關於添加新成員的請求。
  • Leader接收到則直接處理，Follower接收到則會重定向到Leader.
• Leader建立一個用於更新配置的新的日誌文件C_o_n(該日誌配置文件表示C_old與C_new成員共存)，該配置文件按照正常流程複製到集羣中大多數服務器(包括C_old,C_new)
  • 包括新成員C_new，服務器始終使用其日誌中的最新配置，而無論該條目是否被提交，Leader將使用C_o_n規則來肯定什麼時候提交C_o_n的日誌條目。
  • 也就是說本地只持有C_o配置日誌文件的成員仍然使用舊的配置文件。當接收到C_o_n配置文件以後不管是否已經應用到複製狀態機，都會使用C_o_n配置文件做爲服務器的配置文件。
• 當新的日誌文件C_o_n成功在集羣中提交以後，進入了聯合共識階段。
• 進入聯合共識階段以後，Leader建立一個新的用於配置更新的新的配置文件C_n,並將該日誌發送到大部分C_new服務器(文獻中是這麼說的，至此還沒搞明白爲何不是全部的服務器)。

• 當配置日誌文件C_n成功提交以後，則代表成員更新過程結束，集羣使用新的配置文件C_n按照正常的流程繼續運行。

  若是不考慮客戶端發送的新的請求以及服務器崩潰的狀況下，能夠把配置更新看作一個普通的日誌文件，按照正常流程發送，提交，應用後便成功完成配置的更新。惟一不一樣的是普通的日誌文件須要提交事後纔會應用到複製狀態機，而配置文件日誌則是當服務器接收到以後，不管是否已經提交，接收到的配置信息都會生效。

1.2 聯合共識階段

  聯合共識階段:指的是C_o_n配置日誌文件成功提交到集羣中的大多數服務器，且C_n配置日誌文件尚未提交到集羣中的大多數服務器之間的時間段。
  在該階段，任何操做(選舉或者是其餘的日誌請求)對於C_old和C_new的成員來講都不能單獨作出決策。即須要C_old與C_new中的大部分服務器同時作出決策。(由於日誌的提交條件是成功複製到大多數的服務器，因此當C_o_n日誌文件被提交以後，有可能還存在部分的服務器沒有接收到C_o_n日誌文件,仍然處於C_old階段,C_new的成員也是如此)

2 Leader崩潰狀況

  分別從如下幾個時間點說一下Leader在各個階段發生崩潰的措施:

1. C_o_n配置日誌文件未提交以前.
2. C_o_n配置日誌文件提交以後，且C_n配置日誌文件未提交前之間(聯合共識階段)的時間段
3. C_n配置日誌文件提交以後.

2.1 C_o_n配置日誌文件未提交以前

  從集羣初始正常運行狀態一直到C_o_n配置日誌文件被提交這段時間，若是Leader奔潰，那麼當選Leader的成員多是使用C_o的成員，也多是接收到C_o_n配置日誌文件的成員。由於C_o_n配置日誌文件還未被提交，因此C_old的成員能夠單獨作出決策。而C_new的成員還不能單獨作出決策。

2.2 聯合共識階段

   C_o_n配置日誌文件提交以後，且C_n配置日誌文件未提交前之間的時間段，因爲C_o_n配置日誌文件只有當複製到C_old和C_new二者中大多數成員以後才被提交，因此當提交C_o_n配置日誌文件以後，使用C_o_n配置日誌文件的成員佔所有服務器成員的大多數，所以，若是Leader崩潰，那麼只能從使用C_o_n配置日誌文件的成員中選取Leader。此時對於C_old和C_new的成員來講都不能單獨作出決策，所以也不能在使用C_o以及C_n的成員中選取Leader.

2.3 C_n配置日誌文件提交以後

  當該日誌提交以後，實際上已經完成了網絡中成員關係的更新。因此Leader的選舉便可和正常運行階段相同。

3 存在的問題

  在成員關係更新階段，主要存在三個問題:

1. 新添加的成員可能不會存儲任何以前的日誌條目，若是將它們加入集羣，在日誌條目與Leader完成同步以前，是沒法提交新的日誌條目的。
2. Leader可能不屬於新配置集羣中的一部分。
3. 假設更新成員關係是對集羣中的成員進行刪除，那麼被刪除的節點可能會擾亂集羣。

3.1 問題一

  針對該問題，Raft的作法是引入一個新的狀態，即容許新的成員以一種不具有決策權(選舉和參與日誌提交)的身份加入集羣，所以在選舉Leader或者是統計日誌是否已經分發到大部分紅員時，將不會考慮該成員。一直到該成員的日誌存儲狀態追遇上集羣中的其餘成員，再賦予該成員決策權。

3.2 問題二

緣由：  該問題產生的緣由是可能新添加到集羣中的新成員的數量要遠遠多於舊集羣的數量(我的理解，若是有錯誤歡迎指出)。因爲以前說到的C_n配置日誌文件須要發送到C_new中的大多數成員，而Leader並不屬於C_new中的一員。因此在發送C_n配置日誌文件的時段，Leader將會對C_new的成員進行管理。
解決方案:  當C_n日誌成功完成提交時，該Leader自動轉換身份爲Follower，而後從C_new的成員中選舉出一個新的Leader.

3.3 問題三

緣由:  被刪除的服務器若是沒有關閉，那麼他們將不會接收到心跳信息和日誌信息，從而不斷髮生超時，最後致使任期不斷增長(高於集羣中全部成員的任期)，而後不斷向集羣中發送請求投票消息。集羣中的Leader將變爲Follower，集羣中將不斷開始新的選舉。從而擾亂集羣的正常運行。
解決方案:   Raft引入了一個最小選舉超時時間，意思是若是集羣中存在Leader時，而且接收到心跳信息以後在最小選舉超時時間內接受到請求投票消息，那麼將會忽略掉該投票消息。

下一篇文章:Raft算法之日誌壓縮