Cómo implementar la solución de Message Queue Server

Question

Tengo un escenario en el que será necesario enrutar unos 10 mensajes diferentes y luego quitarlos de la cola/procesarlos. Un suscriptor necesitará los 10 mensajes, pero otro solo necesitará 8 de los 10 mensajes. Estoy tratando de entender cuál es la mejor manera de configurar este tipo de arquitectura. ¿Crea una cola para cada tipo de mensaje para que el suscriptor pueda suscribirse a las colas relevantes o las deposite en la misma cola e ignore los mensajes que no son relevantes para ese suscriptor? Quiero asegurar que la solución es flexible/escalable, etc.

proceso:

1. 10 diferentes mensajes XML se encolan con un servidor IBM WebSphere MQ.
2. Utilizaremos .Net (lo más probable es que WCF desde que WebSphere MQ 7.1 haya agregado soporte para WCF)
3. Demostraremos los mensajes y los cargaremos en otro DB back-end (muy probablemente SQL Server).
4. La solución debe escalarse bien porque procesaremos una gran cantidad de mensajes y esto podría aumentar (probablemente 40-50,000/h). Por lo menos una gran cantidad para nosotros.

Como siempre agradezco mucho la información.

-S

Answer 1

Bien, según los comentarios, aquí hay una sugerencia que se ampliará y no requiere muchos cambios en las aplicaciones.

Del lado del productor, copiaba los criterios de selección de mensajes a una propiedad de mensaje y luego publicaba el mensaje a un tema. El único cambio que se requiere aquí para la aplicación es la propiedad del mensaje. Si por algún motivo no desea publicarlo utilizando la funcionalidad nativa, puede definir un alias sobre un tema. La aplicación cree que está enviando mensajes pero en realidad son publicaciones.

En el lado del consumidor, tiene un par de opciones. Una es crear suscripciones administrativas para cada aplicación y usar un selector en la suscripción. Los mensajes se canalizan a una cola dedicada por consumidor, según los criterios de selección. Las aplicaciones piensan que simplemente están consumiendo mensajes.

Alternativamente, la aplicación puede simplemente suscribirse al tema. Esto le da la opción de una suscripción dinámica que no recibe mensajes cuando la aplicación se desconecta (si de hecho lo desea) o una suscripción duradera que es funcionalmente equivalente a la suscripción administrativa.

Esta solución se escalará fácilmente a los volúmenes que citó. Otra opción es que el productor no use propiedades.Aquí, la aplicación del consumidor consume todos los mensajes, rompe la carga del mensaje en cada uno y decide si procesar o ignorar el mensaje. En esta solución, el productor sigue publicando sobre un tema. Cualquier solución que implique cola recta obliga al productor a conocer todos los destinos. Agregue otro consumidor, cambie el productor. Además, hay un PUT para cada destino.

El peor de los casos es un productor que coloca varios mensajes y un consumidor que tiene que leer cada uno para decidir si va a ignorarlo. Esa opción puede tener problemas de escala, dependiendo de cuán profunda sea la carga útil del campo de criterios de selección. Expresión de XPath realmente larga = rendimiento deficiente y sin forma de sintonizar WMQ para compensarlo, ya que la latencia está en la aplicación en ese punto.

Mejor caso, el productor establece un mensaje de propiedad y lo publica. Los consumidores seleccionan en la propiedad en su suscripción o una suscripción administrativa hace esto por ellos. Si esta solución usa suscripciones de aplicaciones o suscripciones administrativas, no hay ninguna diferencia en lo que respecta a la escalabilidad.

Answer 2

Creación de colas es relativamente 'barato' desde una perspectiva de recursos, además de que sí, es mejor utilizar una cola para cada propósito específico, por lo que es probablemente mejor en este caso a separarlos por cliente de destino si es posible. Usar una cola para extraer mensajes selectivamente en función de algunos criterios (ID de correlación u otra cosa) suele ser una mala idea. El escenario de mejor rendimiento en mensajería es el más sencillo: simplemente extrae los mensajes de la cola a medida que llegan, en lugar de mirar y recibir de forma selectiva.

En cuanto a la ampliación, no puedo hablar de Websphere MQ u otros productos de IBM, pero 40-50K mensajes por hora no son particularmente difíciles de manejar para MSMQ en Windows Server, así que supongo que IBM puede hacerlo también. Por lo general, el cuello de botella no es la plataforma de cola en sí, sino más bien el proceso de eliminación y procesamiento de mensajes individuales.