Actualmente estoy en el proceso de armar una arquitectura de referencia para un sistema distribuido basado en eventos donde los eventos se almacenan en una base de datos Azure de SQL Server utilizando tablas simples (no SQL Server Service Broker).Queues de bases de datos y procesamiento de colas
Los eventos se procesarán utilizando Roles de trabajo que sondearán la cola para nuevos mensajes de eventos.
En mi investigación, veo una serie de soluciones que permiten que múltiples procesadores procesen los mensajes fuera de la cola. El problema que tengo con muchos de los patrones que veo es la complejidad añadida de administrar el bloqueo, etc. cuando varios procesos intentan acceder a la cola de mensajes únicos.
Entiendo que el patrón de cola tradicional es tener varios procesadores que extraen de una sola cola. Sin embargo, suponiendo que los mensajes de evento se puedan procesar en cualquier orden, ¿hay alguna razón para no crear simplemente una relación de uno a uno entre una cola y su procesador de cola y solo equilibrar la carga entre las diferentes colas?
queue_1 => processor_1
queue_2 => processor_2
Esta aplicación evita todas las tuberías necesarias para administrar el acceso simultáneo a la cola entre varios procesadores. El editor de eventos puede usar cualquier algoritmo de equilibrio de carga para decidir a qué cola publicar los mensajes.
El hecho de que no veo este tipo de aplicación en cualquiera de mis búsquedas me hace pensar que estoy con vistas a un déficit importante en este diseño.
Editar
Este post ha desencadenado un debate sobre el uso de tablas de bases de datos como las colas frente a MSMQ, Azure colas, etc. Entiendo que hay una serie de opciones de gestión de colas nativos a mi disposición, incluyendo mensaje duradero Buffers en Azure AppFabric. Evalué mis opciones y determiné que las tablas de SQL Azure serán suficientes. La intención de mi pregunta era discutir el uso de múltiples procesadores contra una única cola frente a un procesador por cola.
"Entonces, ¿qué me estoy perdiendo?" Sugeriría que te falta el punto de utilizar una cola de eventos adecuada. Crear una cola de eventos usando una base de datos parece tonto cuando las colas de eventos ya son productos de primera clase. ¿Por qué no usar MS-MQ y ahorrarse un montón de dolor? –
@S. Lott: Yo diría que siempre hay una razón para tener sus colas y datos en la misma tienda. Copia de seguridad/restauración uniforme, eliminación del compromiso en dos fases con cada operación (DTC entre el almacén de mensajes y el almacén de datos), un producto para implementar/solucionar problemas/administrar, una solución HA/DR que falla sobre el almacén de mensajes y el almacén de datos estado coherente, todo esto y más hacen un caso muy convincente para colas dentro de la base de datos. Teniendo en cuenta que casi todos los mensajes se inician como resultado de una operación de datos y terminan actualizando datos, los eventos * son * datos y pertenecen juntos. –
@ S.Lott: 1) No tengo MSMQ, ya que estoy implementando en Azure. 2) MS-MQ tiene mucho dolor. –