RabbitMQによる公平な分散タスクスケジューリング
問題：システムの単一のクライアントが、使用可能なすべてのリソースを大規模なワークロードで完全に溢れさせる可能性があります。キューは1つしかなく、だれでも任意の量の作業をスケジュールできると考えることができます。その後少量の作業を送信する他のクライアントは、最初のタスクが完全に処理されるまで待機する必要があります。これは非同期システムなので、DOSのリスクはありません。私たちが解決したい問題は、少数のクライアントが多くの作業を提出したかどうかに関係なく、クライアントがいつでもかなりの量の処理を行えるようにすることです。これは、十分な数のワーカーを備えた分散システムであり、タスクがシステム全体に正しく流れるように、すべての作業が小さな部分に分割されます。
これは私にとって非常に一般的な問題のようであり、非常に単純な解決策が見つからないという事実に少し驚いています。これは、プロセスにラウンドロビン方式で処理スロットが与えられるという点で、オペレーティングシステムのプロセススケジューリングに似ています。1つのプロセスが大量の作業を事前スケジュールすることはできません。
1つの解決策は、特定のキュートポロジを使用することです。ユーザーごとに1つのキュー。小さな制限付きキューにフィードします。後者のキューでは作業量が少ないため、長時間にわたって1つのプロセスがワーカーを独占することはできません。このような
これはRabbitMQまたはおそらくZeroMQに実装するのが簡単だと思っていましたが、いくつかの課題があります。最初に、新しいユーザーが作業を送信する場合、新しいキューを手動で作成する必要があります。 2番目に重要なのは、赤の部分を自分で実装し、すべてのキューを非ブロッキング方式でリッスンして、それらを制限付きキューに送信する必要があるようです。
私の懸念は、ここでは非常に低レベルの抽象化で作業していることです。必要なのは、容量制限の公平なタスクスケジューリングだけです。基本的に、バックプレッシャーを作成して、実際の作業の直前にスケジューリングが行われるようにして、ユーザーがシステムを独占できないようにします。
使用するより良い抽象化はありますか？
あなたが概説するパターンは一般的なものだと思います。 （独自の「ルーティングワーカー」をプログラムすることで）しかし、それを圧縮して、ルーティングロジック（赤）をワーカーに移動することができます。
たとえば、1つのキューをリッスンするワーカーの代わりに、ユーザーを認識するコードを追加します。
次に、同じワーカーサービスのユーザーキューごとにスレッドを起動し、CPUに各スレッドに時間を分散させます。
これは、多数のユーザーやCPUにバインドされたタスクにはやや最適ではないかもしれませんが、ソリューション全体を簡素化します。
同様の方法で、コストを渡すことができる場合、良い解決策は、ユーザーごとのキューだけでなく、クラウド内の新しいマシンで新しいワーカーを起動することです。
質問の前提に同意するかどうかはわかりませんが、これが理由です。
数学理論
キューイング理論 によると、どの先入れ先出しの確率的プロセスでも、リクエストの到着率と、プロセスがリクエストを処理するのにかかる平均時間があります。次に、プロセスは ポアソンプロセス のルールに従って動作し、プロセスのスループットだけでなく、キューの長さが任意の時点でどのくらい長くなる可能性が高いかを分析的に知ることができます。
したがって、分析/設計の観点から、いくつかの仮定が有効であることを確認する必要があります。
- リクエストの到着は指数分布を持つ確率変数です
- 個々のリクエストのサービス時間は、指数分布を持つ確率変数です
実際には、これらの仮定を正確に満たすことは困難ですが、基本的な設計と分析を行うのに十分な近似が得られます。それらが著しく違反している場合（たとえば、システムが要求のバッチを処理する場合や、一部の要求がその性質上他の要求よりも大幅に時間がかかる場合）、設計作業は、システムを基本的な前提に違反しない状態にすることに焦点を当てる必要があります。
状況
したがって、上記を前提として、リクエスト到着率lとサービス時間m、およびプロセッサ数cの確率的プロセスがあると仮定します。 c * mが到着率よりも低い場合、プロセスが不安定になり、キューのサイズが大きくなります。
したがって、システム設計の目標は、すべての妥当な時間に、インターバル中に到着すると予想されるリクエストを処理するのに十分なプロセッサ（c）を確保することです（〜l ）典型的なリクエスト処理時間（m）に基づいており、キューを含むシステムで費やされる合理的な最大時間の影響を受けます。
これを実行した場合は、処理する予定の要求を処理するようにシステムを適切に設計しました。実際には、このアプローチは非常に多くの状況で機能するため、これらのタイプのシステムで一般的に使用されている他のキューイングアプローチについては知りません。プリエンプションなしで優先キューイングを比較的簡単に設定できます（ファーストクラスのレーンが空港のチェックインで機能するのと同じように）が、それはどのように「公平」でしょうか。