分散システムの学習の一環として、チャットアプリケーションを構築しています。現在、私の設計は、各サーバーに、接続されているクライアント（コンセンサスアルゴリズムを使用してレプリケートされる状態）を知ることです。ロードバランサを介してバックエンドサーバのip：portをクライアントに返すことをお勧めします。
クライアントが最初に接続するロードバランサがあり、ロードバランサはクライアントが次に話すべきサーバーで応答します。クライアントからの後続のコマンドは、それが割り当てられたインスタンスに直接移動します。状態を管理するために、Raft algorithmをコンセンサスに使用することを考えています。
ここでRaftのようなコンセンサスアルゴリズムを実装する理由がわかりません。 RAFTは伝統的にリーダーを選ぶために使われます。あなたがこれを必要とするようには聞こえません。ような何か：
クライアント>ロードバランサ（haproxy）チャットサーバの>プール
Haproxy（ロードバランサ）は、サーバー・プールに対してヘルスチェックを実行することができます。サーバーが死んだ場合、サーバーはプールから削除されます。サーバーがホット/ストレス状態になると、ヘルスチェックがプールから削除されます（バックエンドサーバーはヘルスチェックによって503 httpステータスをスローする必要があります）。トラフィックがダウンすると、サーバーはプールに再追加されます。健全なチャットサーバーのプールメンバーの数を警告/監視できます。
クライアント側のエラーを処理します。エラーが検出された場合は、ロードバランサに再接続し、新しいサーバーを取得します。すべてのチャット状態は、一時的なチャットサーバーのインスタンスではなく、Redisのような何らかの種類のグローバルデータストアに保持されるべきです。
これによりスケーラビリティが向上します。極端な規模では、Redisのデータストアに問題があるかもしれませんが、Redis Clusterやチャットをシャドーすることで軽減できます。