1

[小さなコンテキストプロバイダーとして:私はネットワーキングとZERO-MQに不慣れですが、ガイドと例にかなりの時間を費やしました]

私には次の課題があります(C ++で実行されますが、質問とは無関係です)。タスクを生成する単一のソースがあります。これらのタスクを処理し、結果を送り返す必要がある複数のエンジンがあります。

最初の試み: ZMQ_PUSHソケットを使用してクライアントを作成しました。エンジンにはZMQ_PULLソケットがあります。クライアントに回答を返すために、逆を作成しました。ワーカーにZMQ_PUSHを作成し、クライアントにZMQ_PULLを作成しました。それは箱から出して働いた。しばらくすると、ワーカーが処理できるよりもはるかに多くのリクエストをプッシュしていたため、クライアントのメモリが不足していることがわかりました。背圧が必要です。

2番目の試み: 1000個のタスクが「進行中」であると言うだけの場合にのみプッシュを処理するカウンターをクライアントに追加しました。「進行中」のタスクが1000を超えることはなかったため、メモリ不足の問題は解決されました。しかし...一部の労働者は他の労働者よりも遅かった。PUSH / PULLは均等化キューイングを使用するため、その遅いワーカーの作業量は増え続けました...最も遅いワーカーが1000のリクエストすべてをキューに入れ、他のリクエストが不足するまで。私は労働者を効果的に使用していませんでした。

さて、「異なる速度の労働者」の問題を解決するために、どのアーキテクチャを使用できますか?「進行中のタスクの数を数える」アプローチは、プッシュされたリクエストの数のバランスを取るための良い方法ですか?または、タスクをワーカーにプッシュし、事前定義されたポイントでブロックをプッシュする方法はありますか?HWMでそれを行うことはできますか?

この問題は非常に一般的な性質のものであるため、簡単に対処できるはずです。誰かが私を正しい方向に向けることができますか?

ありがとう!

4

1 に答える 1

1

Paranoid Pirate Protocol http://rfc.zeromq.org/spec:6を使用しました。

しかし、通信のオーバーヘッドが高くなる非常に小さなジョブが多数ある場合は、クレジットベースのフロー制御パターンの方が効率的です。http://unprotocols.org/blog:15

どちらの場合も、リクエスタはジョブを個々のワーカーに直接割り当てる必要があります。これはもちろん抽象化されており、ユースケースによっては、すべてのタスクが処理されたときに返される同期呼び出しとして使用できるようにすることもできます。

于 2012-06-14T13:47:38.763 に答える