networking - キューはいつ使用する必要がありますか？

Question

中央サーバーと複数のクライアントとのチャットなどのネットワークアプリケーションを実装するとします。すべての通信は中央サーバーを経由する必要があり、次にいくつかのクライアントからメッセージを取得してターゲットクライアントに転送する必要があります。すぐ。

使用されているテクノロジ（ソケット、Webサービスなど）に関係なく、プロデューサースレッド（メッセージを生成する）とコンシューマースレッド（メッセージを読み取る）がいくつかあると考えることができます。

たとえば、着信メッセージと発信メッセージに単一のキューを使用できますが、単一のキューを使用すると、一度に1つのスレッドしかキューにアクセスできないため、メッセージの送受信を同時に行うことはできません。

おそらく、2つのキューを使用する方が適切でしょう。たとえば、この記事では、プロデューサーとコンシューマーがほぼ同時に作業できるように、ダブルキューを管理する方法について説明します。このシナリオは、プロデューサーとコンシューマーしかない場合は問題ないかもしれませんが、クライアントが多い場合は次のようになります。

• 中央サーバーが複数の入力ストリームから同時にデータを受信できるようにするにはどうすればよいですか？
• 中央サーバーが複数の出力ストリームに同時にデータを送信できるようにするにはどうすればよいですか？

この問題を解決するために、私の考えは、クライアントごとに二重キューを使用することです。中央サーバーでは、各クライアント接続を2つのキューに関連付けることができます。1つはそのクライアントからの着信メッセージ用で、もう1つはそのクライアント宛ての発信メッセージ用です。このようにして、中央サーバーは、クライアントとのほぼすべての接続で同時にデータを送受信できます...

キューを管理する方法はおそらく他にもあります...必要なキューの数とそれらを整理する方法を決定するためのパラメーターは何ですか？キューを必要としない場合がありますか？

Answer 1

私には、クライアントごとにキューを使用する、またはクライアントごとに複数のキューを使用するというこのアイデアは、要点を見逃しているように見えます。まず、2つのスレッドで同時にアクセスできるキューを作成することは絶対に可能です（1つはアイテムをエンキューし、別のスレッドは別のアイテムをデキューすることができます）。方法を知りたい場合は、それに関する具体的な質問を投稿してください。

第2に、一度に1つのスレッドのみが単一のキューにアクセスできると想定し、サーバーがすべてのクライアントとの間で同時にデータを送受信すると想定しても、必要なことを実行できません。クライアントごとに異なるキュー。システムパフォーマンスの制限を回避するには、サーバーのすべてのCPUを利用するのに十分な同時実行性を許可する必要があります。システム全体の単一のキューであっても、メッセージのデキュー/エンキューがサーバーが実行している他の作業と比較して十分に高速である場合、それはボトルネックではない可能性があります。（そして効率的な実装では、単にアイテムを挿入するか、キューからアイテムを削除するだけです。非常に速くなります。これは非常に単純な操作です。）そのメッセージキューがパフォーマンスを制限するボトルネックになるには、多数のCPUが必要になるか、サーバーが実行していた他のすべてが非常に高速である必要があります。その場合、2倍または4倍の同時実行性を可能にするために、2つまたは4つのシステム全体のキューを使用していくつかのスキームを作成できます。

マルチスレッドシステムでワークキューを使用するという全体的な考え方は、1）複数のコンシューマーがすべて単一の場所から作業を取得できるようにすることです。これにより、プロデューサーは、どのコンシューマーを気にすることなく、その単一の場所で必要な作業を「ダンプ」できます。それを行い、2）消費者の負荷分散メカニズムとして機能します。（さらに、プロデューサーが一時的にコンシューマーに対して速すぎる作業を生成する場合、ワークキューは「バッファー」として機能する可能性があります。）それぞれに専用のプロデューサーとコンシューマーのスレッドのペアがある場合クライアント、それはあなたがキューをまったく使用する必要がある理由に疑問を投げかけます。専用プロデューサーから対応する専用コンシューマーへの同期「パスオフ」を実行しないのはなぜですか？または、プロデューサーとコンシューマーの両方として機能するクライアントごとに1つのスレッドを使用してみませんか？あなたが提案している方法でキューを使用しても、実際には何も得られないようです。