Плюсы и минусы использования сельдерея против RQ [закрыто]

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

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

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

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

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

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

• Мониторинг. Цветок сельдерея и панель управления RQ очень просты в настройке и предоставляют вам не менее 90% всей информации, которую вы когда-либо хотели.

• Брокерская поддержка. Celery - явный победитель, RQ поддерживает только Redis. Это означает меньше документации о том, «что такое брокер», но также означает, что вы не сможете менять брокера в будущем, если Redis больше не работает для вас. Например, Instagram рассматривал и Redis, и RabbitMQ с Celery . Это важно, потому что разные брокеры имеют разные гарантии, например, Redis не может (на момент написания) гарантировать 100% доставку ваших сообщений.

• Приоритетные очереди. Модель очереди приоритетов RQ проста и эффективна - рабочие читают из очередей по порядку . Для использования сельдерея требуется несколько рабочих процессов из разных очередей. Оба подхода работают

• Поддержка ОС. Здесь явным победителем является сельдерей, поскольку RQ работает только в системах, поддерживающих, forkнапример, системы Unix.

• Языковая поддержка. RQ поддерживает только Python, тогда как Celery позволяет отправлять задачи с одного языка на другой.

• API. Celery чрезвычайно гибок (несколько бэкэндов результатов, хороший формат конфигурации, поддержка холста рабочего процесса), но, естественно, эта сила может сбивать с толку. Напротив, RQ api прост.

• Поддержка подзадач. Celery поддерживает подзадачи (например, создание новых задач из существующих). Я не знаю, есть ли у RQ

• Сообщество и стабильность. Celery, вероятно, более устоявшийся, но оба они являются активными проектами. На момент написания у Celery ~ 3500 звезд на Github, а у RQ ~ 2000, и оба проекта активно развиваются.

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

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

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

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