2008-10-03 20 views
5

Necesito poner en cola eventos y tareas para sistemas externos de forma confiable/transaccional. Utilizar cosas como MSMQ o ActiveMQ parece muy seductor, pero la parte transaccional se vuelve complicada (MSDTC, etc.).Queueing/Dequeue transaccional

Podríamos utilizar la base de datos (SQL Server 2005+, Oracle 9+) y lograr un soporte transaccional más fácil, pero la parte de la cola se vuelve más fea.

Ninguna de las dos rutas parece tan buena y está llena de accidentes desagradables y casos extremos.

¿Puede alguien ofrecer alguna orientación práctica en este asunto?

Pensar: E/C/A o un motor de tareas programadas que se activa cada cierto tiempo y ver si hay alguna tarea programada que deba ejecutarse en este momento (es decir, la siguiente fecha de ejecución ha pasado, pero la fecha de expiración aún no ha sido alcanzado).

Respuesta

5

nuestro sistema tiene 60 computadoras, cada una ejecuta 12 tareas (hilos) que necesitan "obtener el próximo trabajo". En general, se trata de 50,000 "trabajos" por día. haga los cálculos de la cantidad de transacciones por minuto y observe que el tiempo de la tarea es variable, por lo que es posible obtener múltiples eventos "pop" al mismo tiempo.

Tuvimos nuestra primera versión usando MSMQ. conclusión: mantenerse alejado.Si bien funcionó bien con los problemas de carga y sincronización, tuvo 2 problemas. uno molesto y un factor decisivo.

Molesto: como software de empresa, MSMQ tiene necesidades de seguridad que simplemente lo convierten en una cosa más para configurar y luchar con el administrador de red del cliente.

Deal breaker: llegó el momento en que queríamos tomar el siguiente trabajo, pero no usando un simple pop pero algo así como "obtener el próximo trabajo AZUL" o "conseguir el próximo trabajo AMARILLO". no puede hacerlo!

Fuimos al plan B: Implementamos nuestra propia Q con una sola tabla SQL 2005. no podría estar más feliz

Me destacó probarlo con 200K mensajes por día, funcionó. Podemos hacer que la "próxima" lógica sea tan complicada como queramos.

la captura: debe tener mucho cuidado con el SQL que toma el siguiente elemento. Ya que quiere que sea rápido y NO se bloquee. hay 2 sugerencias muy importantes de SQL que usamos en base a algunas investigaciones. La magia es algo como esto:

SELECT TOP 1 @Id = callid 
FROM callqtbl WITH (READPAST, XLOCK) 
where 1=1 ORDER BY xx,yy 
+1

¿podría explicar esa consulta con un poco más de profundidad? tia! –

1

Quartz.Net es un sistema de programación de trabajos de código abierto.

+0

interesante, definitivamente voy a dar a esto una mirada. – chadmyers

0

¿Es WebSphere MQ (serie MQ) una opción? Es compatible con mensajes transaccionales.

+0

Potencialmente. ¿Su procesamiento de transacción también incluye la transacción de la base de datos (transacciones distribuidas)? ¿Vale la pena? – chadmyers

+0

Probablemente no valga la pena, ya que tiene su propio procesamiento interno de transacciones solo para el sistema de mensajería. Si también desea incluir llamadas a DB con los get/puts, entonces también necesitará MSDTC goo (suponiendo que Windows). La serie MQ se ejecuta prácticamente en cualquier caso: http://www.mqseries.net/phpBB2/index.php – MotoWilliams

4

He visto MSMQ usado transaccionalmente y no parecía particularmente complicado: una Transacción SCope envolvía las llamadas en cola o dequeue junto con el acceso a la base de datos y todo estaba bien siempre que la cola se definiera como transaccional una vez creada . No creo que esto sea cierto con ActiveMQ, que es un intermediario de mensajes, pero MSMQ se instala localmente en cada máquina de punto final, por lo que no es necesario que una transacción distribuida elaborada coloque un elemento de forma transaccional en la cola.

Usted probablemente ya sepan de esto, pero en .NET hay algunas bibliotecas ligeros que proporcionan algunas abstracciones agradables sobre MSMQ (y teóricamente otros transportes), así

nServiceBus: www.nservicebus.com

misa Tránsito: http://code.google.com/p/masstransit/

Además, Oren Eini tiene una cola transaccional interesante, aunque experimental, basada en el sistema de archivos. El beneficio de esta biblioteca es que, a diferencia de MSMQ, se puede implementar como una biblioteca y no requiere el dolor de cabeza de mantenimiento por la implementación de MSMQ.

Usted puede leer sobre eso aquí: http://ayende.com/Blog/archive/2008/08/01/Rhino.Queues.Storage.Disk.aspx

Además, SQL Server 2005 Cómo maneja cola bastante elegante, el uso de SQL Server Service Broker, pero necesitará SQL Server instalado en cada punto final, y no hacer saber si SSB cruza el firewall

Finalmente, si no obtiene la respuesta que está buscando aquí, le recomiendo el foro de discusión nSErviceBus. Udi Dahan responde este tipo de preguntas junto con su pequeño grupo de seguidores orientados a los mensajes, y es el mejor recurso que he encontrado hasta ahora para obtener respuestas rápidas y competentes a mis preguntas orientadas a las colas. Ese foro está aquí: http://tech.groups.yahoo.com/group/nservicebus/

+0

SSB usa puntos finales que están configurados para usar un puerto UDP. Entonces, el firewall se puede configurar para que coincida con –

1

Esto es lo que MSMQ está diseñado para - cola con las transacciones. Si eso no funciona para usted, consulte la característica "Service Broker" de SQL Server: es la "cola en una tabla SQL" que 'csmba' describe en su respuesta, pero es un componente integrado de SQL Server, muy bien empaquetado. y expuesto para su uso.

Cuestiones relacionadas