Поскольку сельдерей - это очередь заданий / очередь задач, имя показывает, что он может поддерживать свои задачи и обрабатывать их. Тогда зачем ему брокер сообщений, такой как rabbitmq или redis?
вы можете объяснить распределенную очередь задач?





Celery - это Распределенная очередь задач, что означает, что система может находиться на нескольких компьютерах (контейнерах) в нескольких местах с одной централизованной шиной.
базовая архитектура выглядит следующим образом:
рабочие - процессы, которые могут принимать задания (данные) из шины (очереди задач) и обрабатывать их
* он может вернуть результат в шину для дальнейшей обработки другим работником (создать поток обработки)
автобус - очередь задач, это в основном база данных, которая хранит задания в виде сообщений, чтобы рабочие могли их получать,
Важно реализовать параллельную и неблокирующую базу данных, поэтому, когда один процесс принимает или отправляет задание с / на шину, он не мешает другим работникам получать / размещать свои рабочие места.
RabbitMQ, Redis, ActiveMQ, Kafka и другие являются лучшими кандидатами на такое поведение.
у шины есть API, который позволяет отправлять рабочие места и извлекать их (среди более сложных функций)
большинство шин реализуют функцию подтверждения / сбоя, поэтому рабочие могут подтвердить свою работу, или, если нет подтверждения (или сообщить об ошибке), это сообщение может быть снова отправлено другому рабочему, и на этот раз оно может быть успешно обработано, поэтому данные не будут потеряны. . (это сильно зависит от логики отработки отказа и контекста данных в качестве входных данных для задачи)
Celery включает scheduler (бить), который периодически помещает определенные задания в шину и, таким образом, периодически создает задачи.
давайте работать с примером утилизации, вы хотите выбросить весь мир, но Китай может разрешить трафик только из своего региона, как и Европа и США. так что вы можете построить рабочих и разместить их по всему миру
вы можете использовать только одну шину, скажем, она находится в США, все другие работники знают эту шину и могут подключиться к ней, поэтому, разместив определенную работу (лом фарфора) на автобусе, расположенном в США, процесс в Китае может работать над этим, следовательно, распределить
конечно, рабочие увеличат пропускную способность системы только за счет параллелизма, не связанного с их географическим положением, и это обычный случай использования управляемой событиями архитектуры (т.е. центральной шины, потребителей и производителей)
Я предлагаю прочитать формальный документы, это довольно просто
У меня вопрос, я не понимаю, в чем разница между очередью rabbitmq и очередью сельдерея, это одно и то же или они разные? Tnx Tom
@TomislavMikulin да и нет, сельдерей управляет очередью заданий, реализация этой очереди зависит от типа брокера, она может реализовать ее с помощью очереди rabbitmq или списка redis или даже какой-либо другой структуры данных зависит от брокера и его api
когда мы используем сельдерей в контексте rabbitmq, «очередь задач шины», как вы упомянули в своем ответе, это очередь rabbitmq или очередь сельдерея?
Автобус из кролика (очереди), сельдерей предоставляет прозрачный API-интерфейс, т.е. добавляет в очередь, берет из очереди и т. д.
согласно вашему комментарию, можем ли мы сказать, что сельдерей делает брокера сообщений универсальным? это дает возможность выбрать любого другого брокера. Верно?
@shahaf Вопрос касался Celery и RabbitMQ. Из ответа неясно, когда мы используем RabbitMQ. Я добавил RabbitMQ в ответ. Пожалуйста, дайте мне знать, правильно это или нет.
Очередь задач распределен