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

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

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

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

С какой стати я хочу установить для этого совершенно новую технологию, такую как RabbitMQ?

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

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

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

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

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

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

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

 Md. Sajedul Karim17 июл. 2018 г., 11:40
Вы можете посмотреть ниже ссылку. Имеет широкое описание:stackoverflow.com/a/51377756/3073945
 theMayer16 июн. 2016 г., 17:35
Посредник сообщений перемещает данные между узлами, а база данных хранит данные в одном месте. Тот факт, что вы можете получить доступ к данным в базе данных с нескольких узлов, сам по себе не делает его хорошим инструментом для быстрой передачи данных между узлами.
 giorgi dvalishvili20 февр. 2018 г., 13:55
с помощью посредника сообщений производитель и потребитель разъединены.
 Mark K Cowan15 авг. 2016 г., 10:11
«Система планирования, какcelery«- Я только что узнал кое-что, что будет полезно в моем дизайне, извопрос, Теперь, чтобы прочитать ответы ...
 CadentOrange14 янв. 2014 г., 15:02
В PostgreSQL влияние блокировок должно быть намного меньше, потому что он реализует MVCC, где читатели не блокируются писателями, и наоборот. Большинство статей, в которых я критиковал использование баз данных в качестве очередей сообщений, имеют в виду MySQL.

Ответы на вопрос(2)

PostgreSQL 9.5

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

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

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

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

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

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

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

 Craig Ringer22 окт. 2012 г., 13:59
@YugalJindle Да.
 Yugal Jindle22 окт. 2012 г., 13:51
линияreliably handing out entries off the top of the queue to exactly one consumer while preserving highly concurrent operation and not blocking inserts. резюмирует это - верно?
Решение Вопроса

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

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

опрос, сохраняющий базу данных буйной и низкой производительности: Используя Rabbitmq, производители могутОт себя обновления для потребителей, которые гораздо более производительны, чем опрос. Данные просто отправляются потребителю, когда это необходимо, устраняя необходимость в расточительных проверках.

блокировка стола -> опять низкая производительность: Нет таблицы для блокировки: P

миллионы строк задачи -> опять опрос выполняется мало: Как упомянуто выше, Rabbitmq будет работать быстрее, поскольку он находится в оперативной памяти и обеспечивает управление потоком. При необходимости он также может использовать диск для временного хранения сообщений, если у него заканчивается ОЗУ. После 2.0 Rabbit значительно улучшил использование ОЗУ. Варианты кластеризации также доступны.

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

http://blog.springsource.com/wp-content/uploads/2011/04/routing-topology.png

а также: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/

 Mahn22 окт. 2012 г., 16:24
Это интересно. Как насчет последовательности между прочим? Что делать, если в очереди находятся сотни заданий, а узел, удерживающий их в баране, дает сбой?
 Joe16 сент. 2013 г., 21:30
Как и то, что сказал @jkj, есть NOTIFY и нет блокировок таблиц. Единственная проблема - высокая пропускная способность сообщений. Не могли бы вы иметь выделенный экземпляр PostgreSQL вместо поддержки совершенно новой системы, такой как Rabbit? Вы можете 1) использовать один экземпляр PostgreSQL, пока не достигнете узкого места, затем 2) использовать выделенный Postgres, затем, наконец, 3) легко переключиться на Rabbit в качестве вашего брокера. Похоже, начинать с Кролика предварительно оптимизировать.
 jkj29 окт. 2012 г., 19:06
На самом деле, в PostgreSQL нет опроса (см. NOTIFY) и нет блокировки таблиц (см. MVCC). Хотя PostgreSQL по-прежнему не предназначен для организации очередей сообщений, он не является полностью неподходящим.
 Yugal Jindle22 окт. 2012 г., 13:54
Вы просто покрыли все проблемы / сомнения. Отличный ответ!
 Joachim Sauer22 окт. 2012 г., 09:23
Я реализовал реализацию JMS (то есть систему передачи сообщений) поверх базы данных. Я могу сказать вам, что этоявляется возможно, но это не весело, и обычно это не окупается. Некоторые из упомянутых вами проблем можно обойти, но это значительно усложняет задачу. В общем, я согласен: используйте выделенную систему MQ, если она вам нужна. Тем не менее, для небольших рабочих нагрузок вы можете избежать этого в БД.

Ваш ответ на вопрос