定期的なバッチ通知システムを設計する
問題：
- 顧客からのリクエストをリアルタイムで受け取り、データベースに記録するシステムを設計しています。たとえば、商品の購入をリクエストします。
- 次に、顧客は自分の要求に対して一意の要求IDを取得し、要求が処理されているために「X」日待機するように求められます。
- 次に、システムはこれらのすべてのリクエストを1つの電子メールに定期的にバッチ処理することによってアイテムプロバイダーに通知します（4時間としましょう）。
- アイテムプロバイダーは、リポジトリ内のアイテムを更新し、顧客に公開します。そして、顧客はアイテムプロバイダーが彼の要求に応答したという通知を受け取ります。
デザイン：
このユースケースでは、ワークフローベースのシステムを使用することを考えています。以下のコンポーネントを使用（高レベル）-
Synchronous API:
- Receive request from customer.
- Record the request in the database.
- Also start an asynchronous workflow, return request id as a response.
ワークフローは次のことを行います。
Workflow Step 1:
- Get the list of item providers
- Notify them
Workflow Step 2: (This workflow steps gets executed after "X" days)
- Send a response email back to the customer
しかし、バッチ処理のユースケースをサポートするのに苦労しています。個別にcronジョブを作成しなくても、4時間ごとに効率的に顧客の要求をバッチ処理して通知を送信できる方法はありますか？
私はこれについての提案/助けをいただければ幸いです。
これは非常に簡単です。タスクの処理要求は通常どおり行われます-発生するのは、タイムスタンプが付いたエントリがDBに書き込まれることだけです。実装するのは簡単です。
プログラムの他の場所で、必要な時間スリープ状態になり、4時間後に起動し、すべての未処理のタスクを読み取り、それらをサプライヤーに送信するスレッドがあります。
同じことが応答にも当てはまります。サプライヤはシステムに応答を送信し、システムはそれをDBに書き込みます。定期的にタスクが起動し、未解決の応答をすべて読み取り、顧客にメールを送信します。
これで、ステップが顧客とサプライヤーの両方で同じであることがわかるはずなので、これを最適化できます。リクエストを受信してデータをDBに書き込む1つのシステムと、応答の読み取りと送信を担当する別のシステムをセットアップできます。その後さらに最適化すると、cronなどの外部システムを使用してウェイクアップ処理を処理できます。処理をトリガーするシステムにリクエストを送信するだけです。
したがって、顧客の要求とサプライヤの応答に再利用される少量のアーキテクチャをコード化するだけで済みます。ウェイクアップとプロセスのエントリ。これが主にバッチ処理のポイントです。非常にシンプルに保ち、同じプロセスを再利用して異なるデータを処理します。
あなたはそれを-1）Java/Perl/Shellスクリプトスタンドアロンプログラムを00:01にcronで開始し、プログラムは毎日23:59に終了することで実行できます。
プログラムでは、構成ファイルを読み取って、必要な間隔でスリープすることができます。いつでも構成を変更できるので、動的になります。また、将来スタンドアロンプログラムに機能を追加することもできます。
したがって、それは1回だけスケジュールします。これにより、コマンドプロンプトでいつでも強制終了でき、再起動が簡単です。
データベーススケジューラを使用しないことをお勧めします。
あなたのデザインは 非同期メッセージング の恩恵を受けることができるようです
メッセージは、さまざまなパイプラインを介して複数の受信アプリケーションに送信し、特定の時間に実行するようにスケジュールすることができます（スケジュールはメッセージバスの組み込み機能（ミドルウェア）にすることも、ソリューションでベイクすることもできます（シャッドされて応答します）。タスクIDメッセージを送信し、後で実行するためにタスクを別のアプリケーションに送信する）
バッチ処理は、このアーキテクチャ内で、特定のプロパティ値を持つメッセージを収集し、それらをグループ化して、特定の時間枠ごとに異なるメッセージ（バッチメッセージ）として送信するゲートウェイアプリとして発生する可能性があります。
ここで説明した内容は非常に抽象的であることがわかりましたが、ここでアーキテクチャ全体を説明することも実用的ではないことも覚えておいてください。
この回答が、メッセージングのアーキテクチャパターンについての詳細をお読みいただけるように願っています。後で他のより具体的な質問に回答させていただきます。