habilitar - ¿Debo usar MSMQ o SQL Service Broker para las transacciones?

sql server queue

Question

El líder de mi equipo me ha pedido que investigue MSMQ como una opción para la nueva versión de nuestro producto. Usamos SQL Service Broker en nuestra versión actual. He hecho mi parte justa de la experimentación y Google para encontrar el producto que mejor se adapta a mis necesidades, pero pensé que podría pedir el mejor sitio que conozco para programar las respuestas.

Algunos detalles:

• Nuestro cliente es el código .NET 1.1 y 2.0; aquí es de donde se enviará el mensaje.
• El objetivo en una instancia de SQL Server 2005. Todos los mensajes terminan siendo actualizaciones de bases de datos o inserciones.
• Enviaremos varias actualizaciones que deben tratarse como una transacción.
• Debemos tener una capacidad de recuperación de mensajes perfecta; no se pueden perder mensajes
• Tenemos que ser asincrónicos y capaces de aceptar mensajes incluso cuando el servidor SQL de destino no funciona.
• Desarrollar nuestra propia solución de colas no es una opción; somos un equipo pequeño

Cosas que he descubierto hasta ahora:

• Tanto MSMQ como SQL Service Broker pueden hacer el trabajo.
• Parece que el intermediario de servicios es más rápido para los mensajes transaccionales.
• Service Broker requiere que un servidor SQL se ejecute en alguna parte, mientras que MSMQ necesita que cualquier máquina Windows configurada se ejecute en alguna parte.
• MSMQ parece ser mejor / más rápido / más fácil de configurar / ejecutar en clústeres.

¿Me estoy perdiendo de algo? ¿Hay un ganador claro aquí? Cualquier pensamiento, experiencia o enlace sería valorado. ¡Gracias!

EDITAR: Terminamos quedándonos con el intermediario de servicios porque tenemos un marco de base de datos personalizado utilizado en algunos de nuestros códigos de cliente (manejamos mejor las transacciones). Ese código capturó SQL para las transacciones, pero no. El código del cliente también era toda la versión 1.1 de .NET, por lo que tendríamos que actualizar todo el código del cliente. ¡Gracias por tu ayuda!

Answer 1

He usado MSMQ anteriormente y el único elemento que agregaría a su lista es una verificación de requisitos previos para el control de versiones. Me encontré con un problema donde un sitio tenía Win 2000 Server y, por lo tanto, MSMQ v.2, frente a Win 2003 Server y MSMQ v3. Todo mi código .NET apunta a v.3 y no son compatibles ... o al menos no son tan fáciles.

Solo una consideración si vas a la ruta MSMQ.

Answer 2

La limitación del tamaño del mensaje en MSMQ ha detenido mi búsqueda en esa dirección. Estoy aprendiendo Service Broker para el proyecto.

Answer 3

Habiendo migrado mi aplicación de Service Broker a MSMQ, tendría que votar para usar MSMQ. Hay varios factores a tener en cuenta, pero la mayoría de ellos tienen que ver con la forma en que usa sus datos y dónde vive el procesamiento.

• Si el procesamiento se realiza en la base de datos? Service Broker
• Si es solo movimiento de datos? Service Broker
• ¿Se procesa en el código .NET / COM? MSMQ
• ¿Necesita transacciones distribuidas remotas (por ejemplo, procesamiento en un cuadro diferente de SQL)? MSMQ
• ¿Necesita poder enviar mensajes mientras el destino está caído? MSMQ
• ¿Desea utilizar nServiceBus, MassTransit, Rhino-ESB, etc.? MSMQ

Cosas a considerar sin importar lo que elijas

• ¿Cómo sabes la salud de tu cola? Ambas opciones manejan la conmutación por error de manera diferente. Por ejemplo, Service Broker deshabilitará su cola en ciertos escenarios que pueden anular su aplicación.
• ¿Cómo va a realizar informes? Si ya usa Tablas SQL en sus informes, Service Broker puede adaptarse fácilmente ya que se trata simplemente de otra tabla dinámica. Si ya está usando el Monitor de rendimiento, MSMQ puede encajar mejor. Service Broker tiene una gran cantidad de contadores de rendimiento, así que no dejes que este sea tu único factor.
• ¿Cómo se mide el tiempo de actividad? ¿Simplemente se asegura de que no pierda transacciones o necesita responder sincrónicamente? Encuentro que la naturaleza distribuida de MSMQ permite un mayor tiempo de actividad porque la cola principal puede desconectarse y no perder nada. Mientras que con Service Broker su base de datos debe estar en línea o de lo contrario pierde.
• ¿Ya tienes experiencia con una de estas tecnologías? Ambos tienen muchos detalles de implementación que pueden volver y morderte.
• No importa qué elección haga, ¿qué tan fácil es cambiar la tecnología Queuing subyacente? Recomiendo tener una interfaz IQueue genérica contra la que escribas una implementación concreta. De esta manera, la elección que realice puede cambiarse fácilmente más adelante si descubre que tomó la decisión equivocada. Después de todo, una cola es solo una cola y no debe encerrarlo en una implementación específica.

Answer 4

¿Necesita poder enviar mensajes mientras el destino está caído? MSMQ

No entiendo por qué? SSB puede enviar mensajes a un destino desconectado sin ningún problema. Todos estos mensajes van a la cola de transmisión y se entregarán cuando el destino permanezca accesible.