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

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

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

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

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

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

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

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

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

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

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

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

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

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

• опрос по поддержанию базы данных Buzy и низкие исполнительский : Использование 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/

PostgreSQL 9.5

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

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

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

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

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

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

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