основа в этих статьях
собственно основа всего
https://docs.celeryq.dev/en/latest/django/first-steps-with-django.html#using-celery-with-django
вариации
https://www.codingforentrepreneurs.com/blog/celery-redis-django/
https://medium.com/@abheist/django-celery-redis-and-flower-9b5a4d876870
https://www.codingforentrepreneurs.com/blog/celery-redis-django/
https://blog.codeparrot.ai/how-we-scaled-celery-for-our-django-app-da2465a3a6be
https://www.merixstudio.com/blog/boost-your-django-project-celery
https://tproger.ru/articles/ispolzovanie-django-celery-beat-dlja-sozdanija-periodicheskih-zadach-v-django-proektah
https://django-celery-beat.readthedocs.io/en/latest/
использование Celery с Django состоит из следующих шагов:
1) определение брокера сообщений для Celery
2) выполнение магии в Django для связывания его с Celery
3) написание хотя бы одного таска, который будет выполнять воркер
4) запуск Celery
необязательные, но в нашем случае будут выполнены еще шаги:
5) Celery beat - мы используем батарейку django_celery_beat но можно и просто настроить в конфиге
6)батарейка django_celery_results - очень полезна и при отладке и вообще
7) настройка Flower (это необязательно если речь не идет о production сервере)
итак
брокер сообщений для Celery
будем использовать Redis. Он быстр и прост.
в статьях вы можете встретить варианты: RabbitMQ или база данных (Postgresql например) - и то и то применимо, но - не лучшее решение. В принципе, если вам лень ставить Redis а база уже стоит - можете попробовать ее, минусы такого решение - лишнее дерганье базы: сообщение Celery сначала будут добавляться, а затем удаляться из нее, при чем это известно заранее - и удаляться добавляьться бьыстро -практически в тот же час а то и ту же минуту, дергать базу для такого бессмысленно.База - это прежде всегно для хранения. Помогла бы какая-нибудь in memory таблица, но, увы, Postgre/Mysql/MAriaDB это не Clickhouse / Aerospike и особо таких таблиц не поддерживают, есть вариант создания RAM диска и tablespace в нем - но ни о каком динамическом управлении отжираемой памятью речи не идет. Короче - так себе идея.
С RabbitMQ похожая картина, но причины другие: вы могли слышать что это, собственно, сам брокер сообщений, по сути он самостоятельно может быть альтернативой Celery и по функционалу с непрвычки захочется использовать его. Не нужно, минусы такие: RabbitMQ - это еще один сервис/демон, со своими закидонами: например, ограничена длина сообщения, он может скрешиться и не всегда восстановить имющиеся необработанные до креша сообщения, ну и - его сложно отлаживать - в Redis вы всегда сможете заглянуть (не то чтобы оно вам сильно поможет, но все же), а в RabbitMQ ?
Почему же его пишут в документации ? Его используют, когда проект становится большим. Причина проста - в него можно отправлять и читать по сети ( ну в Редис тоже можно, но это уже будет не то), и когда проект большой - есть кому смотреть и за Celery и за поведением Rabbitа.
Итоговый выбор за вами, но мы в статье используем настройке именно для Redis
Комментарии
Отправить комментарий