Compartir por

Azure Service Bus: expiración de mensajes (TTL)

  • Artigo

La carga de un mensaje, o un comando o una consulta que transmite un mensaje a un receptor, casi siempre está sujeta a alguna forma de fecha límite de expiración de nivel de aplicación. Después de esta fecha límite, el contenido ya no se entrega o la operación solicitada ya no se ejecuta.

En los entornos de desarrollo y pruebas en los que las colas y los temas se usan a menudo en el contexto de ejecuciones parciales de aplicaciones o partes de aplicaciones, también conviene que los mensajes de prueba perdidos se recopilen automáticamente como elementos no utilizados para que la siguiente serie de pruebas pueda comenzar de forma limpia.

Nota

Si aún no está familiarizado con los conceptos de Service Bus,vea Conceptos de Service Bus y Colas, temas y suscripciones de Service Bus.

La expiración de los mensajes individuales puede controlarse mediante la propiedad del sistema time-to-live, que especifica una duración relativa. La expiración se convierte en un instante absoluto cuando el mensaje se pone en cola en la entidad. En ese momento, la propiedad expires-at-utc adopta el valor enqueued-time-utc + time-to-live. La configuración de período de vida (TTL) en un mensaje asincrónico no se aplica cuando no hay ningún cliente que escuche activamente.

Nota:

Es posible que el agente no quite inmediatamente los mensajes que han expirado. El agente puede optar por expirar estos mensajes de forma diferida, en función de si la entidad está en uso activo en el momento en que expira un mensaje. Por tanto, los clientes pueden observar un recuento de mensajes incorrecto al usar la expiración del mensaje e incluso ver estos mensajes durante una operación de inspección. Sin embargo, al recibir mensajes, no se incluirá el mensaje expirado.

Tras el instante expires-at-utc, los mensajes se vuelven inteligibles para la recuperación. La expiración no afecta a los mensajes que están bloqueados actualmente para la entrega. Esos mensajes se siguen controlando con normalidad. Si el bloqueo expira o se abandona el mensaje, la expiración surte efecto inmediato. Mientras el mensaje está bajo bloqueo, la aplicación puede estar en posesión de un mensaje que ha expirado. Es decisión del implementador que la aplicación esté dispuesta a seguir adelante con el procesamiento o elija abandonar el mensaje.

Un valor de TTL extremadamente bajo del orden de milisegundos o segundos puede hacer que los mensajes expiren antes de que las aplicaciones receptoras lo reciban. Considere la posibilidad de usar el valor de TTL más alto que funcione para su aplicación.

Nota

Para los mensajes programados, especifique la hora de puesta en cola en la que desea que el mensaje se materialice en la cola para su recuperación. La hora a la que se envía el mensaje a Service Bus es diferente de la hora a la que se pone en cola el mensaje. La hora de expiración del mensaje depende del tiempo en cola, no del momento en el que se envía el mensaje a Service Bus. Por lo tanto, el valor expires-at-utc sigue siendo tiempo en cola + período de vida.

Por ejemplo, si establece ScheduledEnqueueTimeUtc en 5 minutos desde UtcNow y TimeToLive en 10 minutos, el mensaje expirará después de 5 + 10 = 15 minutos desde ahora. El mensaje se materializa en la cola después de 5 minutos y el contador de 10 minutos comienza desde entonces.

Expiración de nivel de entidad

Todos los mensajes enviados a una cola o un tema están sujetos a una expiración predeterminada que se establece en el nivel de entidad. También se puede establecer en el portal durante la creación y ajustarse más adelante. La expiración predeterminada se usa con todos los mensajes enviados a la entidad donde time-to-live no se establece explícitamente. La expiración predeterminada también funciona como un límite superior para el valor time-to-live. Los mensajes que tienen una expiración de time-to-live más larga respecto al valor predeterminado se ajustan de forma silenciosa al valor time-to-live del mensaje antes de ponerse en cola.

Nota

  • El valor de período de vida predeterminado para un mensaje asincrónico es el valor más alto posible para un entero de 64 bits firmado, si no se especifica lo contrario.
  • En el caso de las entidades de mensajería (colas y temas), el tiempo de expiración predeterminado también es el valor más alto posible para un entero de 64 bits firmado para los niveles estándar y prémium de Service Bus. En el nivel básico, el tiempo de expiración predeterminado (también máximo) es de 14 días.
  • Si el tema especifica un TTL menor que la suscripción, se aplica el TTL del tema.

