Тайм-аут сельдерея в Django - PullRequest
1 голос
/ 13 января 2020

В разные периоды в сельдерее выполняется восемь задач. Все они - управляемые событиями задачи. После определенного события их уволили. И конкретная задача работает непрерывно, пока не будут выполнены определенные условия.

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

Подпись задачи выглядит следующим образом:

tasks.py

import time
from celery import shared_task

@shared_task()
def some_celery_task(a, b):
    main_time_end = time.time() + 120
    while time.time() < main_time_end:
        ...
        # some db operations here with given function arguments 'a' and 'b' 
        # this part of the task get execute most of the time

    if time.time() > main_time_end:
        ...
        # some db operations here.
        # this part is the part of the task that doesn't get executed sometimes

views.py

# the other part of the view not mentioned here
# only the task invoked part 
some_celery_task.apply_async(args=(5, 9), countdown=0)

Я запутался в сценарии ожидания задания сельдерея ios. Означает ли это, что задание остановится с того места, где оно истекло, или будет повторяться автоматически? Будет очень полезно, если у вас есть какие-либо четкие представления о времени ожидания и повторных попытках, которые вы, ребята, получили.
В чем может быть причина описанного сценария ios выше? Любая помощь по этому вопросу будет высоко оценена. Спасибо.

1 Ответ

2 голосов
/ 14 января 2020

Проверка Документация Celery о задачах - основы задокументированы очень хорошо.


Если задача не выполнена или была прервана - задача будет иметь статус states.FAILURE. Он не будет перепробован, если не будет специально закодирован. Если регистрация настроена правильно - вы можете увидеть сообщения об исключениях в журналах в случае тайм-аутов или других исключений кода.


Когда задача сельдерея TIME_LIMIT превышена - задача сразу же прекращается:

Рабочий, обрабатывающий задачу, будет убит и заменен новым.

Также с сообщением будет вызвано исключение TimeLimitExceeded например, Task handler raised error: "TimeLimitExceeded(2700)"


Если установлен Celery SOFT_TIME_LIMIT , он меньше TIME_LIMIT и превышен - чем SoftTimeLimitExceeded, будет сгенерировано исключение, позволяющее его нужно отловить в задаче и выполнить действия по очистке.


Когда работник получает сообщение (задача) из очереди посредника - брокеру необходимо знать, что сообщение было успешно использовано. Для подтверждения успешного использования сообщения работник подтверждает (ACK) брокеру . До тех пор, пока сообщение не будет подтверждено, оно не будет удалено из брокера, но также недоступно для использования («невидимо»). При отсутствии подтверждения - сообщение будет повторно доставлено обратно в очередь брокера, снова доступную для потребления.

Реабилитация сообщений о неподтвержденных сообщениях c зависит от брокера:

  • Брокер AMQP (RabbitMQ) - отслеживает состояние соединения с работником, а в случае потери соединения - возвращает сообщение обратно в очередь.

  • Брокер Redis или SQS имеет собственный тайм-аут после чего сообщение будет повторно доставлено в очередь посредника, если не ACKed.


По умолчанию работник сельдерея подтверждает сообщение прямо в начале задачи.

Если установлено значение ACKS_LATE - работник признается брокеру только после успешного выполнения задания.


Можно RETRY задача, перехватывая исключение в задаче и отправляя ту же задачу обратно в брокер для повторного выполнения - тогда эта же задача с тем же идентификатором будет поставлена ​​в очередь в брокере. Обратный отсчет * Опция 1076 * позволяет указать задержку перед повторной попыткой выполнения задачи.


Можно выполнить выполнение задачи Celery и другие параметры глобально в settings.py или для задачи в качестве аргументов .


Рекомендуемый способ разработки задач / logi c с учетом того, что такие события должны быть полностью git, и смотрите они нормальные (но на самом деле не ожидаются) когда-нибудь произойдут и будут готовы:

  • задачи могут завершиться ошибкой ( следующая та же задача может выполнить обе задачи или проверки, которые указывают c работа не была выполнена и перезапустить задачу )
  • та же задача может быть запущена снова ( идемпотентность )
  • аналогичные задачи могут выполняться одновременно ( блокировка )
...