大きな「作業キュー」/「入力キュー」を管理する最も良い方法は？

Question

私たちのシステムでは、ジョブの入力として使用する必要がある項目のIDを含む入力キューを使用しているジョブがあります。数千の入力キューがあり、各キューには数十万から数百万のIDが含まれています。ジョブは通常、1つのキュー（約20.000）からIDのバッチを取得し、そのジョブを実行します。一方、キューにIDをプッシュするプロデューサがいくつか用意されています。これらはバッチでも機能しますので、同時に数千〜数百万のIDを同時にキューに挿入しています。

私たちのプロデューサーはしばしばキューに複製をプッシュするので、私たちはRabbitのようなメッセージングシステムを使用しませんでした。そのため、セットロジックを持つことが望ましいです。さらに、私たちの仕事は物がキューにプッシュされると通知を受け取るので、それを購読する必要はありません。

キューの内容が一時的で、障害が発生した場合にデータが失われる可能性があります。

誰もこの問題を最もよく解決する方法をお勧めしますか？

私たちは現在、idが主キーであり、キューを識別する2番目の列があるRDBMSテーブルを使用しています。挿入は、ON DUPLICATE KEY UPDATE構文を使用して行われるため、1つのバッチ文ですべてを実行できます。欠点はIO負荷が高いことです。利点は、手動で介入する必要がある場合に備えて、キューの内容を簡単に調べて、手動操作（バルク挿入、削除など）を非常に簡単に実行できることです。

私はRedisが選択肢になりそうなのか疑問に思っています。ディスクにバインドされているときに実行されますか？セット/キューから「取り出す」（&を削除する）場合はどうなりますか？ I/Oに関して大きな負荷を掛けたり、置いたりしますか？

技術（私たちはJVMベースの言語を使用しています）やデータベースに関わらず、入力は歓迎です！

Answer 1

IDだけを保存した場合、赤とそのセットはジョブに最適なツールです。一意性を処理し、遅いSQL部分を持たないので、SPOPは一度に複数の項目をポップできます（ランダムに選択します）。

しかし、データ量が使用可能なRAMを超えている場合はうまく機能しません。そのため、考慮する必要があります（十分なRAMを確保してください）。プラスの面では、各トランザクションでI/Oはありません！ :)

あり、それらの入力キューの数千があり、各キューは、IDSのサイズによっては数百万個のID

、このデータセットのか​​もしれないまで数十-数千人から含まれてい1台のマシンに収まるように問題がある。一度に1つのキューしか使用しないので（正しい？）、データセットを複数のマシンに分割するredisクラスタを安全にデプロイできます。