チャット アプリケーションの私の主な使用例は、通常、1 人のエージェントが 1 人のゲストと話すことです。せいぜい一桁台前半の数のゲストとエージェントをサポートすることを計画していますが、そのような機能の使用は非常に少ないでしょう. ただし、さらに重要なことは、HTTP ステータスによってメッセージの受信が確認されるため、送信者が独自のメッセージを受信する必要がないことです。
「プッシュ専用」にPubNubの利用を検討しています。したがって、各クライアントは HTTP (PUT/POST) 経由でアプリケーション Web サーバーにメッセージを送信し、独自の PubNub サブスクリプション チャネル経由でのみメッセージを受信します。
Web サーバー アプリケーションは、HTTP チャット メッセージを受信すると、メッセージが送信されるクライアントをマッピングし、それらの特定のクライアントのチャネルにメッセージを発行します。への呼び出しを伴うループPubNub.publish(client_channel_id, the_message)。
このように、各クライアントは複数のチャネルではなく 1 つのチャネルのみをサブスクライブする必要があり、すべてのクライアントはそのクライアント向けのメッセージのみを受信します (つまり、グローバル チャネルやクライアントでのフィルタリングはありません)。
(Redis を使用して、どのクライアントがどの部屋でチャットしているかのマップを保持することも検討しています。そのため、Web アプリがチャット メッセージを受信するたびに、(ローカル キャッシュを使用して) 最初に Redis にチェックインして、メッセージの宛先をマッピングする必要がある場合があります)。チャネル...）
潜在的な問題
- サーバー全体で単一の PubNub 接続を使用すると、おそらく十分に拡張できません。接続のプールは、おそらくより適切に機能します。これらの接続をブロードキャストするだけで、サブスクライブしていないので、単純なはずですよね?
この設計で他に潜在的な問題はありますか? 他のコメント？