local frente a las colas remotas en pub de mensajería/sub

Question

Si yo estaba construyendo un sistema con docenas de editoriales/abonados que utilizan colas de mensajes, parece que tengo algunas opciones de configuración de red:

1. yo pudiera tener uno agrupadas corredor que todas las máquinas de usar - cada máquina no tendría una cola local
2. pude instalar corredores localmente en cada máquina, y el uso de almacenamiento y hacia adelante para entregar mensajes a máquinas remotas

diferentes tecnologías parecen cumplir diferentes configuraciones, por ejemplo, MS MQ requiere que cada máquina tenga su propia cola local, mientras que Tibco EMS parece usarse a menudo en clústeres, sin colas locales en cada consumidor.

¿Cuáles son los inconvenientes de no tener una cola local y qué factores influyen en la decisión?

Answer 1

No tener una cola local que proporcione un almacén de mensajes duradero significa que no puede garantizar la entrega del mensaje. El uso de algo como RabbitMQ en un clúster con una instancia de intermediario localmente le brinda un mecanismo duradero para almacenar mensajes para la entrega. Si tiene que conectarse a través de una conexión de red a un intermediario remoto para enviar un mensaje duradero, correrá un mayor riesgo de fallas en la red.

MSMQ también es store-and-forward, pero no proporciona ninguna capacidad de enrutamiento agrupado. Esto significa que la aplicación tiene que hacer el trabajo (o tener una capa encima, como MassTransit o NServiceBus lo hacen por usted).

Cuando pienso en TIBCO, pienso en un clúster centralizado de servidores EMS con el que los servidores de aplicaciones se comunican en lugar de ejecutar localmente una instancia de intermediario. Las herramientas de GUI que envuelven a EMS y los servidores de aplicaciones de BusinessWorks realmente fuerzan a un modelo en ese mundo.

En cualquiera de los casos distribuidos donde los mensajes se almacenan localmente, es importante asegurarse de que la máquina esté debidamente equipada para el almacenamiento de mensajes, con disco rápido y suficiente disco para la acumulación esperada de mensajes/capacidad.

Answer 2

Me atrevo a aventurar que la cola local sería necesaria en la mayoría de los escenarios.

La cola local es necesaria si el mensaje debe ser duradero. En otras palabras, si la conexión a una cola remota no es confiable y desea que el mensaje finalmente llegue a sus suscriptores, querría la capacidad de almacenar y enviar de la cola local.

Si el mensaje no necesita ser duradero (se puede perder después del encendido del evento), la cola compartida remota sería una opción.

Es posible que desee ver el NServiceBus distributor model, que sería un híbrido de sus dos escenarios: una cola local en cada máquina para reenviar a un clúster de distribuidor/intermediario remoto.

Answer 3

No estoy seguro de estar de acuerdo con los comentarios sobre MSMQ porque parecen obsoletos. Tal vez me estoy perdiendo algo.

Ambos escenarios son compatibles con MSMQ.

En el escenario 1, los clientes utilizarían recepciones remotas transaccionales (MSMQ 4.0 y superiores). Al ser transaccional, la recepción es confiable y el mensaje es duradero (a diferencia de las versiones anteriores de MSMQ como abortado, el mensaje se deja en el servidor).

En el escenario 2, la cola saliente de almacenamiento y reenvío se enviará a una cola transaccional local en el cliente (otra vez confiable y duradera).

La fiabilidad y la durabilidad no deben ser los puntos de toma de decisiones para el uso de colas locales frente a las remotas. Peformance es el diferenciador aquí para MSMQ.