この質問の断片を見てきましたが、直接答えるものはありません。
以下は仮想環境です。
- HTTP 経由でクライアントと通信する 20 の Java セントリック サーバー (つまり、Tomcat / Glassfish / Jboss など)
- サーバーの前にある HTTP ロード バランサーは、各クライアント接続で同じサーバーに戻ることが保証されていません。
- それ以外は技術的に利用可能です。(JMS / Camel / Memcached / Hazelcast / 何でも)
Joe と彼のブラウザ (おそらく Flash や HTML5 などのクライアント テクノロジを使用) が、20 のサーバーすべてで利用可能な JMS トピックにパブリッシュされたすべてのメッセージを受信できるようにします。
例を次に示します。
- Joe の最初の HTTP 接続がサーバー A に到達する
- サーバー A には、Joe 用の HTTP セッションがあります (Cookie などを介して)
- サーバーAは彼をトピックにサブスクライブします（セッションIDなどに基づいて）
- Joe の HTTP 接続が終了します。
- トピックにメッセージが投稿されます。
- Joe は別の接続を作成しますが、今回はサーバー F によって処理されます。
これは、私にとって物事が少し曖昧になるところです。
- Joe が戻ってきたときのセッション ID はわかっていますが (セッションはすべてのサーバーで共有されている可能性があります)、JMS サブスクリプションはどうでしょうか。サーバー F が再び Joe をトピックにサブスクライブする必要がある場合、Joe はメッセージを見逃しただけでしょうか? A は Joe がそのメッセージを取得できる唯一のサーバーですか、それとも、彼が F でサブスクライブし、メッセージを受信していない (おそらく A で彼を待っている) ことを知っているときに発生する可能性のある何らかの魔法がありますか?
「サブスクライブ」が何をするのか (プロセスに関して)、それがクラスター化されたサーバーとどのように関連するのかについて、私は少し不明確だと思います。トピックメッセージの受信に関してクライアントの応答性を高めるために、ロングポーリング (cometd) と websockets を使用していますが、接続とサブスクリプションを処理できるサーバーが多数ある場合に、これがどのように機能するかを検討する必要があります。サーバーのピン留めを避けたい。
ご指摘ありがとうございます。
EDIT1：うまくいけば、いくつかの明確化。ここで私が言及しているのは、BlazeDS フレームワークで利用できる特定のものです。HTTP クライアントが JMS トピックにサブスクライブできるようにし、ロング ポーリングを使用してほぼリアルタイムのクライアント更新を実現しますが、クライアントがサーバーに到達すると、すべての要求がその 1 つのサーバーに戻される必要があります。そのため、(どういうわけか?) そのサーバー上のそのクライアントのトピック サブスクリプションをアクティブにしておく必要があります。私はその要件を取り除きたいです（あらゆるテクノロジー/フレームワークで）。