Raft 集群成員變更、日志壓縮、客戶端交互

集群成員變更

在集群服務器發(fā)生變化時，不能一次性的把所有的服務器配置信息從老的替換為新的，因為，每臺服務器的替換進度是不一樣的，可能會導致出現(xiàn)雙主的情況，如下圖：

如上圖，Server 1和Server 2可能以 C_old 配置選出一個主，而Server 3，Server 4和Server 5可能以 Ｃ_new 選出另外一個主，導致出現(xiàn)雙主。

raft使用兩階段的過程來完成上述轉換：

• 第一階段，新老配置都存在，稱為joint consensus

• 第二階段，替換成新配置
  

  • 領導者首先創(chuàng)建Cold,new的log entry，然后提交（保證大多數(shù)的old和大多數(shù)的new都接收到該log entry）；

  • 領導者創(chuàng)建Cnew的log entry，然后提交，保證大多數(shù)的new都接收到了該log entry。

這個過程中，有幾個問題需要考慮。

• 新加入的server一開始沒有存儲任何的log entry，當它們加入到集群中，可能有很長一段時間在追加日志的過程中，導致配置變更的log entry一直無法提交

Raft為此新增了一個階段，此階段新的server不作為選舉的server，但是會從leader接受日志，當新加的server追上leader時，才開始做配置變更。

• 原來的主可能不在新的配置中

在這種場景下，原來的主在提交了Cnew log entry（計算日志副本個數(shù)時，不包含自己）后，會變成follower狀態(tài)。

• 移除的server可能會干擾新的集群

移除的server不會受到新的leader的心跳，從而導致它們election timeout，然后重新開始選舉，這會導致新的leader變成follower狀態(tài)。Raft的解決方案是，當一臺server接收到選舉RPC時，如果此次接收到的時間跟leader發(fā)的心跳的時間間隔不超過最小的electionTimeout，則會拒絕掉此次選舉。這個不會影響正常的選舉過程，因為，每個server會在最小electionTimeout后發(fā)起選舉，而可以避免老的server的干擾。

日志壓縮

Raft的日志會隨著處理客戶端請求數(shù)量的增多而不斷增大，在實際系統(tǒng)中，日志不可能會無限地增長，原因如下：

• 占用的存儲空間隨著日志增多而增加
• 日志越多，server當?shù)糁貑r需要回放的時間就越長

因此，需要定期地清理日志，Raft采用最簡單的快照方法。對系統(tǒng)當前做快照時，會把當前狀態(tài)持久化到存儲中，然后到快照點的日志項都可以被刪除。

Raft算法中每個服務器單獨地做快照，即把當前狀態(tài)機的狀態(tài)寫入到存儲中（狀態(tài)機中的狀態(tài)都是已提交的log entry回放出來的）。除了狀態(tài)機的狀態(tài)外，Raft快照中還需要一些元數(shù)據(jù)信息，包括如下：

• 快照中包含的最后一個日志條目的索引值和任期號，記錄這些信息的目的是為了使得AppendEntriesRPC的一致性檢查能通過，因為，在復制緊跟著快照后的日志條目時，AppendEntries RPC帶上需要復制的日志條目前一個日志條目的(索引值，任期號)，即快照的最后一個日志條目的(索引值，任期號)，因此，快照中需要記錄最后一個日志條目的(索引值，任期號)

• 為了支持集群成員變更，快照中保存的元數(shù)據(jù)還會存儲集群最新的配置信息。

當服務器完成快照后，可以刪除快照最后一個日志條目及其之前所有的日志條目，以及之前的快照。

雖然每個服務器是獨立地做快照的，但是也有可能存在需要領導者向跟隨者發(fā)送整個快照的情況，例如，一個跟隨者的日志處于領導者的最近一次快照之前，恰好領導者做完快照之后把其快照中的日志條目都刪除了，這時，領導者就無法通過發(fā)送日志條目來同步了，只能通過發(fā)送完整快照。

領導者通過 InstallSnapshot RPC來完成發(fā)送快照的功能，跟隨者收到此RPC后，根據(jù)不同情況會有不同的處理：

當follower中缺失快照中的日志時

• follower會刪除掉其上所有日志，并清空狀態(tài)機

當follower中擁有快照中所有的日志時

• follower會刪掉快照所覆蓋的log entry，但快照后所有日志都保留。備注：這里論文中沒有提是否還是從leader接受快照，個人覺得follower可以自己做快照，并拒絕掉leader發(fā)快照的RPC請求

對于Raft快照，關于性能需要考慮的點有：

• server何時做快照，太頻繁地做快照會浪費磁盤I/O；太不頻繁會導致server當?shù)艉蠡胤艜r間增加，可能的方案為當日志大小到一定空間時，開始快照。備注：如果所有server做快照的閾值空間都是一樣的，那么快照點也不一定相同，因為，當server檢測到日志超過大小，到其真正開始做快照中間還存在時間間隔，每個server的間隔可能不一樣

• 寫快照花費的時間很長，不能讓其影響正常的操作。可以采用copy-on-write操作，例如linux的fork

客戶端交互

Raft 中的客戶端發(fā)送所有請求給領導人。當客戶端啟動的時候，他會隨機挑選一個服務器進行通信。

• 如果選擇的服務器是領導者，那么客戶端會把請求發(fā)到該服務器上

• 如果選擇的服務器不是領導者，該服務器會把領導者的地址告訴給客戶端，后續(xù)客戶端會把請求發(fā)給該領導者

• 如果此時沒有領導者，那么客戶端會timeout，客戶端會重試其他服務器，直到找到領導者

Raft 的目標是要實現(xiàn)線性化語義（每一次操作立即執(zhí)行，只執(zhí)行一次，在他調用和收到回復之間）。但是，如上述，Raft 是可以執(zhí)行同一條命令多次的：例如，如果領導人在提交了這條日志之后，但是在響應客戶端之前崩潰了，那么客戶端會和新的領導人重試這條指令，導致這條命令就被再次執(zhí)行了。解決方案就是客戶端對于每一條指令都賦予一個唯一的序列號。然后，狀態(tài)機跟蹤每條指令最新的序列號和相應的響應。如果接收到一條指令，它的序列號已經被執(zhí)行了，那么就立即返回結果，而不重新執(zhí)行指令。

只讀的請求可以不寫log就能執(zhí)行，但是它有可能返回過期的數(shù)據(jù)，有如下場景：

領導人響應客戶端請求時可能已經被新的領導人作廢了，但是他還不知道

Raft 需要使用兩個額外的措施在不使用日志的情況下保證這一點。

• 首先，領導人必須有關于被提交日志的最新信息。領導人完全特性保證了領導人一定擁有所有已經被提交的日志條目，但是在他任期開始的時候，他可能不知道那些是已經被提交的。為了知道這些信息，他需要在他的任期里提交一條日志條目。Raft 中通過領導人在任期開始的時候提交一個空白的沒有任何操作的日志條目到日志中去來實現(xiàn)。

• 第二，領導人在處理只讀的請求之前必須檢查自己是否已經被廢黜了（他自己的信息已經變臟了如果一個更新的領導人被選舉出來）。Raft 中通過讓領導人在響應只讀請求之前，先和集群中的大多數(shù)節(jié)點交換一次心跳信息來處理這個問題。可選的，領導人可以依賴心跳機制來實現(xiàn)一種租約的機制，但是這種方法依賴時間來保證安全性（假設時間誤差是有界的）。

總結

以上是生活随笔為你收集整理的Raft 集群成员变更、日志压缩、客户端交互的全部內容，希望文章能夠幫你解決所遇到的問題。

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