0

AnyEvent::RabbitMQ を使用する RabbitMQ perl ライブラリ Net::RabbitFoot を使用しようとしています。RabbitMQ チュートリアルによると、 prefetch_count を 1 に設定すると、別のメッセージで既にビジー状態のワーカーにメッセージをディスパッチしてはならないため、公平なディスパッチが保証されます。ただし、Perl 実装のNet::RabbitFootは、こちらの 54 行で説明されているように qos を設定した後でも、そのようには機能しないようです。仕事。これがqosの実装です。なぜこれが起こっているのかを理解するのを手伝ってもらえますか? ライブラリのバグですか?

前もって感謝します。

編集:

これが私のセットアップです。2 つのコンシューマーが同じ名前のキューに接続されています。多くのメッセージをディスパッチすると、次のパターンが見られます。コンシューマ 1: Msg1、Msg3、Msg5 ... コンシューマ 2: Msg2、Msg4、... すべてのメッセージは同じキューからのものです。Msg3 がコンシューマ 1 を占有している場合、Msg5 はコンシューマ 1 に送信され、コンシューマ 2 は空いています。

4

1 に答える 1

2

バニララウンドロビン?え?

prefetch_count=1 は、同じ共通キューに多くのコンシューマーが接続されている場合に役立ちます。実際、デフォルトでは、クライアント ライブラリは一度に多くのメッセージをプリフェッチします。

したがって、これを 1 に設定することで回避したいデフォルトの奇妙な効果は、1 つのクライアントがほとんど (またはすべて) のメッセージを受け取り、他のコンシューマーはほとんどまたはまったくメッセージを受け取りません。

ただし、「バニララウンドロビン」について話します。これは、消費者ごとに1つずつ、直接交換に異なる(おそらく名前のない/一時的な)キューが接続されている場合に発生します。しかし、この方法では動的に負荷を分散する方法がありません。

私の推測が正しければ、構成を変更して、すべてのコンシューマーを同じ名前のキューにアタッチする必要があります。

編集:OPのコメントから、そうではありません。

または、コンシューマが自動確認で構成されているか、ジョブを完了するに確認応答を送信している可能性があります。この場合も、RabbitMQ クライアント API は、別のメッセージを自由に取得できると考えています。そのメッセージに関するローカル タスクが完了した後にのみ、ACK を返送する必要があります。

于 2014-04-02T21:15:27.690 に答える