タスクライフサイクル
非同期タスクは、そのライフサイクル中に複数のステートを経ることがあります。このページでは、タスクの作成から削除までのライフサイクルを記録します。
タスクをエンキューすると、asynqはそのタスクを内部で管理し、指定された時間にハンドラーが呼び出されるようにします。このプロセス中に、タスクはさまざまなライフサイクルのステートを経ることがあります。
以下は、異なるライフサイクルのステートのリストです。
-
Scheduled: タスクは将来の処理を待っています（
ProcessAtやProcessInオプションを持つタスクにのみ適用）。 - Pending: タスクは処理の準備ができており、アイドル状態のワーカーによって処理されます。
- Active: タスクはワーカーによって処理されています（つまり、ハンドラーがタスクを処理しています）。
- Retry: ワーカーはタスクを処理できず、タスクは将来のリトライを待っています。
- Archived: タスクは最大のリトライ試行回数に達し、手動での検査のためにアーカイブされています。
-
Completed: タスクは正常に処理され、保持期間が切れるまで保持されます（
Retentionオプションを持つタスクにのみ適用）。
それでは、例を使って異なるライフサイクルのステートを見てみましょう。
// タスク 1: 24時間後に処理するようにスケジュールされています。
client.Enqueue(task1, asynq.ProcessIn(24*time.Hour))
// タスク 2: 即時処理のためにエンキューされています。
client.Enqueue(task2)
// タスク 3: 保持オプション付きでエンキューされています。
client.Enqueue(task3, asynq.Retention(2*time.Hour))
この例では、タスク 1 は次の24時間 Scheduled ステートにとどまります。24時間後、Pending ステートに移行し、次に Active ステートに移行します。タスクが正常に処理された場合、タスクデータはRedisから削除されます。タスクが正常に処理されない場合（つまり、ハンドラーがエラーを返したりパニックになった場合）、タスクは後でのリトライのために Retry ステートに移行します。一定の時間の後、タスクはPending ステートに戻り、次に Active ステートに移行します。このサイクルは、タスクが正常に処理されるか、リトライ試行を使い切るまで続きます。後者の場合、タスクは Archived ステートに移行します。
この例では、タスク 2 と タスク 1 の唯一の違いは、タスク 2 が Scheduled ステートをスキップして直接 Pending ステートに入ることです。
タスク 3 は2時間の保持オプションでエンキューされています。これは、ワーカーが タスク 3 を正常に処理した後、タスクがキューから削除されるまで Completed ステートにとどまることを意味します。デフォルトでは、タスクに保持オプションが設定されていない場合、タスクは処理後すぐにキューから削除されます。
以下の図は、ステートの遷移を示しています。
+-------------+ +--------------+ +--------------+ +-------------+
| | | | | | 成功 | |
| Scheduled |----------->| Pending |--------->| Active |---------> | Completed |
| (Optional) | | | | | | (Optional) |
+-------------+ +--------------+ +--------------+ +-------------+
^ | |
| | | 削除
| | 失敗 |
| | V
| |
| |
+------+-------+ | +--------------+
| | | | |
| Retry |<--------------+------->| Archived |
| | | |
+--------------+ +--------------+