2

少し助けてください。

次の機能を持つステートレスサーバーを設計しています。

  1. クライアントはサーバーにジョブを送信します。
  2. サーバーがジョブを実行しようとしている間、クライアントはブロックされます。
  3. サーバーは、ジョブを実行するために1つまたは複数のスレッドを生成します。
  4. ジョブは終了するか、タイムアウトするか、失敗します。
  5. （結果に基づいて）適切な応答が作成され、クライアントのブロックが解除され、応答がクライアントに渡されます。

これが私がこれまで考えてきたことです。

  1. クライアントはサーバーにジョブを送信します。
  2. サーバーはIDをジョブに割り当て、ジョブをキューに配置してから、クライアントを別のキュー（ブロックされる場所）に配置します。
  3. ジョブを実行し、結果をフェッチして適切に応答を作成するスレッドプールを用意します。
  4. IDに基づいて、キューからクライアントを選択し（それにより、ブロックを解除し）、応答を返し、送信します。

手順1、3、4は非常に簡単に思えますが、クライアントをキューに入れてブロックする方法についてのアイデアはありません。また、この子犬をデザインするのに役立つポインタをいただければ幸いです。

乾杯

4

3 に答える 3

2

なぜクライアントをブロックする必要があるのですか? （ほとんど）すぐに（もしあれば最初の検証を実行した後）戻り、クライアントに特定のジョブの一意のIDを与える方が簡単なようです。クライアントは、その ID を使用してポーリングするか、コールバックを提供することができます。

ブロッキングとは、同時にサービスを提供できるクライアントの上限数を明らかに制限するソケットを保持していることを意味します。それがあなたのシナリオにとって問題ではなく、絶対にブロックする必要がある場合 (おそらく、クライアント コードを制御できず、それらをポーリングすることもできませんか?)、ジョブを実行するためにスレッドを生成する意味はほとんどありません。並列タスク。その場合の唯一の「キュー」は、共通スレッドプールによって保持されるものです。ワークフローは基本的に次のようになります。

  1. スレッドプールを作成します ( ThreadPoolExecutorなど)
  2. クライアント要求ごとに:
    1. 並行して実行できるジョブの一部がある場合は、それらをプールに委任します。
    2. そして/または現在のスレッドでそれらを行います。
    3. プールされたジョブ パーツが完了するまで待ちます (該当する場合)。
    4. 結果をクライアントに返します。
  3. スレッド プールをシャットダウンします。

ID 自体は必要ありません。ただし、上記の 2.1 / 2.3 ではある種のラッチを使用する必要があるかもしれません。

タイムアウトは少しトリッキーかもしれません。多かれ少なかれ正確にする必要がある場合は、メインスレッド (クライアント要求を受信したスレッド) を作業から解放し、タイムアウトに達したときに送信されたジョブパーツを (フラグを反転して) 通知し、すぐに戻る必要があります。 . 上記のフラグを定期的にチェックし、反転したら実行を終了する必要があります。その後、プールはスレッドを再利用します。

于 2009-10-10T01:06:32.870 に答える
0

クライアントとどのようにコミュニケーションを取っていますか？

クライアントに到達するためのジョブパラメータとソケット（または他の通信メカニズム）を保持する各ジョブを表すオブジェクトを作成することをお勧めします。スレッドプールは、ジョブ処理の最後にクライアントのブロックを解除するための応答を送信します。

于 2009-10-10T00:19:01.400 に答える
0

タイムアウトはややトリッキーで、隠れた落とし穴がありますが、基本的な設計は単純で、コンストラクターで Socket を取るクラスを記述します。socket.accept では、優れた先見性とスケーラビリティの計画を立てて、新しいソケット処理のインスタンス化を行うだけです。または、これがベンチテスト実験である場合は、ソケット処理クラスがデータ処理スタッフに移動し、返されたときにいくつかの状態または何かのための一種のブール値または数値、null btw の便利な場所、およびイーサはソケットから出力ストリームに成功を書き込むか、クライアントにタイムアウトまたはビジネスで必要なものを通知します

長期にわたる大型輸送業者向けのスケーラブルで効果的な設計が必要な場合は、nio に直接アクセスしてください。私が説明するような手作業でコード化された 1 回限りのソリューションは、おそらくうまく拡張できませんが、nio 設計の基本的な概念化の基礎を提供します。コード修正作業の。

（申し訳ありませんが、私はコードで直接考えています-デザインパターンは、コードが機能した後にコードに適用されます。保持されないものは、前ではなく、その時点で作り直されます）

于 2009-10-10T01:43:12.860 に答える