私は現在、ユーザーがHTTP APIに対して（ユーザーに代わって）実行されるタスクをスケジュールできるようにするWebアプリケーションを設計しています。タスクは繰り返し発生する可能性があり、スケジューリングに使用できる最小の時間分解能は1分になります。タスクの性質上、非同期で実行するのは理にかなっていると思います。しかし、この部分のアーキテクチャはどのように見えるべきですか？
タスクキューを使用してWebアプリケーションでタスクを作成し、それらをワーカーで実行できるようにすることを考えました。この場合、いくつか質問があります。
他に何を考えられますか？この種のWebアプリケーションアーキテクチャについて考えているのは私だけではないと思いますが、「ベストプラクティス」はありますか？タスクキューは進むべき道ですか？
はい、これはWebアプリケーションのバックエンドで長期間有効なタスクを処理するためのよく知られたパターンです。言語とアプリケーションフレームワークに応じて、キューの実装がいくつかあります。たとえば、 Resque、Beanstalkd、ActiveMQなどです。パフォーマンス要件が高くない場合は、データベーステーブルを一種のキューとして使用できます。
基本的な考え方は、Webアプリケーションが、ジョブを続行できるようにするのに十分なコンテンツを含むキューにジョブを配置することです。バックグラウンドで（理想的にはWebアプリケーションから独立して実行されている）ワーカープロセスのグループがキューからジョブを読み取り、それらを実行します。結果は、応答キューに書き戻すことも、データベースに書き込むこともできます。結果をユーザーにどのように表示するかによって異なります。Webアプリケーションの場合、データベースに結果を書き込むことは、おそらくより意味があります。
キューハンドラーによっては、ジョブを永続化することができます。たとえば、ActiveMQは永続的なメッセージングをサポートしているため、障害が発生した場合にキュー上のメッセージが回復されます。
あなたは定期的な仕事について尋ねます-そして私は答えは彼らがいつ再発する必要があるかによると思います。
ストレートメッセージキューは、メッセージが利用可能になるとすぐに、ワーカーへのメッセージを処理/解放します。したがって、スケジューリングはトリッキーまたは不可能です。スケジュールされたジョブ（特定の時間または時間の経過後に繰り返されるジョブを含む）をサポートするには、データベーステーブルを「開始時間」属性を持つ単純なキューとして使用することを検討する必要があります。
最近、ここで同様のパターンについて説明しました。