2008-10-27 23 views
23

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.¿Debo usar MSMQ o SQL Service Broker para las transacciones?

Algunos detalles:

  • Nuestro cliente es .NET 1.1 y 2.0 de código; aquí es de donde se enviará el mensaje.
  • El destino 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.
  • Tenemos que 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 y 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.

¿E-cando extraño? ¿Hay un ganador claro aquí? Cualquier pensamiento, experiencia o enlace sería valorado. ¡Gracias!

EDIT: Terminamos quedándonos con el agente 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!

+3

Si su código de cliente se ejecuta en una máquina que no sea el servidor de la base de datos, asegúrese de probar el escenario de reversión. Me encontré con problemas en los que cuando procesaba la cola y necesitaba fallar algo debido a que el punto final remoto estaba inactivo, terminaba por retirar la cola en el intermediario de servicios porque solo puede manejar 5 fallas antes de que se desconecte. Para evitar esto tuve que deshabilitar transacciones para Service Broker y confiar en el manejo de excepciones en el código, lo que significa que bajo ciertas fallas perdería completamente el mensaje. –

+0

¿Cuál fue la elección final? Eso es si no es demasiado tarde para preguntar :). –

+1

@the coon: Terminamos usando SQL Service Broker, y funcionó bien (como mencioné en la edición anterior).Fue la mejor opción para nosotros en ese momento, aunque creo que (entre estos dos) usaría MSMQ si fuera a reconstruir el sistema desde cero. –

Respuesta

31

Al haber 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 solo se trata de mover datos?Service Broker
  • ¿Se está procesando 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 tener en cuenta, no importa lo que usted elija

  • ¿Cómo sabe la salud de su 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 los informes? Si ya usa Tablas SQL en sus informes, Service Broker puede encajar fácilmente ya que se trata simplemente de otra tabla dinámica. Si ya está utilizando 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 perderá.
  • ¿Ya tiene experiencia con una de estas tecnologías? Ambos tienen muchos detalles de implementación que pueden volver y morderte.
  • No importa qué opción elija, ¿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.
+1

"¿Necesita poder enviar mensajes mientras el destino está inactivo? MSMQ": puede hacer esto con Service Broker, solo necesita tener una base de datos local para contener la cola de envío. –

+0

Sé que esta respuesta es de hace 4 años ... pero siempre ha podido procesar las colas de forma remota y transitoria con Service Broker. (Y siempre que no esté utilizando el enrutamiento, puede hacerlo de forma gratuita con SQL Express). Sí, el contenedor de cliente .Net de Microsoft es un poco asqueroso, pero es muy fácil ajustar los comandos SQL con ADO.Net o Entity Framework . La cola que se cierra después de 5 reversiones puede resolverse fácilmente colocando una declaración de "habilitar cola" en la parte superior de su bucle principal. –

4

He usado MSMQ anteriormente y el único elemento que agregaría a su lista es un requisito previo 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 va por la ruta MSMQ.

3

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.

1

¿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.

+2

¿Qué pasa si SSB está inactivo? O una conexión de red va? Con MSMQ seguirá escribiendo localmente y estará disponible en la cola pública una vez que se restablezca la conexión. Si la conexión de red falla, no puede agregar un mensaje a la cola SSB. –

+1

La forma de resolver el problema de la red es hacer que todos los servidores que se comunican tengan su propio servidor de base de datos. Dado que Service Broker es compatible con SQL Server Express, no es necesario que esto cueste demasiado. –

Cuestiones relacionadas