筏算法正常操作

Question

我已經閱讀了Raft算法的論文，並得到了一個與Raft在收到客戶請求后執行的操作順序有關的問題：

為了克服單點故障情況，Raft依賴於在其他計算機上維護復制的日志，該算法還咨詢了共識模塊以進行完整的日志記錄管理。 操作順序如下：

1. 領導者的狀態機接收到客戶端請求，領導者將命令附加到其日志中。
2. 領導者將AppendEntries RPC發送給他的關注者，以將命令克隆到他們的本地日志中，並等待大多數關注者的確認該條目已成功添加到其本地日志文件中。
3. 一旦收到確認，請求已成功記錄在大多數追隨者日志中，則該請求將提交到領導者的狀態機，導致發生轉換，並將該轉換的輸出返回給客戶端。
4. 最終，領導者在后續的AppendEntries RPC 中將已提交條目通知給跟隨者。

如果上面的理解是正確的，那么我可以聲稱客戶端請求被保留了一段時間以完成復制過程，也可以聲明客戶端請求的成功在很大程度上取決於復制的成功進程（因為在接收到多數確認之前，領導者的機器上不執行客戶端命令/請求）。 問題是，復制過程完成后，客戶端請求平均需要多長時間才能收到響應，這對於實時系統是否有效？

Answer 1

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed建議諸如Raft之類的系統要求CAP定理三位一體的一致性和可用性部分受到性能限制。 您可能也對https://pdfs.semanticscholar.org/7c45/54d064128043897ea2226021f6fda4c64251.pdf（Birman的可靠組播經驗的回顧）感興趣，該文獻描述了在高保證系統（例如空中交通管制）中可靠組播組的經驗。

我從中得出的結論是，一個實際的系統可能需要非常小心，以保護與Raft，Paxos和朋友之間的信息，以及它對信息的保護程度較差。 另一種觀點是采用Paxos的非常復雜的實現，例如Google Spanner，以便程序員不必擔心非ACID系統的問題。

Answer 2

如果上面的理解是正確的，那么我可以聲稱客戶端請求被保留了一段時間，以便復制過程完成

正確，當前術語的領導者只有將命令復制到集群中的大多數節點后，才會確認客戶端請求。

我還可以聲稱，客戶端請求的成功在很大程度上取決於復制過程的成功

沒錯 集群中至少大多數節點（包括領導者）都需要可用並具有響應能力，以便成功復制命令並使領導者確認請求。

復制過程完成后，客戶端請求平均需要多長時間才能收到響應

這取決於您的網絡拓撲。 對客戶端請求的響應延遲將由以下部分組成（假設沒有領導者崩潰）：*在客戶端和領導者之間傳輸客戶端請求所需的等待時間。 *領導者對跟隨者復制條目的AppendEntries請求的延遲（與所有跟隨者並行發送。*跟隨者對領導者的AppendEntries響應的延遲。*領導者應用命令所需的時間到其狀態機（即最佳情況下的磁盤寫入）*客戶端響應從領導者傳輸到客戶端的延遲

各種消息的等待時間取決於節點之間的距離，但可能在十分之幾到幾百毫秒之間。

對實時系統也有效嗎？

這取決於您對特定案例的要求。 但是總的來說，實時系統要求的延遲在幾毫秒以下，因此答案很可能不是。 另外，請記住，在發生新領導人選舉的崩潰和不穩定時期，延遲可能會大大增加。