Как обеспечить отказоустойчивость воркера, обрабатывающего задачи?

Что проверяют

Понимаете ли вы, что воркер обязательно будет падать, и знаете ли, как сделать так, чтобы задача при этом не потерялась и не выполнилась дважды с последствиями. Следом обычно спрашивают про идемпотентность и про задачу, которая падает всегда.

Как отвечать

Сильный ответ строится вокруг доставки «хотя бы один раз» и того, как с ней жить. На примере Celery:

• подтверждение после обработки: по умолчанию Celery подтверждает задачу перед выполнением. task_acks_late=True вместе с task_reject_on_worker_lost=True вернут её в очередь, если процесс умер посреди работы;
• prefetch: worker_prefetch_multiplier=1 для долгих задач, чтобы упавший воркер не держал пачку задач, которые могли бы взять другие;
• идемпотентность: раз задача может прийти повторно, обработчик должен это переживать. Ключ идемпотентности, уникальный индекс, INSERT ... ON CONFLICT DO NOTHING, проверка статуса перед побочным эффектом;
• ретраи: autoretry_for только для временных ошибок (сеть, 503, таймаут), retry_backoff=True с джиттером и лимит max_retries. Ошибки валидации повторять бессмысленно;
• dead letter: после исчерпания попыток задача уходит в отдельную очередь, в RabbitMQ через x-dead-letter-exchange, и на её размер ставится алерт;
• таймауты и память: soft_time_limit и time_limit против зависаний, worker_max_tasks_per_child против утечек;
• корректная остановка: на SIGTERM воркер перестаёт брать новые задачи и доделывает текущие. В Kubernetes на это отведено terminationGracePeriodSeconds, по умолчанию 30 секунд.

Если задача создаётся вместе с записью в базе, упомяните transactional outbox, иначе можно закоммитить заказ и потерять задачу на его обработку. Мониторинг: длина очереди, возраст самой старой задачи, доля ошибок, размер DLQ.

Где спотыкаются

Включают acks_late и забывают про идемпотентность. Письмо уходит дважды, платёж проводится повторно.

Ретраят любые исключения без лимита. «Отравленная» задача крутится бесконечно и занимает воркеры.

Проверяют только, что процесс жив. Воркер, зависший на сетевом вызове без таймаута, выглядит здоровым, а очередь растёт.