我如何實際使用Raft算法

Question

在Raft論文中，他們提到所有客戶端交互發生在領導者節點上。我不明白的是領導者不斷變化。假設我的集羣位於負載平衡器後面。如何通知負載均衡器領導者已更改？或者如果我是正確的，負載均衡器是否可以向任何節點（追隨者或領導者）發送客戶端請求，並且追隨者節點有責任將請求發送給領導者？

Answer 1

投票結束後，您將有一位領導（新的或舊的）。領導者有責任通知網絡中的所有節點定期向所有節點發送心跳（小於網絡的保持活動時間，但大於最大往返時間）。

您的負載均衡器應該在每次獲取心跳時更新領導者。負載均衡器只會將數據發送給領導者，因爲根據raft算法，所有客戶端請求只能直接發給領導者，其他節點不能發送數據，只能確認投票和追加命令。

這裏有一個很好的演示上是相同的： - Raft: Log-Replication

Answer 2

實際上有兩種方法可以做到這一點：無論是負載均衡需要了解其中的佼佼者是或追隨者可以代理請求到領導。

通過跟隨者代理客戶端向領導者發送請求沒有任何問題，事實上它可能會帶來很多好處。許多Raft實現允許客戶從追隨者讀取，同時保持順序一致性。如果客戶端跟蹤它所看到的最後一個索引，並且每次發送請求以確保它不能及時看到狀態，這仍然可以安全地通過負載均衡器向任意節點發送請求來完成。我不會在這裏寫出完整的算法，但是您應該參閱的Raft論文對此進行了描述。

但以這種方式使用負載均衡器在某些情況下可能會變得不安全。如果客戶端被允許發送多個併發請求，負載均衡器可以通過不同的節點路由這些請求，並且他們可能不按順序到達該領導者。這可以通過將序列號附加到客戶端請求並對領導者重新排序請求來解釋。但要這樣做，實施必須包括會話以允許領導者跟蹤每個客戶端的狀態。

雖然Raft客戶端連接到特定節點並保持連接狀態的時間儘可能長，以減少切換服務器時保持一致性的開銷。如果一個實現支持從關注者的閱讀，那麼切換服務器的成本仍然很高，因爲服務器必須等待狀態趕上以保持順序一致性。