Patrón de convoy secuencial

Procesa un conjunto de mensajes relacionados en un orden definido, sin bloquear el procesamiento de otros grupos de mensajes.

Contexto y problema

A menudo, las aplicaciones necesitan procesar una secuencia de mensajes en el orden en que llegan y, además, poder escalarse horizontalmente para controlar el aumento de la carga. En una arquitectura distribuida, el procesamiento de estos mensajes en orden no es sencillo, ya que los trabajos se pueden escalar de manera independiente y suelen extraer los mensajes de forma independiente, mediante un patrón de consumidores simultáneos.

Por ejemplo, un sistema de seguimiento de pedidos recibe un libro de contabilidad que contiene los pedidos y las operaciones pertinentes sobre esos pedidos. Estas operaciones pueden ser la creación de un pedido, la adición de una transacción al pedido, la modificación de una transacción anterior o la eliminación de un pedido. En este sistema, las operaciones se deben realizar de forma FIFO (primero en entrar, primero en salir), pero solo en el nivel del pedido. Pero la cola inicial recibe un libro de contabilidad que contiene transacciones para muchos pedidos, que pueden estar intercalados.

Solución

Inserte los mensajes relacionados en categorías dentro del sistema de cola y haga que los clientes de escucha de la cola bloqueen y extraigan un mensaje individual de una sola categoría.

Este es el aspecto del patrón de convoy secuencial general:

En la cola, los mensajes para distintas categorías pueden estar intercalados, como se muestra en el diagrama siguiente:

Problemas y consideraciones

Tenga en cuenta los puntos siguientes al decidir cómo implementar este patrón:

• Unidad de escala o categoría. ¿En qué propiedad de los mensajes entrantes se puede escalar horizontalmente? En el escenario de seguimiento de pedidos, esta propiedad es el identificador de pedido.
• Capacidad de proceso. ¿Cuál es el rendimiento de los mensajes de destino? Si es muy alto, es posible que tenga que reconsiderar los requisitos de FIFO. Por ejemplo, ¿puede aplicar un mensaje de inicio o finalización, ordenar por hora y después enviar un lote para su procesamiento?
• Funcionalidades de servicio. ¿La elección del bus de mensajes permite el procesamiento individualizado de los mensajes dentro de una cola o la categoría de una cola?
• Capacidad de evolución. ¿Cómo agregará una nueva categoría de mensaje al sistema? Por ejemplo, imagine que el sistema de contabilidad descrito antes es un cliente específico. Si tuviera que incorporar un cliente nuevo, ¿podría tener un conjunto de procesadores de libro de contabilidad que distribuyan el trabajo por cada identificador de cliente?
• Es posible que los consumidores reciban un mensaje en el orden incorrecto, debido a la latencia de red variable al enviarlos. Considere la posibilidad de usar números de secuencia para comprobar el orden. También podría incluir una marca especial de "final de secuencia" en el último mensaje de una transacción. Las tecnologías de procesamiento de flujos como Spark o Azure Stream Analytics pueden procesar mensajes en orden dentro de un período de tiempo.

Cuándo usar este patrón

Use este patrón en los siguientes supuestos:

• Tiene mensajes que llegan en orden y se deben procesar en el mismo orden.
• Los mensajes que llegan se pueden "clasificar" de manera que la categoría se convierta en una unidad de escala para el sistema.

Este patrón podría no ser adecuado en los siguientes casos:

• Escenarios de rendimiento extremadamente alto (millones de mensajes por minuto o segundo), ya que el requisito de FIFO limita el escalado que puede realizar el sistema.

Diseño de cargas de trabajo

Un arquitecto debe evaluar cómo se puede usar el patrón Sequential Convoy en el diseño de su carga de trabajo para abordar los objetivos y principios descritos en los pilares del Marco de buena arquitectura de Azure. Por ejemplo:

Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.

Ejemplo

En Azure, este patrón se puede implementar mediante sesiones de mensajes de Azure Service Bus. Para los consumidores, puede usar Logic Apps con el conector de inspección y bloqueo de Service Bus o Azure Functions con el desencadenador de Service Bus.

En el ejemplo anterior de seguimiento de pedidos, procese cada mensaje de libro de contabilidad en el orden en que se reciba y envíe cada transacción a otra cola en la que la categoría esté establecida en el identificador de pedido. En este escenario, una transacción nunca abarcará varios pedidos, por lo que los consumidores procesan cada categoría en paralelo pero con FIFO dentro de la categoría.

El procesador de libros de contabilidad distribuye los mensajes mediante la desagrupación del contenido de cada mensaje en la primera cola:

El procesador de libro de contabilidad se encarga de lo siguiente:

1. Recorrer el libro de contabilidad una transacción cada vez.
2. Establecer el id. de sesión del mensaje para que coincida con el id. de pedido.
3. Enviar cada transacción de libro de contabilidad a una cola secundaria con el id. de sesión establecido en el id. de pedido.

Los consumidores escuchan la cola secundaria, donde procesan todos los mensajes con identificadores de pedido coincidentes en orden desde la cola. Los consumidores usan el modo de inspección y bloqueo.

Al considerar la escalabilidad, la cola del libro de contabilidad es un cuello de botella principal. Las distintas transacciones registradas en el libro de contabilidad podrían hacer referencia al mismo identificador de pedido. Pero los mensajes se pueden distribuir después del libro de contabilidad al número de pedidos en un entorno sin servidor.

Pasos siguientes

La siguiente información puede resultarle de interés al implementar este patrón:

• Sesiones de mensajes: primero en entrar, primero en salir (FIFO)
• Mensaje bloqueado con peek (lectura no destructiva)
• Entrega ordenada de mensajes correlacionados en Logic Apps mediante sesiones de Service Bus (blog de MSDN)