6.1 腦裂 (split brain)

• 容錯系統，存在多個副本，但是需要單個節點來決定在多個副本中，誰是主(Primary)
• 這種情況下會產生腦裂
• 腦裂的解決方式:
  • 構建不可能出現故障的網路。比如連線了CPU和記憶體的線路就是不可能出現故障的網路，要花很多錢
  • 人工解決。在客戶端需要等待兩個伺服器響應的情況下，如果只有一個伺服器響應，那麼不要執行操作，要運維去修復。

6.2 過半票決 (Majority Vote)

• 網路分割槽是指，網路出現故障，將網路分割為兩半，網路兩邊獨立執行，不能夠訪問對方，那麼形成了兩個網路分割槽
• 過半票決，是raft論文的基本概念，以及實現自動恢復，同時避免腦裂的多副本系統。，一般適合於伺服器數量是奇數
  的網路，要點在於在任何時候為了完成任何操作，你必須湊夠過半的伺服器來批准相應的操作，邏輯是
• 通用的方程是如果系統有2 * F + 1個伺服器，那麼系統可以最多接收F個伺服器，仍然可以正常工作
• 由於每次操作需要過半的伺服器來批准，那麼每一個操作對應的過半伺服器，必然至少包含一個伺服器存在於上一個操作的過半伺服器中

6.3 Raft初探

• Raft會以庫的形式呈現在服務中。如果你有一個基於Raft的多副本服務，那麼每個副本將會由兩部分組成：應用程式和Raft庫。應用程式負責接收RPC或者其他客戶端請求，不同節點的Raft庫之間相互合作，來維護多副本之間的操作同步。
• Raft在應用程式底層，提供容錯。Raft本身會保持狀態，也就是會記錄狀態日誌
• 對於一個三個節點的raft kv伺服器叢集而言，一個請求給伺服器叢集，
  • Leader節點的應用程式會將來自客戶端的請求向下送給Raft層，
  • 並且將這個操作提交到多副本的Raft日誌
  • 當Leader的節點直到過半的節點有這個操作的拷貝之後，那麼Leader的Raft層會通知應用程式，也就是Key-Value資料庫，來說明：剛剛你提交給我的操作，已經提交給過半副本了，現在可以真正執行這個使用者請求了
  • 在Leader節點被提交後，每個副本節點的Raft層都會將相同的操作提交到本地應用程式層

6.4 Log同步時序

• 從時序的角度看Raft Log同步，
  • Leader的Raft層會發送一個新增日誌(AppendEntires)的RPC到其他兩個副本,
  • 之後Leader會等到其他副本響應，直到過半(包括Leader節點自己)的節點響應返回
  • Leader在收到過半伺服器的正確響應之後，Leader會執行客戶端請求，並將結果返回給客戶端伺服器3也會將響應返回給Leader，這個響應有用但不需要等待
  • 對於Leader之外的伺服器，在Leader提交之後，那麼Leader會去將這個訊息通知給其他副本，這個committed訊息會被夾帶在下一個AppendEntries中
  • Leader需要給副本傳送心跳？對於客戶端的請求稀疏的情況需要Leader傳送心跳包，心跳包用來告訴follower當前Leader還活著,當follower的定時器過了一段時間沒有收到Leader的心跳包，那麼之後就會發送新Leader的選舉

6.5 日誌

• Log的作用：
  • Log是Leader來對操作排序的一種手段。即如果有是個客戶端同時向Leader發出請求，那麼Leader必須確認一個順序，其他副本都會遵從同樣的順序，Log是一些按照數字編號的槽位(類似陣列)
  • Log對於非Leader的副本而言，一些還未執行的操作，會放在其中，直到Leader傳送了新的commit號，這些操作可能會被丟棄
  • 對於傳送給副本的操作，可能需要重新傳送，那麼Log中記錄了可能需要重傳的操作
  • Log對於故障節點的恢復，一個Raft節點故障重啟之後，Log保留在磁碟中，那麼Log會被Raft節點用來從頭執行其中的操作進而重建故障前的狀態，實現持久化
• 確認操作？確認是指Leader發來的committed訊息，那麼確認與累計可以很快必要時，需要follower去傳送訊息給Leader進行流量控制