Raft アルゴリズムの論文を読み、Raft がクライアント リクエストを受け取ったときに実行する操作のシーケンスに関連する質問を受けました。
単一障害点のシナリオを克服するために、Raft は他のマシンで複製されたログを維持することに依存しています。アルゴリズムは、完全なログ管理のためにコンセンサス モジュールも参照します。一連の操作は次のように機能します。
- クライアント要求はリーダーのステート マシンで受信され、リーダーはそのログにコマンドを追加します。
- リーダーはAppendEntries RPC をフォロワーに送信してローカル ログにコマンドを複製し、フォロワーの大多数から、エントリがローカル ログ ファイルに正常に追加されたことを確認するのを待ちます。
- リクエストがフォロワーログの大部分に正常に記録されたという確認が受信されると、リクエストはリーダーのステートマシンにコミットされ、遷移が発生し、その遷移の出力がクライアントに返されます。
- 最終的に、リーダーは後続のAppendEntries RPC でコミットされたエントリをフォロワーに通知します。
上記の理解が正しければ、レプリケーション プロセスが完了するまでクライアント リクエストがしばらく保留されていると主張できます。また、クライアント リクエストの成功はレプリケーションの成功に大きく依存していると主張することもできます。プロセス (クライアントのコマンド/リクエストは、過半数の承認が受信されるまでリーダーのマシンで実行されないため)。問題は、レプリケーション手順が完了した後、クライアント リクエストが応答を受信するまでに平均でどれくらいの時間がかかると予想されるかということです。これは、リアルタイム システムでも効率的に機能しますか?