NServiceBus: ¿Las transacciones MSMQ no son MALAS?

Question

Estoy aprendiendo sobre NServiceBus y MSMQ. Me dijeron que las colas transaccionales en MSMQ son MALAS y que usarlas es realmente malo para el rendimiento. ¿Alguien sabe por qué? Supongo que esto proviene de la idea de que usa DTC y todos saben que el DTC no es realmente una solución escalable. Me parece que hay un par de razones por las que MSMQ con NServiceBus no es tan malo, pero no sé si entiendo cómo funciona completamente. En cuanto a esta lógica, no puedo pensar en 3 lugares donde NServiceBus podría operaciones con el fin de obtener la entrega garantizada:

1. Al enviar un mensaje a través de la red, es posible que desee utilizar una transacción para asegurar que el mensaje tiene Llegó a la cola remota antes de descartarla.
2. Al leer un mensaje de una cola local, es posible que desee asegurarse de que se maneja con éxito antes de descartarlo.
3. Al publicar un mensaje para varios suscriptores, es posible que desee asegurarse de que llegue a TODOS ellos antes de descartarlo. (Realmente espero que esto NO sea lo que hace NServiceBus)

¿Alguien me puede aclarar cómo NServiceBus hace esto?

Answer 1

Las transacciones Msmq no garantizan que el receptor haya recibido el mensaje. La transacción garantiza que el mensaje ha sido recibido por la infraestructura msmq en su máquina, y si el mensaje es duradero (el valor predeterminado en NSB), esto significa que se ha conservado en el disco y sobrevivirá a un reinicio. El mensaje será entregado por msmq sin bloquear a la persona que llama. Esto es mejor conocido como "store and forward"

1. Por defecto MSMQ sólo garantiza que la infraestructura de msmq local ha recibido el mensaje. No se requiere que los servidores receptores estén en línea. Sin embargo, esto se puede habilitar (ver la respuesta de John a continuación)

2. Este es uno de los puntos clave de venta de NSB. La capacidad de usar transacciones que abarca tanto la cola local como su almacén de datos (es decir, la transacción distribuida) es crucial para garantizar la coherencia. Es decir, si algo falla, no se conservará nada en el almacén de datos y el mensaje se revertirá y se reintentará sin que el usuario tenga que hacer nada.

3. Igual que el # 1. La única garantía es que cada suscriptor recibirá eventualmente el mensaje publicado. No se realizan llamadas de bloqueo por lo que siempre que tenga espacio libre en el disco y el servidor de publicación la llamada volverá de inmediato.

Hope this helps!

Answer 2

El punto n. ° 2 es correcto. No quiere que un mensaje cause un error y luego caiga por las grietas. Desea que el manejador de mensajes tenga éxito, en cuyo caso se elimina de la cola, o falla y se retrotrae, de modo que se puede volver a intentar o enviar a una cola de error para su análisis después de que se ha alcanzado un número configurable de intentos .

Answer 3

Punto 1 - Incomplete. Los mensajes transaccionales sí le dan esto SI usted usa el Diario de Fuente Negativo y Postivo con Colas de Carta Muerta y temporizadores TTRQ/TTBR. Luego puede determinar exactamente qué le ha sucedido a un mensaje, si fue rechazado, si se entregó, si se procesó.