キューイング：次のようにN、N個の消費者に生産

Question

要件は次のとおりです。

• メッセージやジョブを生成したり、あなたがそれを呼び出すために好きなNの生産者が、あります。
• 各procuderからのメッセージを順番に処理する必要があり、各メッセージは一度だけ処理する必要があります。
• もう1つの制限があります。特定のプロデューサのためにいつでも、処理されるメッセージは複数ありません。
• 消費側は、いくつかのプロセスにまたがっているいくつかのスレッド（機能的には同じです）から成ります。これは、mod_wsgiを介して実行されるWSGIアプリケーションです。現時点で

、消費する側のキューイングはQueueをサブクラスカスタムキュー、として実装されますが、それは私が浸入しない独自の問題を抱えている、主なものは、プロセスにそのを再起動することをされていますキューは失われます。

私は上記で概説した要件を満たすことができる製品はありますか？永続性のサポートは素晴らしいですが、それはだからという重要なものではありません（キューはワーカープロセスのメモリにはそれ以上存在しないため）。

Answer 1

あなたが探していることをする多くの製品があります。 Djangoの経験を持つ人は、おそらく "セロリ"と言うでしょうが、それは完全な答えではありません。 Celeryは実際のキューイングシステムを包む（有用な）ラッパーであり、ラッパーを使用しても、基本的なテクノロジーについて考える必要はありません。

ZeroMQ、Redis、およびRabbitMQは、いくつかの異なる解決策です。もちろん、もっと多くのオプションがあります。私はかなりのキューイングの解決策はあなたの "任意のプロデューサのためにいつでも処理されているメッセージが1つ以上でなければならない"という設定パラメータとしての要件をサポートしないことを確信しています。プロデューサでこの要件を実装する必要があります（つまり、ジョブ＃1が完了したという確認を受け取るまで、ジョブ＃2を送信しないでください）。

Redisは実際のキューイングシステムではありませんが、pub/sub機能を備えた非常に高速なデータベースです。 Redis pub/subを使用して「ジョブが一度だけ処理されました」という要件を満たすことはできませんが、Redis pub/subを使用して単一のサブスクライバにジョブを発行してから、リスト（貧しい人の列）。あなたの消費者は、リストから仕事をアトミックに引き出します。あなたがこのルートに行きたいなら、それはうまくいくでしょう。

RabbitMQはエンタープライズのキューイングシステムであり、あなたの要件を完全に満たすことができますが、RabbitMQサーバをどこかに配置する必要があり、過度の負荷になる可能性があります。記録のために、私はRabbitMQを多数のプロジェクトで使用しています。 「直接」型交換をセットアップし、それを単一のキューにバインドし、すべてのコンシューマをこのキューにサブスクライブします。あなたはRabbitMQでもかなり良い持続性を得ます。

ZeroMQは非常に柔軟性の高いキューイングモデルを備えており、ZeroMQはあなたの望むことを絶対に行うことができます。 ZeroMQは基本的には転送メカニズムですが、パブリッシャーとサブスクライバー、そしてブローカーにそれらを配布させることになると、あなた自身がロールバックしてしまうかもしれません。