RabbitMQ: Что предлагает сельдерей, что Пика не делает?

Ответ 1

То, что предлагает pika, - это всего лишь небольшая часть того, что делает Сельдерей. Pika - это библиотека Python для взаимодействия с RabbitMQ. RabbitMQ является брокером сообщений; по сути, он просто отправляет сообщения в/принимает сообщения из очередей. Он может использоваться как очередь задач, но его также можно использовать для передачи сообщений между процессами, без фактического распределения "работы".

Сельдерей реализует распределенную очередь задач, опционально используя RabbitMQ в качестве брокера для IPC. Вместо того, чтобы просто предоставлять способ отправки сообщений между процессами, он предоставляет систему для распределения фактических задач/заданий между процессами. Вот как это описывает сайт сельдерея:

Очереди задач используются как механизм для распределения работы по потокам или машинам.

Вход в очереди задач - это единица работы, называемая задачей, выделенные рабочие процессы, а затем постоянно контролирует очередь для выполнения новой работы.

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

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

Сельдерей имеет целую кучу функциональности, которая находится вне области pika. Вы можете взглянуть на документы Celery, чтобы получить представление о том, что он может сделать, но вот пример:

>>> from proj.tasks import add

>>> res = add.chunks(zip(range(100), range(100)), 10)()
>>> res.get()
[[0, 2, 4, 6, 8, 10, 12, 14, 16, 18],
 [20, 22, 24, 26, 28, 30, 32, 34, 36, 38],
 [40, 42, 44, 46, 48, 50, 52, 54, 56, 58],
 [60, 62, 64, 66, 68, 70, 72, 74, 76, 78],
 [80, 82, 84, 86, 88, 90, 92, 94, 96, 98],
 [100, 102, 104, 106, 108, 110, 112, 114, 116, 118],
 [120, 122, 124, 126, 128, 130, 132, 134, 136, 138],
 [140, 142, 144, 146, 148, 150, 152, 154, 156, 158],
 [160, 162, 164, 166, 168, 170, 172, 174, 176, 178],
 [180, 182, 184, 186, 188, 190, 192, 194, 196, 198]]

Этот код хочет добавить каждый x + y, где x находится в range(0, 100) а y находится в range(0,100). Он делает это, выполняя задачу с именем add, которая добавляет два числа и распределяет работу по добавлению 1+1, 2+2, 3+3 и т.д. В куски 10 и распределяет каждый кусочек как можно большему числу работников сельдерея есть. Каждый рабочий будет запускать add на свой 10-элементный блок, пока все работы не будут завершены. Затем результаты собираются res.get(). Я уверен, что вы можете представить себе способ сделать это с помощью pika, но я уверен, вы также можете себе представить, сколько потребуется работы. Вы получаете эту функциональность из коробки с Сельдерей.

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

Ответ 2

Я собираюсь добавить ответ здесь, потому что это второй раз, когда сегодня кто-то рекомендовал сельдерей, когда он не нужен на основании этого ответа, которого я подозреваю. Таким образом, разница между распределенной задачей и брокером заключается в том, что брокер просто передает сообщения. Ни больше ни меньше. Сельдерей рекомендует использовать RabbitMQ в качестве брокера по умолчанию для IPC и размещать поверх этих адаптеров для управления задачами/очередями с процессами демона. Хотя это особенно полезно для распределенных задач, где вам нужно что-то общее очень быстро. Его просто построить для издателя/потребительского процесса. Фактические задачи, в которых вы определили рабочий процесс, который вам необходимо выполнить, и обеспечить долговечность сообщений на основе ваших конкретных потребностей, вам лучше писать собственный издатель/потребитель, чем полагаться на сельдерей. Очевидно, вам все равно придется выполнять все проверки долговечности и т.д. С большинством веб-сервисов, которые не контролируют фактические "рабочие" единицы, а скорее передают их на службу. Таким образом, для очереди распределенных задач мало смысла, если вы не нажмете какой-либо произвольный лимит вызовов API на основе ip/географического региона или номера учетной записи... Или что-то в этом направлении. Таким образом, использование сельдерея не мешает вам писать или обрабатывать код состояния или управление рабочим процессом и т.д., И он предоставляет AMQP таким образом, чтобы вам было легче избегать написания конструкций кода издателя/потребителя.

Короче говоря, если вам нужна простая очередь задач, чтобы пережевывать работу, и вы действительно обеспокоены нюансами производительности, сложностями долговечности через ваш рабочий процесс или фактическими процессами публикации/потребления. Сельдерей работает. Если вы просто передаете сообщения на api или службу, на которой вы фактически не контролируете, вы можете использовать Celery, но вы могли бы так же легко взломать своего собственного издателя/потребителя Pika за пару минут. Если вам нужно что-то надежное или придерживается ваших собственных сценариев долговечности, напишите свой собственный код публикации/потребителя, как и все остальные.