De forma opcional, los mensajes expirados se pueden mover a una cola de mensajes con problemas de entrega. Puede configurar esta opción mediante programación o en Azure Portal. Si la opción se deja deshabilitada, se quitan los mensajes que han expirado. Los mensajes expirados movidos a la cola de mensajes con problemas de entrega se pueden distinguir de otros mensajes con problemas de entrega mediante la evaluación de la propiedad dead-letter reason que el agente almacena en la sección de propiedades del usuario.

Si el que el mensaje está protegido de la expiración mientras está bajo bloqueo y si la marca se establece en la entidad, el mensaje se mueve a la cola de mensajes fallidos cuando se abandone el bloqueo o este expire. Sin embargo, no se mueve si el mensaje se ha liquidado correctamente, y se asume entonces que la aplicación ha podido gestionarlo correctamente, a pesar de la expiración nominal. Para obtener más información sobre los bloqueos de mensajes y la liquidación, vea Transferencias de mensajes, bloqueos y liquidación.

La combinación de time-to-live y las colas automáticas y transaccionales de mensajes con problemas de entrega cuando ocurre la expiración es una valiosa herramienta para establecer confianza en si un trabajo proporcionado a un controlador o un grupo de controladores con una fecha límite se recupera para el procesamiento cuando se alcance dicha fecha límite.

Por ejemplo, imagine un sitio web que necesita ejecutar trabajos de forma confiable en un back-end con restricción de escala, y que experimenta de vez en cuando picos de tráfico o quiere aislarse contra episodios de ese back-end. En el caso normal, el controlador del lado servidor de los datos de usuario enviados inserta la información en una cola y, como consecuencia, recibe una respuesta para confirmar que se ha gestionado correctamente la transacción a una cola de respuestas. Si hay un aumento del tráfico y el controlador de back-end no puede procesar sus elementos de trabajo pendiente a tiempo, los trabajos que han expirado se devuelven a la cola de mensajes con problemas de entrega. El usuario interactivo puede recibir la notificación de que la operación solicitada tarda un poco más de lo normal, y la solicitud se puede colocar entonces en una cola diferente en una ruta de acceso de procesamiento donde el resultado final de dicho procesamiento se envía al usuario por correo electrónico.

Entidades temporales

Las colas, los temas y las suscripciones de Service Bus se pueden crear como entidades temporales, que se eliminan automáticamente cuando no se han usado durante un período de tiempo especificado.

La limpieza automática resulta útil en escenarios de desarrollo y pruebas en los que las entidades se crean dinámicamente y no se limpian tras su uso debido a alguna interrupción de la ejecución de la depuración o prueba. También es útil cuando una aplicación crea entidades dinámicas, como una cola de respuestas, para volver a recibir respuestas en un proceso de servidor web, o en otro objeto de duración relativamente corta donde resulta difícil limpiar esas entidades de forma confiable cuando la instancia del objeto desaparece.

La característica se habilita mediante la eliminación automática en la propiedad inactiva de la entidad. Esta propiedad se establece en el período durante el cual una entidad debe estar inactiva (sin usar) antes de que se elimine automáticamente. El valor mínimo para esta propiedad es de 5 minutos.

Importante

Establecer el nivel de bloqueo de Azure Resource Manager en CanNotDelete, en el espacio de nombres o en un nivel superior, no impide que se eliminen las entidades con AutoDeleteOnIdle. Si no quiere que se elimine la entidad, establezca la propiedad AutoDeleteOnIdle en DataTime.MaxValue.

Inactividad

Esto es lo que se considera inactividad de las entidades (colas, temas y suscripciones):

Entidad Qué se considera inactivo
Cola
  • No envía
  • No recibe
  • No hay actualizaciones a la cola
  • No hay mensajes programados
  • No hay navegación o inspección
Tema
  • No envía
  • No hay actualizaciones al tema
  • No hay mensajes programados
  • Ninguna operación en las suscripciones del tema (vea la siguiente fila)
Suscripción
  • No recibe
  • No hay actualizaciones a la suscripción
  • No se han agregado nuevas reglas a la suscripción
  • No hay navegación o inspección

Importante

Si tiene la configuración de reenvío automático en la cola o suscripción, es equivalente a que un receptor haga recepciones en la cola o la suscripción y no estará inactivo.

SDK

Pasos siguientes

Para más información sobre la mensajería de Service Bus, consulte los siguientes artículos: