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


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

  1. какие плюсы и минусы использовать сельдерей против RQ.
  2. примеры проекты / задачи подходит для использования сельдерей против RQ.

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

2 63

2 ответа:

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

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

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

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

  • приоритет очереди. Приоритетная модель очереди rqs-это простой и эффективный - работники читают из очередей по порядку. Сельдерей требует раскручивания нескольких работников, чтобы потреблять из разных очередей. Оба подхода работают

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

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

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

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

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

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

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

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