私は、各チャットルームの大規模なグループ（> 50ユーザー）を特に対象としたリアルタイムのグループチャットアプリケーションを設計しようとしています。すべてのユーザーが一度にアクティブにチャットするわけではありませんが、チャットルームにチャットが入ると、多くのユーザーが単にアイドル状態/リッスンして更新を受信することが期待できます。
私はクラウド指向ではないプロトタイプを作成し、クラウドベースのシステム用に再設計中です。
一連のバックエンドの「チャット」サーバー（CServer）にリダイレクトする「リダイレクト/負荷分散」サーバー（LBServer）が1つあると思います。ユーザーがクライアントから特定のチャットルームへの参加を要求すると、クライアントはLBServerに接続し、LBServerはチャットルームのインスタンスをメモリに保持している特定のCServerの接続情報で応答します。次に、クライアントはLBServerから切断し、CServerに接続します。CServerへのこの接続は、ユーザーがチャットルームにいる限り維持されます。CServerは、チャットルームの状態をログに記録するバックエンドデータベースを更新するだけでなく、CServerに接続している他のクライアントにチャットルームの更新を通知する役割を果たします。
1つのチャットルームに存在するユーザーが多すぎる場合（したがって、1つのCServerがこれらすべてのユーザーへの永続的な接続を維持する必要がある）、部屋のアクティビティがCServerの処理速度のしきい値を超えて増加すると、「ホットスポット」シナリオが展開されることをすでに想像できます。すべての更新に対応します。
この時点で、システムをスケーラブルにするための1つの単純なソリューションを考え出しました。より大きなCServerインスタンスをロードし、チャットルームの状態をコピーして、「ホット」CServerのすべてのユーザーに新しいより大きなインスタンスに再接続するように要求できます。これがそのようなシステムのスケーラビリティを処理する正しい方法であるとは思いません。
少し質問があります：
チャットのリアルタイム性を望んでいることを考えると、1つのサーバーインスタンスへの接続を維持する必要がないようにバックエンドシステムを設計するためのより適切な方法はありますか？
すでにデータベイの状態を追跡しているときに、各チャットルームの処理をすべて1つのCServerで実行するように分離する必要がありますか？ユーザーが複数のチャットルームに同時に参加できるように、部屋を空けておきたいです。現在のモデルを使用する場合、クライアントはクラウドへの複数の接続を維持する必要があります（ユーザーがいるチャットルームごとに1つ）。これはクライアント側にとっては最悪です。改訂版として、ユーザーが現在使用しているチャットルームの変更をリッスンし、それに応じて更新する「ユニバーサル」CServerへの接続を維持するクライアントを想定しています。
すべてのフィードバックと入力をいただければ幸いです。不明な点について詳しく説明させていただきます。ありがとう。