Достижение шаблонов обмена сообщениями JMS/AMQP с использованием Redis

Этот вопрос возникает, когда я сталкивался с некоторыми упоминаниями (например, this) об использовании программного обеспечения для обмена сообщениями, такого как ZeroMQ наряду с Redis, но я все время слышу о том, что сам Редис использовал систему обмена сообщениями. Итак, если Redis используется вместе с другими системами обмена сообщениями, значит ли это, что у Redis есть серьезные недостатки, когда они используются как система обмена сообщениями самостоятельно?

Хотя использование Redis для кеширования и pub/sub ясное для меня, неясно, можно ли использовать Redis на месте полноценной системы обмена сообщениями, такой как JMS, AMQP или ZeroMQ.
Оставшись в одиночку аспекте соответствия стандартам и сосредоточив внимание только на функциональности/функциях, помогает ли Redis поддерживать все шаблоны/модели обмена сообщениями, необходимые для системы обмена сообщениями?

Паттерны обмена сообщениями, о которых я говорю, следующие:

Если да, то Redis, похоже, решает сразу два (возможно, более) аспекта: кэширование и обмен сообщениями.

Я рассматриваю это в контексте веб-приложения, поддерживаемого сервером Java/Java EE. И я смотрю на это не с точки зрения доказательной концепции, а из масштабного угла разработки программного обеспечения.

Edit1:
пользователь: 791406 задал правильный вопрос:

Я подумал, что лучше детализировать эту часть как часть вопроса, а не в разделе комментариев.

Мои текущие потребности в меньшей степени связаны с SLA и QOS, а больше - с выбором инструмента для моей работы (обмена сообщениями), который я могу использовать, даже когда мои требования растут (разумно) в будущем. Сначала я начинаю с упрощенных требований, и все мы знаем, что требования, как правило, растут. И НЕТ, я не ищу ни одного инструмента, который сделает все это. Я просто хочу знать, выполняет ли Redis обычные требования, ожидаемые из системы обмена сообщениями, например, ActiveMQ/RabbitMQ. Конечно, если мои потребности в SLA/QOS являются экстремальными/эксцентричными, мне нужно будет получить специальный инструмент для удовлетворения этого. Например: в некоторых случаях ZeroMQ может быть выбран над RabbitMQ из-за особых требований SLA. Я не говорю о таких особых требованиях. Я сосредотачиваюсь на средних корпоративных требованиях.

Я испугался (основываясь на моем небольшом понимании), что событие, хотя redis можно было использовать в качестве базового инструмента для сегодняшних сообщений, это может быть неправильным инструментом для реальной работы с сообщениями в будущем. У меня есть опыт работы с системами обмена сообщениями, такими как ActiveMQ/RabbitMQ, и знайте, что они могут использоваться для простых (разумно) сложных потребностей обмена сообщениями.

Я решил использовать JMS для своих нужд обмена сообщениями и использовать Redis для кэширования.

Ответы

Ответ 1

Что вам нужно?

Я думаю, что вопрос, который вы должны задать себе, - это "какое качество обмена сообщениями необходимо для поддержки моего приложения?" прежде чем принять решение о платформе обмена сообщениями. Кого волнует, если redis поддерживает эти шаблоны; будет ли соответствовать вашим требованиям SLA и QoS? В первую очередь сосредоточьтесь на этом, затем сделайте свое технологическое решение на основе этой оценки.

Сказав это, я представлю свой материал о том, как вы можете принять это решение...

Высоконадежные/постоянные/надежные сообщения
Возьмем крайний случай: скажем, вы строите торговое или финансовое приложение. Такие приложения требуют строгой SLA, где надежность сообщений, надежность, ровно однажды доставка и долговечность являются первостепенными. Использование redis в качестве основы для обмена сообщениями для этого случая, вероятно, является плохим выбором, множество причин, почему...

redelivery сообщения (когда sh * t попадает в вентилятор)
репликация хранилища сообщений, когда redis не работает
сообщение сделка (redis не могу сделать XA)
отказоустойчивость производителя/абонента и отказоустойчивость
последовательность заказов сообщений
отправка сообщений, когда брокер недоступен (сохранение и пересылка)
однопоточный redis может стать узким местом

Если ваша система имеет строгие SLA, некоторые или все эти проблемы будут определенно возникать, так как вы будете справляться с этими ограничениями? Вы можете реализовать собственный код вокруг redis для решения некоторых проблем, но зачем беспокоиться, когда зрелые платформы обмена сообщениями, такие как ActiveMq, WebsphereMQ и WebLogic JMS, обеспечивают постоянство, надежность и отказоустойчивость? Вы сказали, что находитесь в стеке Java/Java EE, поэтому вы можете использовать некоторые из наиболее надежных фреймворков обмена сообщениями, доступных как с открытым исходным кодом, так и с коммерческой точки зрения. Если вы делаете финансовые транзакции, вам необходимо рассмотреть эти параметры.

Сообщения о высокой производительности/больших распределенных системах
Если вы строите социальную сеть или игровую платформу, где вам нужна производительность по надежности, ZeroMq, вероятно, подходит. Это библиотека связи сокета, завернутая в API-интерфейс, похожий на сообщения. Он децентрализован (без брокера), очень быстрый, очень устойчивый и отказоустойчивый. Если вам нужно делать что-то вроде N-to-N pub/sub с посредниками-посредниками, управлением потоками, постоянством сообщений или синхронизацией "точка-точка", ZeroMq предлагает необходимые средства и образцы кода, чтобы сделать все это с минимальным кодом, избегая при этом строительные решения с нуля. Он написан на C, но имеет клиентские библиотеки почти для каждого популярного языка.

Надеюсь, что это поможет...