Compartir vía

Sesiones de mensajes

  • Artículo

Las sesiones de Azure Service Bus permiten la administración ordenada y conjunta de secuencias sin enlace de mensajes relacionados. Se pueden usar sesiones en patrones FIFO (primero en entrar, primero en salir) y de solicitud-respuesta. En este artículo se muestra cómo usar sesiones para implementar estos patrones al utilizar Service Bus.

Nota

El nivel Básico de Service Bus no admite sesiones. Los niveles Estándar y Premium admiten sesiones. Para conocer las diferencias entre estos niveles, consulte Precios de Service Bus.

Patrón FIFO (primero en entrar, primero en salir)

Para realizar una garantía FIFO en el procesamiento de mensajes en colas o suscripciones de Service Bus, use sesiones. Service Bus no prescribe la naturaleza de la relación entre los mensajes, y tampoco define un modelo concreto para determinar dónde comienza o termina una secuencia de mensajes.

Cualquier remitente puede crear una sesión al enviar mensajes a un tema o una cola si se establece la propiedad Id. de sesión en algún identificador definido por la aplicación que sea único para la sesión. En el nivel de protocolo AMQP 1.0, este valor se asigna a la propiedad group-id.

En las colas o suscripciones basadas en sesiones, las sesiones existen cuando hay al menos un mensaje con el id. sesión. Una vez que una sesión existe, no hay ningún tiempo o API definidos para cuando la sesión expira o desaparece. En teoría, se puede recibir un mensaje para una sesión hoy y el siguiente mensaje en un año, pero si el id. de sesión coincide, la sesión será la misma desde la perspectiva de Service Bus.

Por lo general, sin embargo, una aplicación tiene una noción clara de dónde comienza o termina un conjunto de mensajes relacionados. Service Bus no establece ninguna regla específica. Por ejemplo, la aplicación puede establecer la propiedad Label del primer mensaje en start, de los mensajes intermedios en content y del último mensaje en end. La posición relativa de los mensajes de contenido se puede calcular como la diferencia de SequenceNumber del mensaje actual a partir del valor SequenceNumber del mensaje de inicio.

Importante

Cuando las sesiones están habilitadas en una cola o una suscripción, las aplicaciones cliente ya no pueden enviar ni recibir mensajes normales. Todos los mensajes se deben enviar como parte de una sesión (estableciendo el id. de sesión) y recibirlos mediante la aceptación de la sesión. Los clientes todavía pueden ver una cola o una suscripción que tenga habilitadas las sesiones. Consulte Exploración de mensajes.

Las API de las sesiones existen en los clientes de colas y suscripciones. Hay un modelo imperativo, que controla cuándo se reciben mensajes y sesiones, y un modelo basado en controlador, que oculta la complejidad de la administración del bucle de recepción.

Para obtener ejemplos, use los vínculos de la sección Pasos siguientes.

Características de las sesiones

Las sesiones proporcionan la demultiplexación simultánea de flujos de mensajes intercalados, al tiempo que se conserva y garantiza la entrega ordenada.

Diagram that shows how the Sessions feature preserves an ordered delivery.

El cliente que acepta una sesión crea un receptor de sesión. Cuando un cliente acepta y conserva la sesión, el cliente mantiene un bloqueo exclusivo sobre todos los mensajes con ese id. de sesión en la cola o suscripción. Contiene bloqueos exclusivos en todos los mensajes con el id. de sesión que llega más adelante.

El bloqueo se libera cuando se llama a los métodos de cierre en el receptor o cuando expira el bloqueo. También hay métodos en el receptor para renovar los bloqueos. En su lugar, puede usar la característica de renovación automática de bloqueos, donde puede especificar el tiempo durante el que desea seguir renovando el bloqueo. El bloqueo de sesión debe tratarse como un bloqueo exclusivo en un archivo, lo que significa que la aplicación debería cerrar la sesión en cuanto ya no lo necesite o no espere ningún otro mensaje.

Cuando varios receptores simultáneos se extraen de la cola, los mensajes que pertenecen a una sesión determinada se envían al receptor específico que actualmente mantiene el bloqueo en esa sesión. Con esa operación, una secuencia de mensajes intercalados en una cola o suscripción se demultiplexa limpiamente en receptores diferentes y esos receptores también pueden encontrarse en distintas máquinas cliente, puesto que la administración del bloqueo tiene lugar en el servidor, dentro de Service Bus.

La ilustración anterior muestra tres receptores de sesiones simultáneas. Una sesión con SessionId = 4 no tiene ningún cliente activo, propietario, lo que significa que no se entregan mensajes de esta sesión concreta. Una sesión actúa de muchas maneras, como de subcola.

El bloqueo de sesión mantenido por el receptor de sesión sirve de protección para los bloqueos de mensaje usados en el modo de usado en el modo de liquidación bloqueo de inspección. No puede haber más de un receptor que tenga un bloqueo en una sesión. Un receptor puede tener muchos mensajes en curso, pero los mensajes se reciben en orden. Abandonar un mensaje hace que el mismo mensaje se sirva de nuevo en la siguiente operación de recepción.

Estado de la sesión de mensaje

Cuando se procesan flujos de trabajo en sistemas de nube de gran escala y alta disponibilidad, el controlador del flujo de trabajo asociado con una sesión determinada debe ser capaz de recuperarse de errores inesperados y también de reanudar el trabajo finalizado parcialmente en un proceso o una máquina diferentes de aquellos donde comienza el trabajo.

El servicio de estado de sesión permite una anotación definida por la aplicación de una sesión de mensajes en el agente, de modo que el estado de procesamiento registrado con respecto a esa sesión deja de estar disponible al instante cuando un nuevo procesador adquiere la sesión.

