リモート Web サイトから情報を取得して再検証するジョブを作成しています。私は実際に、次のように機能するキューを使用して既に実装しています。テキスト ファイルが読み取られ、5k 単位でスライスされ、スレッド プロセッサに渡されます。スレッド プロセッサは終了し、新しいワーカーが生成されます。
私はresqueを調べていますが、このような問題について一般的な種類の設計上の質問がありました. では、5 ～ 2,000 万単位の作業になる可能性があるジョブがある場合、キューを格納するためのベスト プラクティスは何ですか? たとえば、理論的には作業を分割して保存し、そのチャンクのジョブを作成したり、キューに 5 ～ 2,000 万の個別の項目を入れることができます。フェッチ/再生成される作業には多くのオーバーヘッドがあるようです。ただし、作業をチャンク化しようとすると、かなりのオーバーヘッドが発生し、コーディングが増えます。
私たちが行って見たことに基づいて、良いアプローチは、実行前ではなく実行時に作業をチャンク化することです。言い換えると、イベントまたは時間駆動型のマスター/スレーブパターンであり、マスターは、キューに入れられて実行されるときに、作業/データスペースを細かいタスク/チャンクにスライスします。
この理由は、粗い粒度レベルで実行すると、スケジュール内のジョブの表示がはるかに簡単になるためです。このレベルでは、ジョブは追跡しているユニット（Webページ、ユーザープロファイル、センサーからのストリーミングデータなど）に対応します。
私たちはしばしばきめ細かいレベルでスライスするのを見ますが、それから各労働者が合理的なタスクのコレクションに取り組んでいるのを見ます。各ワーカーに複数のタスク（タスクのタイプ/長さに応じて20〜1000？）を処理させると、次のバランスが取れていることがわかりました。
長時間実行されるタスクではなく、各ワーカーの処理時間を分単位にして、ワーカーのパフォーマンスをより明確にし、再試行が限られた量のワークスペースにのみ影響するようにする必要があります。NoSQLソリューション（特にMongoHQやMongoLabsなどのサービスとしてのデータベース）を利用すると、チャンク化と処理中の作業を簡単に追跡および管理できます。
もう1つの推奨事項は、アプリケーション環境から独立したワーカーを作成することです。これは、コールバック、データベースフラグ、およびその他の非同期アプローチを使用するだけでなく、各ワーカーを合理的に自己完結するように作成することを意味します。少し手間がかかるかもしれませんが、MVCアプリケーションの設計と同じように、俊敏性が大幅に向上し、弾力性のあるワーカーシステムに作業を分散できます。
（完全な開示：私はIronMQ、IronWorker、およびIronCacheのメーカーであるIron.ioのチームに所属しています。）