Этот вопрос возникает, когда я сталкивался с некоторыми упоминаниями (например, this) об использовании программного обеспечения для обмена сообщениями, такого как ZeroMQ наряду с Redis, но я все время слышу о том, что сам Редис использовал систему обмена сообщениями. Итак, если Redis используется вместе с другими системами обмена сообщениями, значит ли это, что у Redis есть серьезные недостатки, когда они используются как система обмена сообщениями самостоятельно?
Хотя использование Redis для кеширования и pub/sub ясное для меня, неясно, можно ли использовать Redis на месте полноценной системы обмена сообщениями, такой как JMS, AMQP или ZeroMQ.
Оставшись в одиночку аспекте соответствия стандартам и сосредоточив внимание только на функциональности/функциях, помогает ли Redis поддерживать все шаблоны/модели обмена сообщениями, необходимые для системы обмена сообщениями?
Паттерны обмена сообщениями, о которых я говорю, следующие:
- RPC/Request-reply ( пример используя ActiveMQ/JMS и другой, используя RabbitMQ/AMQP)
- Трубопровод/рабочие очереди (один раз и один раз, когда потребление каждого сообщения)
- Широковещательная передача (все подписались на канал)
- Многоадресная рассылка (фильтрация сообщений на сервере на основе селекторов потребителей)
- Любой другой шаблон обмена сообщениями?
Если да, то Redis, похоже, решает сразу два (возможно, более) аспекта: кэширование и обмен сообщениями.
Я рассматриваю это в контексте веб-приложения, поддерживаемого сервером Java/Java EE. И я смотрю на это не с точки зрения доказательной концепции, а из масштабного угла разработки программного обеспечения.
Edit1:
пользователь: 791406 задал правильный вопрос:
"Кого волнует, если redis поддерживает эти шаблоны, будет повторно соответствовать вашему SLA и QoS?"
Я подумал, что лучше детализировать эту часть как часть вопроса, а не в разделе комментариев.
Мои текущие потребности в меньшей степени связаны с SLA и QOS, а больше - с выбором инструмента для моей работы (обмена сообщениями), который я могу использовать, даже когда мои требования растут (разумно) в будущем. Сначала я начинаю с упрощенных требований, и все мы знаем, что требования, как правило, растут. И НЕТ, я не ищу ни одного инструмента, который сделает все это. Я просто хочу знать, выполняет ли Redis обычные требования, ожидаемые из системы обмена сообщениями, например, ActiveMQ/RabbitMQ. Конечно, если мои потребности в SLA/QOS являются экстремальными/эксцентричными, мне нужно будет получить специальный инструмент для удовлетворения этого. Например: в некоторых случаях ZeroMQ может быть выбран над RabbitMQ из-за особых требований SLA. Я не говорю о таких особых требованиях. Я сосредотачиваюсь на средних корпоративных требованиях.
Я испугался (основываясь на моем небольшом понимании), что событие, хотя redis можно было использовать в качестве базового инструмента для сегодняшних сообщений, это может быть неправильным инструментом для реальной работы с сообщениями в будущем. У меня есть опыт работы с системами обмена сообщениями, такими как ActiveMQ/RabbitMQ, и знайте, что они могут использоваться для простых (разумно) сложных потребностей обмена сообщениями.
Edit2
-
На веб-сайте redis упоминается "Redis часто используется как сервер обмена сообщениями" , но как достичь шаблонов обмена сообщениями неясно.
-
Salvatore sanfilippo упоминает Пользователи Redis используют его как базу данных, как шину обмена сообщениями или как кеш. В какой степени он может служить "шиной обмена сообщениями", неясно.
-
Когда я пытался выяснить, какие требования к передаче сообщений JMS не поддерживаются redis, я сталкивался с тем, что Redis поддерживает, но JMS не поддерживает: Подписки подбора шаблонов, т.е. клиенты могут подписаться на glob-style шаблоны, чтобы получать все сообщения, отправленные на имена каналов, соответствующие заданному шаблону.
Заключение
Я решил использовать JMS для своих нужд обмена сообщениями и использовать Redis для кэширования.