작업 라이프사이클
비동기 작업은 그들의 라이프사이클 동안 여러 상태를 거칩니다. 이 페이지는 작업이 생성되고 삭제될 때까지의 작업 라이프사이클을 기록합니다.
작업을 큐에 넣을 때 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시간 동안 스케줄됨 상태에 머무를 것입니다. 24시간 후에 대기 중 상태로 전환되고 그 후 활성 상태로 전환될 것입니다. 작업이 성공적으로 처리되면 작업 데이터가 Redis에서 삭제될 것입니다. 작업이 성공적으로 처리되지 않으면(즉, 핸들러가 오류를 반환하거나 패닐할 경우), 작업은 장래 재시도를 위해 재시도 상태로 전환될 것입니다. 일정한 시간이 지나면 작업은 대기 중 상태로 다시 전환되고 그 후 활성 상태로 전환될 것입니다. 이 주기는 작업이 성공적으로 처리되거나 재시도 횟수가 고갈될 때까지 계속될 것입니다. 후자의 경우 작업은 보관됨 상태로 전환될 것입니다.
이 예제에서 작업 2와 작업 1간의 유일한 차이점은 작업 2가 스케줄됨 상태를 건너뛰고 바로 대기 중 상태로 들어간다는 것입니다.
작업 3은 2시간의 보관 옵션과 함께 큐에 넣었습니다. 즉, 워커가 작업 3을 성공적으로 처리한 후 작업은 큐에서 제거되기 전 완료 상태에 2시간 동안 유지될 것입니다. 기본적으로 보관 옵션이 설정되지 않은 경우 작업은 완료된 직후에 즉시 큐에서 제거될 것입니다.
다음 다이어그램은 상태 전이를 설명합니다.
+-------------+ +--------------+ +--------------+ +-------------+
| | | | | | 성공 | |
| 스케줄됨 |----------->| 대기 중 |--------->| 활성 |---------> | 완료 |
| (선택 사항) | | | | | | (선택 사항) |
+-------------+ +--------------+ +--------------+ +-------------+
^ | |
| | | 삭제
| | 실패 |
| | V
| |
| |
+------+-------+ | +--------------+
| | | | |
| 재시도 |<--------------+------->| 보관됨 |
| | | |
+--------------+ +--------------+