Как стать автором
Обновить

Комментарии 2

В целом все верно, хотел что-нибудь поправить, но даже не нашёл к чему придраться.

Вообще говоря, если недоступен брокер - то это уже само по себе форс-мажор. 100 раз делать retry - уже перебор, наверное..

Ещё хочется добавить про транзакции - если вы вызываете таску внутри транзакции, а завершаете её уже потом - то есть очень ненулевой шанс, что celery-таска начнётся в новой транзакции и не увидит ваши изменения. Например, добавляем новый объект и вызываем таску для заполнения его свойств - если она быстро начнётся, то не увидит объект вообще. Для этого даже иногда приходится ставить что-то типа countdown=3.

Что касается retry самой таски - если у неё стоит ignore_result=True (а оно часто ставится), то, насколько я помню, retry может и не сработать, поскольку мастер-процесс не знает результат.

Что касается результатов - лучший engine для этого - Redis. Упаси вас Нортон использовать для этого базу данных - с транзакциями запутаетесь и лишние висящие подключения вам не нужны.

Для транспорта многие не рекомендуют использовать Redis и считается, что на продакшене нужно использовать только RabbitMQ. На мой взгляд, Redis тоже справляется неплохо и особых проблем с ним у меня не было. Однако, если много воркеров - то лучше RabbitMQ.

В старых версиях celery очень не любил, если вы внутри тасков запускали потоки (Threads), потому что движок библиотеки billiard иногда форкался и все треды вели себя непредсказуемо. В последних версиях они, кажется, перешли на multiprocessing, но с тредами всё равно надо поосторожнее.

Спасибо! Интересное замечание с отправкой таски в транзакции и что созданный объект может быть не найдет. Как еще один аргумент, что этого нужно избегать и как я упоминал transaction.on_commit поможет решить эту проблему.

А retry все равно отработает даже при ignore_result=True, потому что это реализовано через возврат сообщения в очередь, не через отсллеживание результата.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации