Raft紙では、すべてのクライアントのやりとりがリーダーノードで起こると述べました。私が理解できないことは、リーダーが変わっていくことです。だから私のクラスタがロードバランサの後ろにあるとしましょう。リーダーが変更されたことをロードバランサに通知するにはどうすればよいですか？あるいは、私が正しいのであれば、ロードバランサがノード（フォロワまたはリーダー）のいずれかにクライアント要求を送ることができ、フォロワノードがリーダーに要求を送信するのは責任ですか？どのように実際にRaftアルゴリズムを使用するのですか
投票の終了後、リーダー（新旧）があります。リーダは、ネットワーク内のすべてのノードに定期的に（ネットワークのキープアライブ時間よりも短く、最大往復時間よりも長い）ハートビートを送信するように通知する必要があります。
ロードバランサは、ハートビートを取得するたびにリーダーを更新する必要があります。ロードバランサは、ラフトアルゴリズムに従って、すべてのクライアント要求がリーダーのみに直接送られ、他のノードは、データを送信することはできませんが、投票および追加コマンドに対する確認だけを送信するため、リーダーにのみデータを送信します。同じで、ここで本当に良いプレゼンテーションがあり
が本当にこれを行うことができる2つの方法があります。いずれかのロードバランサは、リーダーがどこにあるか理解する必要があるかが信者缶にプロキシ要求リーダー。
フォロワーを介してリーダーにクライアント要求をプロキシすることには何も問題はなく、実際には大きな利点があります。多くのRaft実装では、クライアントはフォロワから読み込み、シーケンシャルな一貫性を維持します。これは、ロードバランサがクライアントが最後に見たインデックスを追跡し、各要求でそれを送信して状態が戻ってこないことを確認した場合、任意のノードに要求を送信することで、安全に実行できます。私はここで完全なアルゴリズムを書くつもりはないが、これは相談すべきRaftの論文に記載されている。
ただし、このようにロードバランサを使用すると、場合によっては危険になることがあります。クライアントが複数の同時要求を送信することが許可されている場合、ロードバランサはこれらの要求を別々のノード経由でルーティングすることができ、リーダーに順不同で到着する可能性があります。これは、クライアント要求にシーケンス番号を付加し、リーダー上で要求を並べ替えることによって説明することができます。しかし、実装には、リーダーがクライアントごとの状態を追跡できるようにセッションを含める必要があります。
しかし、通常、Raftクライアントは特定のノードに接続し、可能な限り長く接続しておくことで、サーバーの切り替え時に一貫性を維持するオーバーヘッドを削減します。インプリメンテーションがフォロワーからの読み取りをサポートしている場合、サーバーは順次整合性を維持するために状態が追いつくのを待たなければならないため、サーバーを切り替えるにはコストがかかる可能性があります。
しかし、この文書では、クライアントはユーザーだけでなく、システム内のノードでもあると述べています。 –
@FaizHalde質問をさらに説明してください。ここでは、クラスタ内のデータをプッシュしたいエンティティとしてクライアントを参照しています。あなたの場合はロードバランサです –
ロードバランサの背後にある5つのノードのクラスタを考えてみましょう。すべてのクライアントのやり取りは、ロードバランサを通じて行われます。ロードバランサは、クラスタ内の任意のノード（フォロワーおよびリーダー）に要求を渡すことができます。しかし、フォロワーがリクエストを受け取った場合、それはすぐにリーダーに送信されます。 （なぜ私はこれを考えたのかというと、クライアントはクラスタ内のノードの1つになる可能性があるからです） –