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

101

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

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

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

Макс Каменков
источник
3
К сожалению, подобный вопрос не подходит под формат этого сайта, см. FAQ . Подобные вопросы, как правило, приводят к расплывчатым ответам, которые также очень быстро устаревают. Если мы можем помочь вам с конкретной проблемой, не стесняйтесь задавать еще один вопрос!
Мартейн Питерс
Кстати, мне кажется, что вы можете отзывать задачи даже с помощью rq-dashboard
Питер Кильчук

Ответы:

141

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

Короче говоря, 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% надежные гарантии сообщений и возможность легко переключать брокеров сообщений.

Хэми
источник
1
Subtask support. Celery supports subtasks (e.g. creating new tasks from within existing tasks). I don't know if RQ does На 24.05.2019 RQ также поддерживает подзадачи (внутренний вызов очереди).
eserdk
1

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

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

Джесси Игра
источник
47
Совершенно не согласен с вашей оценкой. Пару недель я изо всех сил пытался заставить Celery успешно работать на моем сервере Debian, даже после прочтения большей части документации и многочисленных сообщений в блогах. Основная проблема, с которой я столкнулся, заключалась в том, что если у вас что-то не так в конфигурации, Celery не предоставит никаких отзывов о том, в чем может быть проблема. И когда я наконец заработал, я начал получать OSError типа os OSError глубоко в стеке Celery. Я опубликовал проблему на Github, но никто не мог помочь. Я бы больше не трогал сельдерей десятифутовым шестом.
Ray
2
Эффин О.С. Ошибочный человек. No such file or directory. Понятия не имею, с чего начать. Сегодня вечером я впервые попробую RQ.
MiniGunnR