Compartir a través de

Sesiones de mensajes

Las sesiones de Azure Service Bus permiten el procesamiento conjunto y ordenado de secuencias sin enlazar de mensajes relacionados. Sesiones se pueden usar en patrones de primero en entrar, primero en salir (FIFO) y de solicitud-respuesta. En este artículo se muestra cómo usar sesiones para implementar estos patrones al usar 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 lograr el procesamiento de FIFO en el procesamiento de mensajes de las colas o suscripciones de Service Bus, use sesiones. Service Bus no es prescriptivo sobre la naturaleza de la relación entre los mensajes y tampoco define un modelo determinado para determinar dónde se inicia o finaliza una secuencia de mensajes.

Un remitente puede iniciar una sesión al enviar mensajes a un tema o cola estableciendo la propiedad id. de sesión en un identificador único definido por la aplicación. En el nivel de protocolo AMQP 1.0 , este valor se asigna a la propiedad group-id .

En las colas o suscripciones compatibles con la sesión, las sesiones existen cuando hay al menos un mensaje con el identificador de sesión. Una vez que existe una sesión, no hay ninguna hora definida o API para cuando la sesión expira o desaparece. Teóricamente, se puede recibir un mensaje para una sesión hoy, el siguiente mensaje en un año, y si el identificador de sesión coincide, la sesión es la misma desde la perspectiva del Service Bus.

Sin embargo, normalmente, una aplicación define dónde se inicia y finaliza un conjunto de mensajes relacionados. Service Bus no impone ninguna regla específica. Por ejemplo, la aplicación podría establecer la propiedad Label para el primer mensaje como inicio, para los mensajes intermedios como contenido y para que el último mensaje finalice. La posición relativa de los mensajes de contenido se puede calcular como la diferencia del SequenceNumber del mensaje actual con el SequenceNumber del mensaje inicial.

Importante

Cuando las sesiones están habilitadas en una cola o una suscripción, las aplicaciones cliente ya no pueden enviar o recibir mensajes normales. Los clientes deben enviar mensajes como parte de una sesión, estableciendo el identificador de sesión, y recibirlos aceptando la sesión. Es posible que los clientes sigan viendo 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 cola y suscripción. Hay dos maneras de recibir sesiones y mensajes: el modelo imperativo, donde se controla manualmente cuándo y cómo se reciben los mensajes, y el modelo basado en el controlador, lo que simplifica las cosas mediante la administración automática del bucle de mensajes y el procesamiento.

Para obtener ejemplos, use vínculos en la sección Ejemplos .

Características de sesiones

Las sesiones proporcionan desmultiplexación simultánea de secuencias de mensajes intercaladas al tiempo que conservan y garantizan la entrega ordenada.

Diagrama que muestra cómo la función Sesiones conserva una entrega ordenada.

Un cliente crea un receptor de sesión para aceptar una sesión. Cuando el cliente acepta y mantiene una sesión, mantiene un bloqueo exclusivo en todos los mensajes con el Id. de sesión de esa 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 la duración del tiempo durante el que desea mantener la renovación del bloqueo. El bloqueo de sesión debe tratarse como un bloqueo exclusivo en un archivo, lo que significa que la aplicación debe cerrar la sesión tan pronto como ya no la necesite o no espere ningún mensaje adicional.

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 desmultiplexa limpiamente en receptores diferentes y esos receptores también pueden encontrarse en distintas máquinas cliente, ya que la administración del bloqueo tiene lugar en el servidor, dentro de Service Bus.

En la ilustración anterior se muestran tres receptores de sesión simultáneos. Una sesión con SessionId = 4 no tiene ningún cliente activo y propietario, lo que significa que no se entrega ningún mensaje desde esta sesión específica. Una sesión actúa de muchas maneras como una sub cola.

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. Solo un receptor puede tener 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 se vuelva a atender el mismo mensaje con la siguiente operación de recepción.

Estado de sesión del mensaje

