Плюсы и минусы использования Celery vs. RQ

В настоящее время я работаю над проектом python, который требует выполнения некоторых фоновых заданий (в основном для отправки электронной почты и значительных обновлений базы данных). Я использую Redis для брокера задач. Итак, в этом пункте у меня есть два кандидата: Celery и RQ. У меня был некоторый опыт работы с этими очередями заданий, но я хочу попросить вас, ребята, поделиться с вами опытом использования этих инструментов. Так.

Какие плюсы и минусы используют сельдерей против RQ.
Любые примеры проектов/задач, подходящих для использования Celery vs. RQ.

Сельдерей выглядит довольно сложно, но это полнофункциональное решение. На самом деле я не думаю, что мне нужны все эти функции. С другой стороны, RQ очень прост (например, конфигурация, интеграция), но кажется, что в нем отсутствуют некоторые полезные функции (например, аннулирование задачи, автоматическая перезагрузка кода)

Ответ 1

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

Короче говоря, RQ спроектирован таким образом, чтобы быть проще во всем. Сельдерей разработан, чтобы быть более надежным. Они оба превосходны.

Документация. Документация RQ является всеобъемлющей, не будучи сложной и отражает общую простоту проекта - вы никогда не чувствуете себя потерянным или запутанным. Документация на сельдерей также является всеобъемлющей, но ожидайте повторного посещения ее довольно часто, когда вы впервые настраиваете ситуацию, поскольку слишком много вариантов для интернализации
Мониторинг
. Цветок сельдерея и панель инструментов RQ очень просты в настройке и дать вам как минимум 90% всей информации, которую вы когда-либо хотели бы
Поддержка брокера. Сельдерей - явный победитель, RQ поддерживает только Redis. Это означает, что меньше информации о "том, что является брокером", но также означает, что вы не можете переключать брокеров в будущем, если Redis больше не работает для вас. Например, Instagram рассмотрел как Redis, так и RabbitMQ с Celery. Это важно, потому что у разных брокеров есть разные гарантии, например. Redis не может (на момент написания) гарантировать 100% доставку ваших сообщений.
Очереди приоритетов. Модель очереди приоритетов RQ проста и эффективна - рабочие читают из очередей в порядке. Сельдерей требует размножения нескольких работников, чтобы потреблять их из разных очередей. Оба подхода работают
Поддержка ОС. Сельдерей является явным победителем здесь, поскольку RQ работает только на системах, поддерживающих fork, например. Unix-системы
Поддержка языка. RQ поддерживает только Python, а Celery позволяет отправлять задания с одного языка на другой язык.
API
. Сельдерей чрезвычайно гибкий (множественные результирующие бэкэнд, хороший конфигурационный формат, поддержка холста рабочего процесса), но, естественно, эта мощность может сбить с толку. Напротив, RQ api прост.
Поддержка подзадачи. Сельдерей поддерживает подзадачи (например, создает новые задачи из существующих задач). Я не знаю, работает ли RQ
Сообщество и стабильность. Сельдерей, вероятно, более развит, но они оба являются активными проектами. С точки зрения написания, сельдерей имеет ~ 3500 звезд в Github, а RQ ~ 2000, и оба проекта показывают активное развитие

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

Итак, почему кто-то хочет торговать (возможно, более полнофункциональным) Celery для RQ? На мой взгляд, все сводится к простоте. Ограничиваясь Redis + Unix, RQ обеспечивает более простую документацию, более простую базу кода и более простой API. Это означает, что вы (и потенциальные участники проекта) можете сосредоточиться на коде, о котором вы заботитесь, вместо того, чтобы хранить информацию о системе очереди задач в вашей рабочей памяти. У всех нас есть ограничение на то, сколько деталей может быть у нас в голове сразу, и, устраняя необходимость держать детали очереди задач там, RQ позволяет вернуться к интересующему вас коду. Эта простота достигается за счет таких функций, как межязычные очереди задач, широкая поддержка ОС, надежные гарантии сообщений на 100% и возможность легко переключаться на брокеры сообщений.

Ответ 2

Сельдерей не такой уж сложный. По своей сути вы делаете пошаговую конфигурацию из tutorials, создайте экземпляр celery, украсьте свою функцию с помощью @celery.task затем запустите задачу с помощью my_task.delay(*args, **kwargs).

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