ワーカー プールが互いに異なる (ただし頻繁に重複する) 基準に基づいて作業メッセージをサブスクライブできるように、RabbitMQ を介して作業を分散するにはどうすればよいでしょうか。仕事？
簡単な例:
- host1 と host2 があります。
- Host1 は、classA と classB のジョブを処理します。host2 は、classB と classC のジョブを処理します。
- classA のジョブをルーティングすると、host1 だけがそれを受け取ります。classB のジョブをルーティングすると、host1 または host2 のいずれかが (現在の負荷 / 最初に利用可能なものに基づいて) それを取得しますが、両方を取得することはありません。
ルーティング基準が複雑で、ワイルドカードを使用すると、必要なタイプの柔軟なマッチングが得られるため、トピック交換を使用する必要があるようです。
でも：
- ワーカー プール キューに同じ名前 (「worker-jobs」など) を使用すると、必要な作業が任意の一致するワーカーに分割されますが、名前付きキューにサブスクライブするすべてのワーカーは、他のワーカーに互いのルーティング基準を感染させるようです。彼らはそれをバインドします。つまり、ルーティング キーのバインディングは、接続からキューへのベースではなく、中央のキュー名レベルにあるようです。
- 同じ交換への各ワーカー プール接続 (「poolA-jobs」と「poolB-jobs」など) に異なるキュー名を使用すると、プール間で維持される異なるルーティング基準で望ましい動作が得られますが、入ってくるジョブは可能です。 poolA と poolB の両方に一致すると、両方にルーティングされます (ただし、それぞれのワーカーは 1 つだけです)。
ノート：
- 理由の詳細は省きますが、50 ミリ秒未満の応答時間を必要とする既存のマルチペタバイトの分散検索アプリケーションがあると言えます。独自のカスタム ルーティング ハブで既にこれを実現していますが、必要な洗練されたルーティングを取得できる場合は、RabbitMQ のパフォーマンスが魅力的であるため (汎用コミュニティ プロジェクトと重複する自家製コードを廃止するため)、RabbitMQ に置き換えたいと考えています。
- 私たちはPythonを使用しています
- ディスコは多くの理由で実行可能ではありません。
- RabbitMQ である必要はありませんが、パフォーマンスが優れている必要があります。ØMQ は非常に興味深いようで、柔軟性とパフォーマンスの両方を提供する可能性がありますが、すでに RabbitMQ を使用しており、カラフルに書かれた ØMQ ガイドの前半を読んだ後でも、必要なルーティングをサポートするかどうかはまだわかりませんが、それを行うには、ほとんどブローカーを作成する必要があるようです。
- 実際には、どのホストがどのジョブを処理できるかを知る余裕があるので、host1 を #.host1.# にサブスクライブさせ、host2 を #.host2.# にサブスクライブさせることができます。次に、classB メッセージをルーティングするときに、host1.host2 のキーを指定して、どのバックエンドがサービスに受け入れられるかを示すことができます。これにより、ルーティング ルールが簡素化されますが、説明した問題は解決されません。