0

すべてのユーザーが要求を開始し、サーバーからの応答を待機する 1 万人以上のユーザーをサポートする必要があります (応答が到着するまでに 20 ～ 30 秒かかる場合があります)。これはクライアントからの 1 つの要求であり、サーバーによる長い処理の後、応答が送信され、接続が切断されます。バックグラウンドでは、サーバーは DB 検索を実行し、クライアントに応答する前に他のバックグラウンド プロセスが完了を通知するのを待ちます。

いくつかの調査を行った後、netty (=> nettosphere ) またはjettyなどの非同期サーバーとともに、websockets/sse イベント/ロング ポーリングをサポートするために、大気フレームワークのようなものを使用する必要があることがわかりました。私の経験については、主にJava EEの世界とTomcatサーバーです。

私の質問は次のとおりです。

  1. 私の経験と私たちの要件に関して、どちらが実装しやすいでしょうか: 大気 + ネットまたは大気 + 桟橋? 拡張性が高く、学習曲線が簡単で、他の Java テクノロジを実装しやすいのはどれですか?

  2. 元のクライアントにのみ送信され、残りのクライアントにはブロードキャストされない応答を大気中に実装するにはどうすればよいですか? （私が見つけたすべての例は放送されています）。

  3. 大気フレームワークの応答を使用する場合、netty (または jetty) でどのように実装できますか? つまり、クライアントがリクエストを送信し、それがサーバーで受信された後、いくつかのバックグラウンド プロセスが実行されます。それらが終了したら、接続を見つけて応答を送信する必要があります。それは達成可能ですか？

4

2 に答える 2

0

AKKA フレームワークは、この種のニーズに対応できると思います。おそらくRabbitMQを使用してスケーリングの問題を処理し、後で必要に応じてスケーリングするために追加される可能性のある他のサーバーに作業をオフロードするのに使用することを検討しています。

于 2013-12-12T04:50:30.413 に答える
0

いくつかの考え：

  1. 1 万人以上のユーザーで、20 ～ 30 秒の応答待ち時間がある場合、ネットワーク インターフェイスを 1 つだけ使用すると、ファイル記述子の制限に達する可能性があります。複数のネットワーク インターフェイスを使用するソリューションを検討してください。

  2. リクエスト/レスポンスの説明は、標準のサーブレット 3.0、標準の HTTP/1.1、非同期リクエスト処理、および大きなタイムアウトで完全に処理できます。

  3. クライアントが Web ブラウザーで、サーバーからの応答の送信を 20 ～ 30 秒の時間枠まで開始しない場合、ブラウザーのアイドル タイムアウトに達する可能性があります。

  4. Atmosphere と Cometd は同じことを行い、長時間の接続をサポートし、接続技術のフォールバックと論理チャネル API を使用します。

于 2013-07-02T20:58:33.683 に答える