Desde el punto de vista de Service Bus, el estado de la sesión de mensajes es un objeto binario opaco que puede contener datos del tamaño de un mensaje, que es de 256 KB en el caso de Service Bus Estándar y 100 MB en el de Service Bus Prémium. El estado de procesamiento relativo a una sesión puede estar contenido en el estado de sesión, o el estado de sesión puede apuntar a alguna ubicación de almacenamiento o registro de base de datos que contiene dicha información.

Los métodos para administrar el estado de sesión, SetState y GetState, se encuentran en el objeto de receptor de sesión. Una sesión sin estado de sesión anterior devuelve una referencia nula para GetState. El estado de sesión establecido anteriormente se puede borrar pasando null al método SetState en el receptor.

El estado de sesión permanecerá siempre y cuando no se borre (se devuelva null), incluso si se consumen todos los mensajes de una sesión.

El estado de sesión mantenido en una cola o en que una suscripción se tiene en cuenta en la cuota de almacenamiento de esa entidad. Cuando la aplicación se termina con una sesión, se recomienda por lo tanto que dicha aplicación limpie su estado retenido para evitar costos de administración externos.

Efecto del recuento de entregas

La definición de recuento de entregas por mensaje en el contexto de las sesiones varía ligeramente de la definición cuando no hay sesiones. En esta tabla se resume cuándo se incrementa el recuento de entregas.

Escenario Se incrementa el recuento de entregas del mensaje
Se acepta la sesión, pero el bloqueo de la sesión expira (debido al tiempo de espera) Sí
Se acepta la sesión, los mensajes de la sesión no se completan (aunque estén bloqueados) y la sesión se cierra. No
Se acepta la sesión, se completan los mensajes y, luego, la sesión se cierra explícitamente. N/A (es el flujo estándar. Aquí se quitan los mensajes de la sesión)

Patrón de solicitud-respuesta

El patrón de solicitud-respuesta es un modelo de integración bien establecido que permite a la aplicación remitente enviar una solicitud y proporciona una manera de que el receptor envíe correctamente una respuesta a la aplicación remitente. Normalmente, este patrón necesita una cola o un tema de corta duración a los que la aplicación envíe respuestas. En este escenario, las sesiones proporcionan una solución alternativa sencilla con semántica comparable.

Varias aplicaciones pueden enviar sus solicitudes a una única cola de solicitudes, con un parámetro de encabezado específico establecido para identificar de forma única a la aplicación remitente. La aplicación receptora puede procesar las solicitudes que entran en la cola y enviar respuestas en una cola habilitada para sesiones, de forma que el identificador de sesión se establezca en el identificador único que el remitente había enviado en el mensaje de solicitud. La aplicación que envió la solicitud puede recibir luego mensajes en un identificador de sesión específico y procesar correctamente las respuestas.

Nota

La aplicación que envía las solicitudes iniciales debe conocer el id. de sesión y usarlo para aceptar la sesión, de modo que se bloquee la sesión en la que se espera la respuesta. Se recomienda usar un GUID que identifique de forma única la instancia de la aplicación como un id. de sesión. No debe haber ningún controlador de sesión o un tiempo de espera especificado en el receptor de la sesión para la cola a fin de garantizar que las respuestas estén disponibles para que las bloqueen y procesen destinatarios específicos.

Secuenciación en comparación con el uso de sesiones

El número de secuencia por sí solo garantiza el orden de puesta en cola y el orden de extracción de los mensajes, pero no el orden de procesamiento, para el que se requieren sesiones.

Supongamos que hay tres mensajes en la cola y dos consumidores.

  1. El consumidor 1 selecciona el mensaje 1.
  2. El consumidor 2 selecciona el mensaje 2.
  3. El consumidor 2 termina de procesar el mensaje 2 y selecciona el mensaje 3, mientras que el consumidor 1 aún no ha terminado con el procesamiento del mensaje 1.
  4. El consumidor 2 termina de procesar el mensaje 3 pero el consumidor 1 aún no ha terminado con el procesamiento del mensaje 1.
  5. Por último, el consumidor 1 completa el procesamiento del mensaje 1.

Por lo tanto, los mensajes se procesan en este orden: mensaje 2, mensaje 3 y mensaje 1. Si necesita que los mensajes 1, 2 y 3 se procesen en orden, debe usar sesiones.

Si los mensajes solo necesitan ser recuperados en orden, no es necesario usar sesiones. Pero si los mensajes deben procesarse en orden, use sesiones. El mismo identificador de sesión debe establecerse en los mensajes que van juntos, que podrían ser los mensajes 1, 4 y 8 de un conjunto, y 2, 3 y 6 de otro conjunto.

Expiración de mensajes

En el caso de las colas habilitadas para sesiones o las suscripciones a temas, los mensajes se bloquean a nivel de sesión. Si el TTL de cualquiera de los mensajes expira, todos los mensajes relacionados con esa sesión se anulan o se envían mensajes fallidos en función de la configuración de mensajes fallidos habilitada en la configuración de expiración de mensajería en la entidad. Es decir, si hay un solo mensaje en la sesión que ha superado el TTL, todos los mensajes de la sesión están caducados. Los mensajes expiran solo si hay un agente de escucha activo. Para más información, consulte Expiración de mensajes.

Pasos siguientes

Puede habilitar sesiones de mensajes mientras crea una cola mediante Azure Portal, PowerShell, la CLI, una plantilla de Resource Manager, .NET, Java, Python y JavaScript. Para más información, consulte Habilitación de sesiones de mensajes.

Pruebe los ejemplos en el lenguaje que prefiera para explorar las características de Azure Service Bus.