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

140

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

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

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

  • Почему я хочу настроить совершенно новую технологию для этого, например, RabbitMQ?

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

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

  • опрос, при котором база данных занята и работает с низкой производительностью
  • блокировка таблицы → снова низкая производительность
  • миллионы строк задачи → повторный опрос невысок.

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

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

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

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

  • 4
    В PostgreSQL влияние блокировок должно быть намного меньше, потому что он реализует MVCC, где читатели не блокируются писателями, и наоборот. Большинство статей, в которых я критиковал использование баз данных в качестве очередей сообщений, имеют в виду MySQL.
  • 0
    Посредник сообщений перемещает данные между узлами, а база данных хранит данные в одном месте. Тот факт, что вы можете получить доступ к данным в базе данных с нескольких узлов, сам по себе не делает его хорошим инструментом для быстрой передачи данных между узлами.
Показать ещё 3 комментария
Теги:
redis
rabbitmq
celery
message-queue

3 ответа

65
Лучший ответ

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

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

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

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

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

Что касается 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/

Поделиться
  • 2
    Я реализовал реализацию JMS (то есть систему передачи сообщений) поверх базы данных. Я могу вам сказать , что это возможно, но это не весело , и это обычно не окупаются , чтобы сделать это. Некоторые из упомянутых вами проблем можно обойти, но это значительно усложняет задачу. В общем, я согласен: используйте выделенную систему MQ, если она вам нужна. Тем не менее, для небольших рабочих нагрузок вы можете избежать этого в БД.
  • 1
    Вы просто покрыли все проблемы / сомнения. Отличный ответ!
Показать ещё 6 комментариев
51

PostgreSQL 9.5

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

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

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

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

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

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

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

Поделиться
  • 9
    линия reliably handing out entries off the top of the queue to exactly one consumer while preserving highly concurrent operation and not blocking inserts. резюмирует это - верно?
  • 1
    @YugalJindle Да.
0

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

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

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню