だから、ZeroMQ パイプライン アーキテクチャのこの小さな例を作成しました。これは、近いうちに同様のことを行う必要があり、パイプラインの概念を正しい方法で把握しようとしているからです。
https://gist.github.com/2765708
現在、これは完全に非同期です。コントローラーはタスクのバッチをさまざまなワーカーにディスパッチし、ワーカーは次にメッセージをシンクに送信します。コントローラーとシンクは私のアーキテクチャの固定部分ですが、ワーカーは動的です。それは最高です。
ただし、労働者がすべてのタスクの作業をいつ終了したかを知りたいです。その例では、メッセージの量はわかっていますが、実際の状況ではそうではありません。100通か10,000通のメッセージがあるかもしれません。では、シンクまたはコントローラーは、ワーカーがタスクの作業を終了したことをどのように知ることができるのでしょうか? ワーカーに送信されたジョブの結果に応じて、いくつかのアクションを実行する必要があります。
@bjlaubの回答を拡張したかったのです。コメントとして始まりましたが、入力しすぎました。承認の概念には同意しますが、複数の場所で発生する可能性があると考えています。
このコミュニケーションには複数のアプローチがあり、それはすべて、システム内で求めている動作に依存します。
まず、ワーカーが各タスクを完了するときにメッセージを送信するか、シンクが各タスクを受信するときにシンクからメッセージを送信できます。現時点では、ソケットの種類については言及していません。通信の行為についてのみ言及しています。ワーカーごとに 1 つではなく、コントローラーへの接続が 1 つしか必要ないため、シンクから送信する方がはるかに効率的であると思います。シンクは、合計タスク数を知る必要はありません。結果を受け取るたびにメッセージを送信しているだけです。コントローラーは、それが送信ポイントであり、送信を使い果たしたときに新しいものであるため、予想される数 (カウント) を決定できます。
これで、メッセージがワーカーまたはシンクのどちらから送信されたかに関係なく、さまざまなソケット タイプを使用できるようになりました。すべての作業が完了するまでコントローラを完全にブロックする場合は、X メッセージを受信するまでコントローラをプッシュ/プルにすることができます (メッセージの内容は何でもかまいません。単なるトリガーです)。
これらのタスクが発生している間にコントローラーが他の作業を実行できるようにしたい場合、これは制限になる可能性があります。その場合は、pub/sub を使用して、コントローラーがタスクの完了時に通知されるようにサブスクライブさせ、合計が満たされるまでカウントを非同期に維持することができます。
最後に、コントローラーが適切と判断したときに、シンクにステータスを要求する必要がある場合があります。コントローラーが要求に応じて受信した要求の数をシンクに問い合わせる req/rep パターンを持つことができます。
これらのパターンのいずれかが特定のニーズに合うと確信しています。
1つのアイデア（免責事項：0MQの経験はほとんどありません！）：
逆方向の「承認」パイプラインをセットアップします。コントローラーはおそらくワーカーにディスパッチしたタスクの数 (たとえば、 を呼び出した回数send) を知っているため、PULL ソケットを使用して、各ワーカーからタスクの完了を示す小さなメッセージ (たとえば整数) を受け取ることができます。 . ワーカー プロセスは、完了した結果をシンクにディスパッチし、同時に確認をコントローラーに送り返します。コントローラーが適切な数の確認応答を収集すると、次の一連の作業を開始する前に、必要な後処理を実行できます。
これを下流のシンクにプッシュすることもできますが、ワークユニットをワーカーにファームアウトする前に、予期されるワークユニットの総数をシンクに通知する必要があります。