問題タブ [consensus]

Raft アルゴリズムの論文を読み、Raft がクライアント リクエストを受け取ったときに実行する操作のシーケンスに関連する質問を受けました。

単一障害点のシナリオを克服するために、Raft は他のマシンで複製されたログを維持することに依存しています。アルゴリズムは、完全なログ管理のためにコンセンサス モジュールも参照します。一連の操作は次のように機能します。

1. クライアント要求はリーダーのステート マシンで受信され、リーダーはそのログにコマンドを追加します。
2. リーダーはAppendEntries RPC をフォロワーに送信してローカル ログにコマンドを複製し、フォロワーの大多数から、エントリがローカル ログ ファイルに正常に追加されたことを確認するのを待ちます。
3. リクエストがフォロワーログの大部分に正常に記録されたという確認が受信されると、リクエストはリーダーのステートマシンにコミットされ、遷移が発生し、その遷移の出力がクライアントに返されます。
4. 最終的に、リーダーは後続のAppendEntries RPC でコミットされたエントリをフォロワーに通知します。

上記の理解が正しければ、レプリケーション プロセスが完了するまでクライアント リクエストがしばらく保留されていると主張できます。また、クライアント リクエストの成功はレプリケーションの成功に大きく依存していると主張することもできます。プロセス (クライアントのコマンド/リクエストは、過半数の承認が受信されるまでリーダーのマシンで実行されないため)。問題は、レプリケーション手順が完了した後、クライアント リクエストが応答を受信するまでに平均でどれくらいの時間がかかると予想されるかということです。これは、リアルタイム システムでも効率的に機能しますか?

スタンフォードの Raft に関するスライド ( https://ramcloud.stanford.edu/~ongaro/userstudy/raft.pdf ) は、Raft が次の障害モデルを処理することを示しています:フェイルストップ(ビザンチンではない)、遅延/失われたメッセージ。フェイル リカバリのケースによっては、一貫性が失われる可能性がある、またはフェイル リカバリの障害に対して回復力があるということですか?

Raft に関するいくつかのドキュメントを読んでいますが、コミットに関する矛盾した情報を入手しています。大多数のサーバーに保存されていることがわかっている場合にのみエントリをコミットできると思いますが、他に条件はありますか? 現在の用語のエントリをすべてのサーバーに保存することも義務付けられていることを読みましたが、他のドキュメントではそれについて何も述べていません。何か助けはありますか？