java - con - Lograr patrones de mensajería JMS/AMQP usando Redis

rabbitmq netbeans

Question

Esta pregunta surge cuando me topé con algunas menciones (como this ) sobre el uso de un software de mensajería como ZeroMQ junto con Redis, pero sigo escuchando que el propio Redis usa un sistema de mensajería. Entonces, si Redis se usa junto con otros sistemas de mensajería, ¿significa que Redis tiene algunas deficiencias serias cuando se usa como un sistema de mensajería solo?

Si bien el uso de Redis para el almacenamiento en caché y pub / sub es claro para mí, no está claro si se puede usar Redis en lugar de un sistema de mensajería completo como JMS, AMQP o ZeroMQ.
Dejando solo el aspecto de cumplimiento de estándares y concentrándose solo en la funcionalidad / características, ¿Redis proporciona soporte para todos los patrones / modelos de mensajería requeridos de un sistema de mensajería?

Los patrones de mensajería de los que estoy hablando son:

1. RPC / Request-reply (un example usa ActiveMQ / JMS y another usa RabbitMQ / AMQP)
2. Pipeline / Colas de trabajo (consumo de una vez y casi una vez de cada mensaje)
3. Difusión (todos suscritos al canal)
4. Multicast (filtrado de mensajes en el servidor basado en los selectores de los consumidores)
5. ¿Algún otro patrón de mensajería?

Si es así, entonces Redis parece resolver dos (posiblemente más) aspectos a la vez: almacenamiento en caché y mensajería.

Lo estoy viendo en el contexto de una aplicación web respaldada por un servidor Java / Java EE. Y estoy viendo esto no desde un punto de vista de prueba de concepto sino desde un ángulo de desarrollo de software a gran escala.

Edit1:
usuario: 791406 hizo una pregunta válida:

"¿A quién le importa si redis admite esos patrones; volverá a satisfacer sus necesidades de SLA y QoS?"

Pensé que es mejor dar este detalle como parte de la pregunta en lugar de en la sección de comentarios.

Mis necesidades actuales tienen menos que ver con SLA y QOS, y más con la elección de una herramienta para mi trabajo (mensajes) que puedo usar incluso cuando mis necesidades crezcan (razonablemente) en el futuro. Estoy empezando con requisitos simplistas al principio y todos sabemos que los requisitos tienden a crecer. Y NO , no estoy buscando una herramienta que lo haga todo. Solo quiero saber si Redis cumple con los requisitos habituales que se esperan de un sistema de mensajería, como lo hace ActiveMQ / RabbitMQ. Por supuesto, si mis necesidades de SLA / QOS son extremas / excéntricas, necesitaría una herramienta especial para satisfacerlas. Por ejemplo: en algunos casos, ZeroMQ podría elegirse sobre RabbitMQ debido a los requisitos específicos del SLA. No estoy hablando de tales requisitos especiales. Me estoy centrando en los requisitos empresariales promedio.

Tenía miedo (en base a mi escasa comprensión) de que aunque la redis podría ser utilizada como una herramienta básica para mis necesidades de mensajería de hoy, podría ser la herramienta equivocada para un verdadero trabajo de mensajería en el futuro. Tengo experiencias con sistemas de mensajería como ActiveMQ / RabbitMQ y sé que se pueden usar para necesidades de mensajería simples y complejas.

Edit2 :

1. El sitio web de redis menciona "Redis se usa a menudo como un servidor de mensajería", pero no está claro cómo lograr los patrones de mensajería.

2. Salvatore sanfilippo menciona que los usuarios de Redis tienden a usarlo como una base de datos, como un bus de mensajería o como caché . Hasta qué punto puede servir como un "bus de mensajería" no está claro.

3. Cuando intentaba averiguar qué requisitos de mensajería de JMS no admite redis, encontré algo que Redis admite pero JMS no: suscripciones de coincidencia de patrones, es decir, los clientes pueden suscribirse a patrones de estilo glob para recibir todos los mensajes enviados a nombres de canales que coinciden con un patrón dado.

Conclusión :

Decidí usar JMS para mis necesidades de mensajería y usar Redis para almacenamiento en caché.

Answer 1

Que necesidades tienes

Creo que la pregunta que debe hacerse es "¿qué calidad de mensajería necesito para admitir mi aplicación?" Antes de decidirse por una plataforma de mensajería. A quién le importa si redis apoya esos patrones; ¿Volverá a satisfacer sus necesidades de SLA y QoS? Céntrese en eso primero, luego tome su decisión tecnológica basada en esa evaluación.

Dicho esto, ofreceré mi opinión sobre cómo puede tomar esa decisión ...

Mensajería altamente confiable / persistente / duradera
Tomemos un caso extremo: digamos que está creando una aplicación comercial o financiera. Tales aplicaciones exigen SLA estrictos donde la persistencia del mensaje, la confiabilidad, la entrega exacta y la durabilidad son primordiales. Usar redis como la red troncal de mensajería para este caso es probablemente una mala elección, hay muchas razones por las que ...

• mensaje redelivery (cuando el sh * t golpea el ventilador)
• replicación del almacén de mensajes cuando redis baja
• transacciones de mensajes (redis no puede hacer XA)
• Tolerancia a fallos del productor / suscriptor y resistencia a la desconexión
• secuencia de orden de mensajes
• enviar mensajes cuando el intermediario está inactivo (almacenar y reenviar)
• redis de un solo hilo puede convertirse en cuello de botella

Si su sistema tiene SLA estrictos, algunos o todos estos problemas surgirán definitivamente, entonces, ¿cómo manejará estas limitaciones? Puede implementar código personalizado alrededor de redis para abordar algunos problemas, pero ¿por qué molestarse cuando las plataformas de mensajería maduras como ActiveMq, WebsphereMQ y WebLogic JMS ofrecen persistencia, confiabilidad y tolerancia a fallas? Usted dijo que está en una pila de Java / Java EE, por lo que está en condiciones de utilizar algunos de los marcos de mensajería más robustos disponibles, ya sea de código abierto o comercial. Si está haciendo transacciones financieras, debe considerar estas opciones.

Mensajería de alto rendimiento / sistemas distribuidos grandes
Si está creando una red social o una plataforma de juegos en la que desea un rendimiento superior a la confiabilidad, ZeroMq es probablemente una buena opción. Es una biblioteca de comunicación de socket envuelta en una API similar a la mensajería. Es descentralizado (sin intermediario), muy rápido, muy resistente y tolerante a fallos. Si necesita hacer cosas como pub / sub N-to-N con intermediarios de intermediarios, control de flujo, persistencia de mensajes o sincronización punto a punto, ZeroMq ofrece las instalaciones necesarias y ejemplos de código para hacerlo todo con un código mínimo, evitando al mismo tiempo Construyendo soluciones desde cero. Está escrito en C pero tiene bibliotecas cliente para casi todos los idiomas populares.

Espero que ayude...