Я работал над тем, чтобы некоторые распределенные задачи работали через RabbitMQ.
Я потратил некоторое время, пытаясь заставить Celery делать то, что я хотел, и не мог заставить его работать.
Затем я попытался использовать Pika, и все заработало, безупречно и в считанные минуты.
Что я упускаю, используя Pika вместо Celery?
Пика дает лишь небольшую часть того, что делает сельдерей. Pika - это библиотека Python для взаимодействия с RabbitMQ. RabbitMQ - брокер сообщений; по своей сути, он просто отправляет сообщения в / получает сообщения из очередей. Его можно использовать как очередь задач, но также можно просто использовать для передачи сообщений между процессами без фактического распределения «работы».
Celery реализует распределенную очередь задач, при необходимости используя RabbitMQ в качестве брокера для IPC. Вместо того, чтобы просто предоставлять способ отправки сообщений между процессами, он предоставляет систему для распределения фактических задач / заданий между процессами. Вот как это описано на сайте Celery:
Очереди задач используются как механизм для распределения работы по потокам или машинам.
Входные данные очереди задач - это единица работы, называемая задачей, выделенные рабочие процессы затем постоянно контролируют очередь на предмет выполнения новой работы.
Сельдерей общается через сообщения, обычно используя брокера для посредничества между клиентами и работниками. Чтобы инициировать задачу, клиент помещает сообщение в очередь, а затем брокер доставляет сообщение работнику.
Система Celery может состоять из нескольких рабочих и брокеров, уступая место высокой доступности и горизонтальному масштабированию.
В Celery есть целый набор встроенных функций, выходящих за рамки pika. Вы можете ознакомиться с документами по сельдерею, чтобы получить представление о том, что он может делать, но вот пример:
>>> 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 и распределяет каждый блок по такому количеству рабочих Celery, сколько есть доступных. Каждый рабочий будет запускать add на своем блоке из 10 элементов, пока вся работа не будет завершена. Затем результаты собираются с помощью вызова res.get(). Я уверен, что вы можете представить, как это сделать с помощью pika, но я уверен, что вы также можете представить, сколько работы потребуется. Вы получаете эту функциональность прямо из коробки с помощью Celery.
Вы, безусловно, можете использовать pika для реализации распределенной очереди задач, если хотите, особенно если у вас довольно простой вариант использования. Celery просто предоставляет решение с «включенными батареями» для планирования задач, управления и т. Д., Которое вам придется реализовать вручную, если вы решите, что они вам нужны с вашим решением pika.
Я собираюсь добавить здесь ответ, потому что сегодня уже второй раз, когда кто-то порекомендовал сельдерей, когда он не нужен, основываясь на этом ответе, как я подозреваю. Таким образом, разница между распределенной очередью задач и брокером заключается в том, что брокер просто передает сообщения. Ни больше ни меньше. Celery рекомендует использовать RabbitMQ в качестве брокера по умолчанию для IPC и размещает поверх этих адаптеров для управления задачами / очередями с процессами демонов. Хотя это особенно полезно для распределенных задач, где вам очень быстро нужно что-то общее. Это просто конструкция для процесса издатель / потребитель. Фактические задачи, в которых вы определили рабочий процесс, который необходимо выполнить, и обеспечить долговечность сообщений в соответствии с вашими конкретными потребностями. Лучше написать собственному издателю / потребителю, чем полагаться на сельдерей. Очевидно, вам все равно придется выполнять всю проверку устойчивости и т. Д. В большинстве веб-сервисов никто не контролирует фактические «рабочие» единицы, а, скорее, передает их сервису. Таким образом, это не имеет смысла для очереди распределенных задач, если вы не достигнете некоторого произвольного лимита вызовов API, основанного на ip / географическом регионе или номере учетной записи ... Или что-то в этом роде. Таким образом, использование сельдерея не мешает вам писать или иметь дело с кодом состояния или управлением рабочим процессом и т. Д., А также предоставляет AMQP таким образом, чтобы вам было проще избежать написания конструкций кода издателя / потребителя.
Короче говоря, если вам нужна простая очередь задач, чтобы разобраться в работе, и вас на самом деле не беспокоят нюансы производительности, сложности, связанные с надежностью вашего рабочего процесса, или фактические процессы публикации / использования. Сельдерей работает. Если вы просто передаете сообщения API или службе, которую фактически не контролируете, конечно, вы можете использовать Celery, но вы можете так же легко создать своего собственного издателя / потребителя с помощью Pika за пару минут. Если вам нужно что-то надежное или соответствующее вашим собственным сценариям устойчивости, напишите свой собственный код публикации / потребителя, как и все остальные.
