Barramento de Serviço do Azure ꟷ expiração de mensagens (vida útil)
O conteúdo de uma mensagem ou um comando ou consulta que uma mensagem transmite para um destinatário, está quase sempre sujeito a alguma forma de prazo de expiração de nível de aplicativo. Após o prazo, o conteúdo não é mais entregue ou a operação solicitada não é mais executada. Para ambientes de desenvolvimento e teste em que as consultas e tópicos são frequentemente usadas no contexto de execuções parciais de aplicativos ou partes de aplicativos, também é desejável que as mensagens de teste presas sejam automaticamente coletadas no lixo para que a próxima execução de teste possa começar limpa.
Tempo de vida e expira em UTC
A expiração para qualquer mensagem individual pode ser controlada pela configuração da propriedade do sistema time-to-live, que especifica uma duração relativa. A expiração se torna um instante absoluto quando a mensagem é enfileirada na entidade. Nesse momento, a propriedade expires-at-utc obtém o valor enqueued-time-utc + time-to-live. A configuração da vida útil (TTL) em uma mensagem agenciada não é exigida quando não há clientes escutando ativamente.
Observação
As mensagens que expiraram podem não ser removidas imediatamente pelo agente. O agente pode optar por expirar lentamente essas mensagens, dependendo de como a entidade está sendo usada quando a mensagem expira. Por isso, os clientes podem notar que um número incorreto de mensagens ao usar a funcionalidade de expiração de mensagens e pode até se deparar com essas mensagens em uma operação de visualização preliminar. No entanto, essas mensagens expiradas não serão incluídas quando novas mensagens chegarem.
Após o instante expires-at-utc, as mensagens se tornam não qualificadas para recuperação. A expiração não afeta as mensagens que estão bloqueadas no momento para entrega. Essas mensagens ainda são manipuladas normalmente. Se o bloqueio expirar ou se a mensagem for abandonada, a expiração entrará em vigor imediatamente. Enquanto a mensagem está em um bloqueio, o aplicativo pode estar em posse de uma mensagem que expirou. Se o aplicativo está disposto a prosseguir com o processamento ou opta por abandonar a mensagem cabe ao implementador.
A TTL extremamente baixa, na ordem de milissegundos ou segundos, pode fazer com que as mensagens expirem antes que os aplicativos receptores a recebam. Considere a TTL mais alta que funciona para seu aplicativo.
Mensagens agendadas
Para mensagens agendadas, especifique o tempo de enfileiramento no qual deseja que a mensagem se materialize na fila para recuperação. O momento em que a mensagem é enviada ao Barramento de Serviço é diferente do momento em que a mensagem é enfileirada. O tempo de expiração da mensagem depende do tempo enfileirada, não da hora em que a mensagem é enviada ao Barramento de Serviço. Portanto, expires-at-utc ainda é tempo enfileirado + vida útil.
Por exemplo, se você definir ScheduledEnqueueTimeUtc como 5 minutos de UtcNow e TimeToLive para 10 minutos, a mensagem expirará após 5 + 10 = 15 minutos a partir de agora. A mensagem se materializa na fila após 5 minutos e o contador de 10 minutos começa a partir daí.
Expiração de nível de entidade
Todas as mensagens enviadas para uma fila ou tópico estão sujeitas a uma expiração padrão definida no nível de entidade. Também pode ser definida no portal durante a criação e ajustado posteriormente. A expiração padrão é usada para todas as mensagens enviadas para a entidade em que time-to-live não é definida explicitamente. A expiração padrão também funciona como um limite para o valor de time-to-live. Mensagens que têm uma expiração time-to-live maior do que o valor padrão são silenciosamente ajustadas para o valor de mensagem time-to-live padrão antes de serem enfileiradas.
O expires-at-utc é padrão. Se o TTL da mensagem não estiver definido e apenas o TTL da entidade estiver definido, então expires-at-utc será um valor computado e não será computado no caminho Peek, mas será computado no caminho Receive/Peeklock. Se a mensagem tiver TTL, essa expire-at-utc será computada no momento em que a mensagem for enviada e armazenada. Portanto, nesse caso, Peek retornará valores expires-at-utccorretos.
Observação
- O valor de vida útil padrão para uma mensagem agenciada é o maior valor possível para um número inteiro assinado de 64 bits, se não for especificado de outra forma.
- Para entidades de mensagens (filas e tópicos), o tempo de expiração padrão também é o maior valor possível para um número inteiro com sinal de 64 bits para as camadas padrão e premium do Barramento de Serviço. Para a camada básica, o tempo de expiração padrão (também máximo) é de 14 dias.
- Se o tópico especificar um TTL inferior à assinatura, o TTL do tópico é aplicado.
É possível mover mensagens expiradas para uma fila dead-letter. Você pode definir essa configuração programaticamente ou usando o portal do Azure. Se a opção estiver desabilitada, as mensagens expiradas serão descartadas. As mensagens expiradas movidas para a fila dead-letter podem ser distinguidas de outras mensagens dead-letter avaliando a propriedade razão de dead-letter que o agente armazena na seção de propriedades do usuário.
Se a mensagem está protegida contra expiração enquanto está bloqueada e se o sinalizador está definido na entidade, a mensagem é movida para a fila de mensagens mortas assim que o bloqueio for abandonado ou expirar. No entanto, ela não será movida se a mensagem for estabelecida com êxito, o que assume então que o aplicativo a manipulou com êxito, apesar da expiração nominal. Para obter mais informações sobre bloqueios e liquidação de mensagens, consulte Transferências, bloqueios e liquidação de mensagem.
A combinação de time-to-live e dead-lettering automáticas (e transacionais) na expiração são uma ferramenta valiosa para estabelecer confiança em se um trabalho atribuído a um manipulador ou um grupo de manipuladores em um prazo é recuperado para processamento conforme o prazo é alcançado.
Por exemplo, considere um site da Web que precisa executar trabalhos de forma confiável em um back-end com restrição de escala e que ocasionalmente enfrente picos de tráfego ou deseje ser isolado contra episódios de disponibilidade de tal back-end. No caso normal, o manipulador do lado do servidor para os dados de usuário enviados envia por push as informações em uma fila e subsequentemente recebe uma resposta confirmando o tratamento bem-sucedido da transação em uma fila de resposta. Se houver um aumento de tráfego e o manipulador de back-end não puder processar seus itens de lista de pendências no prazo, os trabalhos expirados serão retornados na fila dead-letter. O usuário interativo pode ser notificado de que a operação solicitada levará um pouco mais do que o normal e a solicitação poderá então ser colocada em uma fila diferente para um caminho de processamento em que o resultado do processamento eventual é enviado para o usuário por email.
Entidades temporárias
As assinaturas, os tópicos e as filas do Barramento de Serviço podem ser criadas como entidades temporárias, que são removidas automaticamente quando não forem usadas por um período de tempo especificado.
A limpeza automática é útil em cenários de desenvolvimento e teste nos quais entidades são criadas dinamicamente e não são limpas após o uso, devido a alguma interrupção do teste ou execução de depuração. Isso também é útil quando um aplicativo cria entidades dinâmicas, como uma fila de resposta, para receber respostas de volta para um processo do servidor Web, ou em outro objeto de duração relativamente curta, no qual é difícil limpar essas entidades de forma confiável quando a instância do objeto desaparecer.
O recurso é habilitado usando a propriedade exclusão automática em ociosidade no namespace. Essa propriedade é definida como a duração para a qual uma entidade pode estar ociosa (não utilizada) antes de ser excluída automaticamente. O valor mínimo para essa propriedade é 5 minutos.
Importante
Definir o nível de bloqueio do Azure Resource Manager para CanNotDelete no namespace ou em um nível superior não impede que entidades com AutoDeleteOnIdle sejam excluídas. Se não quiser que a entidade seja excluída, defina a propriedade AutoDeleteOnIdle como DataTime.MaxValue.
Ociosidade
Aqui está o que é considerado ociosidade de entidades (filas, tópicos e assinaturas):
| Entidade | O que é considerado ocioso |
|---|---|
| Fila |
|
| Tópico |
|
| Assinatura |
|
Importante
Se você tiver o encaminhamento automático configurado na fila ou assinatura, isso equivale a ter um receptor realizando recebimentos na fila ou assinatura e ele não ficará ocioso.
SDKs
Você pode definir a propriedade de tempo de vida usando Kits de Desenvolvimento de Software (SDKs).
- Para definir a vida útil em uma mensagem: .NET, Java, Python, JavaScript
- Para definir a vida útil padrão em uma fila: .NET, Java, Python, JavaScript
- Para definir a vida útil padrão em um tópico: .NET, Java, Python, JavaScript
- Para definir a vida útil padrão em uma assinatura: .NET, Java, Python, JavaScript, Python, JavaScript
Conteúdo relacionado
Se você ainda não estiver familiarizado com os conceitos do Barramento de Serviço, consulte Conceitos do Barramento de Serviçoe Filas, tópicos e assinaturas do Barramento de Serviço.
Para saber mais sobre os recursos avançados do Azure Service Bus, veja Visão geral dos recursos avançados.