メールのスケジュールにクォーツを使用したいと思っていますが、どのアプローチを取るべきかわかりません。
メッセージ/受信者などをいずれかの方法で渡す必要があります。大量のジョブを作成すると、かなりのメモリオーバーヘッドが追加されるかどうかはわかりません。これは、数千の電子メールがスケジュールされる可能性があるためです。
更新：これらのメールは私ではなくユーザーによってスケジュールされます-したがって、実行時にプログラムでこれらを追加します。特定の時間に送信されるようにはスケジュールされていません。
Quartz は、何万ものトリガーを処理することを目的としています。ここでのスケーラビリティの主な制限は、ジョブストアで利用できるスペースです。妥当なデータベースを備えた JDBCJobStore は、何十万ものトリガーを処理できるはずです。
トリガーのジョブ データ マップを使用して 1 つのジョブをパラメーター化できる場合は、メールごとに 1 つのジョブと 1 つのトリガーを作成します。Quartz はジョブストアを定期的にポーリングして、起動する準備ができているトリガーを探します。Quartz は、このクエリからの任意の大きな結果セットを安全に処理するように設計されています。
重要なのは、これは実際には Quartz 自体には関係ありませんが、ピーク負荷を実行するために必要な帯域幅があることです。ユーザーがメールをまとめてスケジュールする傾向がある場合は、メールを送信するためのコンピューティング リソースがあることを確認する必要があります。これには、ネットワーク帯域幅、処理、および利用可能なリソースを利用するように構成された十分なワーカー スレッドが含まれます。
ジョブの実行が大幅に遅れた場合に、Quartz がトリガーで何をすべきかを構成できることに注意してください。試行を続けたり、トリガーをスキップしたりできます。
トリガーはタイムスケジュールに基づいていますか? CronTriggerを使用して、個々のトリガーではなく、より複雑な時間ベースのスケジュールを設定できます。
1つのジョブと1つのトリガーをお勧めします。電子メール要求をデータベーステーブルに配置し、クォーツジョブに送信する新しい電子メールを探しさせます。
一連の電子メールをキューに入れるか、グループ化することを検討し、「バッチ」を処理する単一または場合によってはいくつかの定期的な（またはスケジュールされた）ジョブを作成することができます。
Quartzジョブに、消費して送信するワーカーのコレクションの電子メールをキューに入れることもできます。
何千ものQuartzジョブ/トリガーはお勧めしません-それはツール（IMHO）の使用目的ではありません。
編集：以下のコメントに応えて：
同じJVMでアプリケーションを実行するフレームワークの一部として使用する場合、何千ものQuartzジョブ/トリガーはお勧めしません。ジョブ/トリガーは、アプリケーションの他の部分とリソースを奪い合うことになります。