1. 首頁 > 生活百科 > >

【翻譯】Raft 共識算法：集群成員變更

生活百科

轉載請注明出處：https://www.cnblogs.com/morningli/p/16770129.html
【【翻譯】Raft 共識算法：集群成員變更】之前都在集群配置是固定的（參與共識算法的server集合）假設下討論raft 。在實踐中，偶爾有需要改變配置，比如說當server故障時替換server，或者改變復制級別 。雖然可以通過下線整個集群，更新配置文件，重啟集群來實現 ， 但是這樣會導致集群在改變的過程中一直不可用 。另外，人工操作存在操作錯誤的風險 。為了避免這樣的問題，raft通過自動化配置變更并將它包含到raft共識算法中 。

【翻譯】Raft 共識算法：集群成員變更

文章插圖
為了保證配置變更機制是安全的，必須保證不存在轉換過程中有兩個leader在同一個term內被選舉出來 。不幸的是 ， server直接從老配置轉換到新配置的任何方法都是不安全的 。不可能自動一下子自動切換所有的server，所以集群在轉換期間存在分裂成兩個獨立的大多數的可能性（見 Figure 10） 。
為了保證安全性，配置變更必須使用兩階段方法 。有不同的方式來實現兩階段 。舉個例子，一些系統使用第一階段禁用老的配置，這樣系統無法處理客戶端請求；然后第二階段啟用新的配置 。在raft集群首先切換到一個過度的配置，稱為joint consensus；一旦joint consensus被提交，系統切換到新的配置 。joint consensus結合了新老配置：
  • 日志記錄復制到新老配置的所有server
  • 兩個配置中任何一個server都可以作為leader
  • 達成一致（針對選舉和提交）需要分別在兩種配置上獲得大多數的支持 。
joint consensus允許各個服務器在不同時間在配置之間進行轉換，而不會影響安全性 。此外 ， joint consensus允許集群在整個配置更改期間繼續為客戶端請求提供服務 。
【翻譯】Raft 共識算法：集群成員變更

文章插圖
集群配置通過復制的日志中的特殊記錄來存儲和交流；Figure 11介紹了配置變更過程 。當leader接收到一個將配置從Cold修改為Cnew的請求時 ， 它會為joint consensus （圖中的Cold,new）將這個配置存儲成一個日志記錄并復制這個記錄 。一旦一個server將這個新的配置記錄添加到它的日志里，它以后的決定都會使用這個配置（server總會使用日志中最新的配置，無論這個配置是否提交） 。這意味著leader將會使用Cold,new的規則來決定Cold,new這個記錄什么時候是committed的 。如果leader崩潰了，一個新的leader有可能包含配置Cold或者Cold,new，取決于取勝的candidate有沒有收到Cold,new 。在這個期間，任何情況Cnew不能單方面做決定 。
一旦Cold,new已經被提交，Cold或者Cnew都不能在沒有得到對方同意的情況下做決定的，Leader Completeness Property保證了只有包含Cold,new的記錄的server會被選為leader 。leader這是創建一個Cnew的日志并復制到集群中是安全的 。這個配置會在server接收到后立馬生效 。當新的配置在Cnew的規則下被提交時，老的配置已經不重要了，不在新配置中的server可以被關停 。如Figure 11所示 ， 不存在Cold和Cnew單方面做決定的時候 。這保證了安全性 。
配置變更還有三個問題需要解決 。第一個問題是新的server剛開始不會存儲任何日志 。如果新server被添加到集群，它們跟上日志需要一些時間，這段時間內不能提交新的日志記錄 。為了避免這種可用性的間隔時間，raft在更新配置之前引入了額外的步驟，新加入集群的server作為一個 non-voting 成員（leader復制記錄給它們，但是在大多數投票時不會將它考慮進來） 。一旦這個新server追上集群中其他server的進度，配置更新像上面描述的過程一樣 。
第二個問題是集群leader可能不屬于新配置中的成員 。這種情況，leader提交了Cnew后立馬下臺（變回follower狀態） 。這表示會有一段時間（正在提交Cnew）leader會管理一個不包含自己的集群；它復制日志記錄但是在計算大多數時不會把自己考慮進去 。在Cnew被提交的時候變更leader是因為這是新配置可以獨立運行的最早的時間點（新的leader肯定會包含Cnew） 。在這個點之前，有可能選出一個包含Cold配置的leader 。
第三個問題是移除server（不在Cnew）會擾亂集群 。這些server不會受到心跳，所以它們會超時并開始新的投票 。它們會使用新的term發送RequestVote RPCs，這會導致當前的leader轉換到follower狀態 。最終會選出一個新的leader ， 但是已經移除的server會再次超時，上面的過程會重復發送，影響了可用性 。

推薦閱讀