Cuando los flujos de trabajo se procesan en sistemas en la nube a gran escala y de alta disponibilidad, el controlador de flujo de trabajo asociado a una sesión determinada debe poder recuperarse de errores inesperados y puede reanudar el trabajo completado parcialmente en un proceso o máquina diferente desde donde comenzó el trabajo.

La funcionalidad de estado de sesión permite una anotación definida por la aplicación para una sesión de mensajes dentro del intermediario, de modo que el estado de procesamiento registrado en relación con esa sesión esté disponible instantáneamente cuando la sesión sea adquirida por un nuevo procesador.

Desde la perspectiva de Service Bus, el estado de sesión del mensaje es un objeto binario opaco que puede contener datos del tamaño de un mensaje, que es de 256 KB para Service Bus Standard y 100 MB para Service Bus Premium. El estado de procesamiento relativo a una sesión se puede mantener dentro del 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 pueden encontrar en el objeto receptor de sesión. Una sesión que anteriormente no tenía ningún estado de sesión 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 permanece siempre que no se borre (devolviendo null), aunque se consuman 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 termine con una sesión, se recomienda por tanto que esta limpie su estado almacenado para evitar el coste de gestión externa.

Impacto del recuento de entregas

La definición del recuento de entregas por mensaje en el contexto de las sesiones varía ligeramente de la definición en ausencia de sesiones. Esta es una tabla que se resume cuando 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í
La sesión se acepta, los mensajes dentro de la sesión no se completan (incluso si están bloqueados) y la sesión se cierra. No
La sesión se acepta, se completan los mensajes y, a continuación, se cierra explícitamente la sesión. N/A (es el flujo estándar. Aquí, los mensajes se quitan de la sesión).

Patrón de solicitud-respuesta

El patrón de solicitud-respuesta es un patrón 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 sola cola de solicitudes, con un parámetro de encabezado específico establecido para identificar de forma única la aplicación remitente. La aplicación receptora puede procesar las solicitudes que vienen en la cola y enviar respuestas en la cola habilitada para la sesión, estableciendo el identificador de sesión en el identificador único que el remitente había enviado en el mensaje de solicitud. La aplicación que envió la solicitud puede recibir mensajes en el identificador de sesión específico y procesar correctamente las respuestas.

Nota:

La aplicación que envía las solicitudes iniciales debe conocer el identificador de sesión y usarlo para aceptar la sesión para que la sesión en la que espera la respuesta esté bloqueada. Se recomienda usar un GUID que identifique de forma única la instancia de la aplicación como identificador de sesión. No debe haber ningún controlador de sesión o un tiempo de espera especificado en el receptor de sesión de la cola para asegurarse de que las respuestas están disponibles para que los receptores específicos bloqueen y procesen las respuestas.

Secuenciación frente a sesiones

El número de secuencia por sí mismo garantiza el orden de puesta en cola y el orden de extracción de mensajes, pero no el orden de procesamiento, que requiere 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. Consumidor 2 termina de procesar el mensaje 2 y recoge el mensaje 3, mientras que Consumidor 1 aún no ha terminado de procesar el mensaje 1.
  4. El consumidor 2 termina de procesar el mensaje 3, pero el consumidor 1 todavía no ha terminado de procesar el 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 solo es necesario recuperar mensajes 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 pertenecen juntos, que podrían ser el mensaje 1, 4 y 8 en un conjunto, y 2, 3 y 6 en otro conjunto.

Expiración del mensaje

En el caso de las colas o suscripciones a temas habilitados para sesión, los mensajes se bloquean a nivel de sesión. Si expira el período de vida (TTL) para cualquiera de los mensajes, todos los mensajes relacionados con esa sesión se quitan 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 único mensaje en la sesión que ha pasado el TTL, todos los mensajes de la sesión han expirado. Los mensajes expiran solo si hay un agente de escucha activo. Para obtener más información, consulte Expiración de mensajes.

Muestras

Puede habilitar sesiones de mensajes al crear una cola mediante Azure Portal, PowerShell, CLI, plantilla de Resource Manager, .NET, Java, Python y JavaScript. Para obtener más información, vea Habilitar sesiones de mensajes.

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

Contenido relacionado