要件は次のとおりです。
現時点では、消費側のキューイングは、キューをサブクラス化するカスタムキューとして実装されていますが、プロセスの再起動時にキューが失われるという主な問題があります。
上で概説した要件を満たすことを可能にする製品はありますか？永続性のサポートは素晴らしいものでしたが、それはそれほど重要ではありません（キューはワーカープロセスのメモリに存在しなくなるため）。
あなたが探していることをする多くの製品があります。Djangoの経験がある人はおそらく「セロリ」と言うでしょうが、それは完全な答えではありません。Celeryは、実際のキューイングシステムの（便利な）ラッパーであり、ラッパーを使用しても、基盤となるテクノロジーについて考える必要がないという意味ではありません。
ZeroMQ、Redis、およびRabbitMQは、頭に浮かぶいくつかの異なるソリューションです。もちろん、もっと多くのオプションがあります。構成パラメーターとして「処理中のメッセージは常に1つだけである必要があります」という要件をサポートするキューイング・ソリューションはないと確信しています。おそらく、プロデューサーでこの要件を実装する必要があります（つまり、ジョブ＃1が完了したという確認を受け取るまで、ジョブ＃2を送信しないでください）。
Redisは実際のキューイングシステムではありませんが、pub/sub機能を備えた非常に高速なデータベースです。Redis pub / subを使用して、「ジョブを1回だけ処理する」要件を満たすことはできませんが、Redis pub / subを使用して単一のサブスクライバーにジョブをパブリッシュし、データベースにプッシュすることはできます。リスト（貧乏人のキュー）。次に、消費者はリストからアトミックにジョブをプルします。このルートに行きたい場合はうまくいきます。
RabbitMQは「エンタープライズ」キューイングシステムであり、要件を完全に満たしますが、RabbitMQサーバーをどこかにデプロイする必要があり、やり過ぎになる可能性があります。記録のために、私は多くのプロジェクトでRabbitMQを使用し、それが仕事を成し遂げます。「直接」タイプの交換を設定し、それを単一のキューにバインドして、すべてのコンシューマーをこのキューにサブスクライブします。RabbitMQからもかなり良い永続性が得られます。
ZeroMQには非常に柔軟なキューイングモデルがあり、ZeroMQは絶対にあなたが望むことをするように作ることができます。ただし、ZeroMQは基本的に単なる転送メカニズムであるため、パブリッシャーとサブスクライバー、およびそれらを配布するブローカーを作成する場合は、独自のメカニズムを使用することになります。