スループットが遅い-専用メッセージキューを使用する価値はありますか？
キューの要件は次のとおりです。
- 数日ごとに、さまざまな優先度で最大10万のタスクを追加します
- ワーカーは通常10秒未満でタスクをプルします
- （エラーチェックのために）〜2人の一意のワーカーがタスクを完了し、結果に応じて追加のワーカーがタスクを完了する必要がある
- タスクの永続的なストレージ
タスクの処理率はかなり低いので、専用のメッセージキューイングシステムをスタックに追加したり、データベース（MongoDB）を再利用したりする価値はありますか？
あなたが何を成し遂げようとしているのかを完全に理解しないと言うのは難しいですが、あなたの言っていることに基づいて、データベースはもっと理にかなっていると思います。データベースとキューシステムを併用したい場合があります。
その理由は、この種の状況では、通常、ある種の監査バランス制御機能が必要であり、キューはこれを提供しないためです。あなたは正しいときに誰が何をしたか知りたいのですか？どこで追跡しますか？おそらくDBにあります。また、労働者がタスクを選択してから家に帰るなど、心配する必要があります。キューでコミットされていない長期間の読み取りを大量に実行したくない場合。
キューについて理解する重要なことは、読み取りは破壊的であることです。これは、多くの一般的な状況で（それ自体では）不十分なソリューションになります。簡単に言えば、誰かが読み取りをコミットすると、メッセージがそこにあったことを知るのは困難から不可能です。メッセージがコンシューマーによって読み取られてコミットされても、そのコンシューマーがメッセージを正常に処理できない場合、物事が失われる可能性があります。多くの待ち行列システムには「保証付き配信」があり、これは人々が考えているほどには意味がありません。それは単に目的地に到着した（または配信できないと報告された）ことを意味しますが、消費者が何かをしたとは限りません。 「それで、データベースから読んでもそれは変わりません」とあなたは言うかもしれません。違いは、DBからメッセージを読み取っても消えないことです。多くの場合、データベースから削除するのではなく、ステータスを追跡することもできます。これは、消費者の欠陥が原因でメッセージを失うことがないことを意味します。
ここではハイブリッドソリューションがうまく機能すると思います。キューを分散メカニズムとして使用します。それらは、同じもののセットからプルする多数のリーダーを処理し、1つのリーダーだけがそれぞれのものを取得するようにするのに最適です。あなたはDBでそれを行うことができますが、それはちょっと醜いです。次に、リーダーがアイテムを要求すると、ほとんど競合することなく、その情報でDBを更新できます。 2ワーカーの要件に応じて、同じメッセージをキューに送信できます（同じワーカーが両方のリクエストを処理しないようにするメカニズムが必要です）。また、ワーカーがメッセージをプルしたがタスクを実行しない場合も同様です。
ここで最も印象に残っているのは、スループットが遅いことではありません。数日ごとに約10万タスクです。バッチ処理のように思えます。時々シャットダウンしてアップデートをインストールできるように、永続的にしたいもの。これは必ずしもDBを意味するわけではありませんが、揮発性メモリのみに保持したいものではありません。
私は最近 ActiveMQ でApache Camelを使用しており、メッセージキューは非常に扱いやすいと言えます。スピードとパフォーマンスは私にとってまったく問題ではありませんでした。
ActiveMQは、他のほとんどすべての大規模メッセージブローカーとともに永続性をサポートします。ActiveMQでは、configでデータベースへのファイルパスを指定するのと同じくらい簡単です。スループットが問題である場合、 Apache Kafka が適切な候補であると聞きました。
Kafkaの理論上のスループットは、ActiveMQが144バイトで各メッセージをフラッフするため、ActiveMQよりも高く、Kafkaたった9（！）バイトです。
私の経験では、おそらく私はデータベースウィザードではないため、メッセージキューでより良い結果を作成する方が簡単だと思います。
この記事を参照してください： Queue As Queue Anti-Pattern