Почему нам нужны брокеры сообщений, такие как RabbitMQ, из базы данных, например PostgreSQL?

Я новичок в таких брокерах сообщений, как RabbitMQ, которые мы можем использовать для создания задач/очередей сообщений для системы планирования, такой как Celery.

Теперь вот вопрос:

Я могу создать таблицу в PostgreSQL, к которой можно добавлять новые задачи и использовать такую потребительскую программу, как Celery.
С какой стати я хочу установить для этого совершенно новую технологию, такую как RabbitMQ?

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

Я погуглил, какие проблемы создает база данных для конкретной проблемы, и обнаружил:

опрос поддерживает занятость базы данных и низкую производительность
блокировка стола → опять низкая производительность
миллионы строк заданий → опять же, опрос неэффективен

Теперь, как RabbitMQ или любой другой подобный брокер сообщений решает эти проблемы?

Кроме того, я узнал, что протокол AMQP это то, что он следует. Что в этом хорошего?

Можно ли использовать Redis в качестве брокера сообщений? Я нахожу его более похожим на Memcached, чем на RabbitMQ.

Пожалуйста, пролите немного света на это!

Ответ 1

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

Что касается упомянутых вами проблем:

Опрос с сохранением базы данных и низкой производительностью. Используя Rabbitmq, производители могут отправлять обновления потребителям, что гораздо эффективнее, чем опрос. Данные просто отправляются потребителю, когда это необходимо, устраняя необходимость в расточительных проверках.
блокировка таблицы → опять низкая производительность: Нет таблицы для блокировки: P
миллионы строк задачи → опять-таки опрос неэффективен: Как упоминалось выше, Rabbitmq будет работать быстрее, поскольку он находится в оперативной памяти и обеспечивает управление потоком. При необходимости он также может использовать диск для временного хранения сообщений, если у него заканчивается ОЗУ. После 2.0 Rabbit значительно улучшил использование ОЗУ. Также доступны варианты кластеризации.

Что касается AMQP, я бы сказал, что действительно крутой функцией является "обмен" и возможность его перенаправления на другие обмены. Это дает вам больше гибкости и позволяет создавать широкий спектр сложных типологий маршрутизации, которые могут оказаться очень полезными при масштабировании. Хороший пример см.:

_{(источник: springsource.com)}

и: http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

Наконец, что касается redis, то да, его можно использовать как брокер сообщений, и он может преуспеть. Однако Rabbitmq имеет больше возможностей очереди сообщений, чем redis, поскольку rabbitmq изначально создавался как полнофункциональная выделенная очередь сообщений корпоративного уровня. Redis, с другой стороны, был изначально создан, чтобы быть хранилищем ключей в памяти (хотя он делает гораздо больше, чем сейчас; его даже называют швейцарским армейским ножом). Тем не менее, я читал/слышал, что многие люди добились хороших результатов с Redis для проектов меньшего размера, но мало что слышали об этом в более крупных приложениях.

Вот пример использования redis в реализации длинного опроса чата: http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/

Ответ 2

PostgreSQL 9.5

PostgreSQL 9.5 включает SELECT ... FOR UPDATE ... SKIP LOCKED. Это упрощает и упрощает внедрение рабочих систем очередей. Вы можете больше не требовать внешнюю систему очередей, так как теперь просто получить строки "n", которые не заблокировали ни один другой сеанс, и заблокировать их, пока вы не подтвердите, что работа выполнена. Он даже работает с двухфазными транзакциями, когда требуется внешняя координация.

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

Старые версии

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

Вот почему существуют такие инструменты, как PGQ.

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

Если вам не нужны высокоуровневые выборки для нескольких рабочих групп, то использование единой таблицы очередей в PostgreSQL вполне разумно.

Ответ 3

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

И я думаю, что в разработке нет лучшего решения [брокера сообщений], но в конкретное время всегда существует наиболее подходящее решение для конкретного бизнес-приложения.