Публикация / подписка надежные сообщения: Redis VS RabbitMQ
фон
Я делаю типичное приложение для публикации/подписки, где издатель отправляет сообщения потребителю.
издатель и потребитель находятся на разных компьютерах и связь между ними может иногда ломаться.
цель
цель здесь состоит в том, чтобы убедиться, что независимо от того, что происходит с подключением или с самими машинами, сообщение, отправленное издателем,всегда получил потребитель.
порядок сообщений не является обязательным.
согласно моим исследованиям, RabbitMQ является правильным выбором для этого сценария:
однако, хотя RabbitMQ имеет учебник о публикации и абонентом этот учебник не преподносит нам постоянные очереди и не упоминают подтверждает, что которые, я считаю, являются ключом к обеспечению доставки сообщений.
С другой стороны, Redis также способен сделать это:
но я не мог найти никаких официальных учебников или примеров, и мое текущее преуменьшение приводит к тому, что я считаю, что постоянные очереди и сообщения подтверждение должно быть сделано нами, поскольку Redis в основном является хранилищем данных в памяти, а не брокером сообщений, таким как RabbitMQ.
вопросы
- для этого случая использования, какое решение было бы проще всего реализовать? (Решение Redis или решение RabbitMQ?)
- пожалуйста, предоставьте ссылку на пример с тем, что вы считаете лучшим!
3 ответов
фон
Я изначально хотел опубликовать и подписаться с сохранением сообщений и очередей.
это в теории, не совсем подходит для публикации и подписки:
- этот шаблон не заботится о том, получены ли сообщения или нет. Издатель просто рассылает сообщения, и если есть какие-либо подписчики, слушающие, хорошо, иначе ему все равно.
действительно, глядя на мои потребности мне нужно больше работать очередь , или даже шаблон RPC.
анализ
люди говорят, что оба должны быть легкими, но это действительно субъективно.
RabbitMQ имеет лучшую официальную документацию в целом с четкими примерами на большинстве языков, в то время как информация Redis в основном находится в сторонних блогах и в редких репозиториях github, что значительно затрудняет ее поиск.
Что касается примеров, RabbitMQ имеет два примера, которые четко отвечают на мой вопросы:
смешивая два, я смог заставить издателя отправлять нескольким потребителям надежные сообщения-даже если один из них терпит неудачу. Сообщения не теряются и не забываются.
падение rabbitMQ:
- самая большая проблема этого подхода заключается в том, что если потребитель / работник падает, вам нужно определить логику самостоятельно, чтобы убедиться, что задачи не теряются. Это происходит потому, что после завершения задачи, следуя шаблону RPC с длительными очередями из рабочих очередей, сервер будет продолжать отправлять сообщения работнику, пока он не вернется снова. Но работник не знает, прочитал ли он уже ответ с сервера или нет, поэтому потребуется несколько ACK с сервера. Чтобы исправить это, каждое рабочее сообщение должно иметь идентификатор, который вы сохраняете на диске (в случае сбоя) или запросы должны быть идемпотентными.
- другая проблема заключается в том, что если соединение потеряно, клиенты взрываются с ошибками, поскольку они не могут подключиться. Это также то, что вы должны подготовить заранее.
что касается redis, у него есть хороший пример длительных очередей в этом блоге:
после официальной рекомендация. Вы можете проверить GitHub РЕПО для получения дополнительной информации.
падение Рэдис:
- как и с rabbitmq, вам также нужно обрабатывать рабочие сбои самостоятельно, иначе выполняемые задачи будут потеряны.
- вы должны сделать опрос. Каждый потребитель должен спрашивать производителя, есть ли какие-либо новости, каждые X секунд.
это, на мой взгляд, худший кролик.
вывод
Я в конечном итоге иду с rabbitmq для следующие причины:
- более надежная официальная онлайн-документация с примерами.
- нет необходимости для потребителей, чтобы опросить производителя.
- обработка ошибок так же просто, как в redis.
имея это в виду, для этого конкретного случая я уверен, что redis является худшим rabbitmq в этом сценарии.
надеюсь, что это помогает.
Что касается реализации, они оба должны быть простыми - у них есть библиотеки на разных языках, проверьте здесь redis и здесь в RabbitMQ. Я просто буду честен здесь: я не использую javascript, поэтому я не знаю, как реализованы или поддерживаются уважаемые библиотеки.
относительно того, что вы не нашли в учебнике (или, возможно, пропустили во втором где есть несколько слов о длительных очередях и постоянных сообщениях и признавая сообщения) есть некоторые хорошо объясненные вещи:
- о сохранении
- о подтверждает (та же ссылка, что и в вопросе, просто перечислите ее здесь для ясности)
- о надежности
издатель подтверждает, что действительно нет в учебнике, но есть пример на github в amqp.РЕПО узла.
с кроликом mq сообщение путешествует (в большинстве случаев), как это
publisher -> exchange -> queue -> consumer
и на каждой из этих остановок есть какая-то настойчивость, которая должна быть достигнута. Кроме того, если вы доберетесь до кластеров и зеркального отображения очередей, вы достигнете еще большей надежности (и доступности, конечно).
Я думаю, что они оба прост в использовании, так как есть много библиотек, разработанных для них обоих.
есть несколько имен, таких как disque, bull, kue, amqplib и т. д...
документация для них довольно хороша. Вы можете просто скопировать и вставить и запустить его за несколько минут.
Я использую seneca и seneca amqp-довольно хороший пример