Barramento de Serviço do Azure ꟷ expiração de mensagens (vida útil)

  • Artigo

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.

Observação

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.

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.

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.

Observação

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.

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.

Expiração para entidades habilitadas para sessão

Para filas habilitadas para sessão ou assinaturas de tópicos, as mensagens são bloqueadas no nível da sessão. Se o TTL de qualquer uma das mensagens expirar, todas as mensagens relacionadas a essa sessão serão descartadas ou com letras mortas, com base na letra morta habilitada na configuração de expiração de mensagens na entidade. Em outras palavras, se houver uma única mensagem na sessão que tenha passado o TTL, todas as mensagens na sessão expirarão. As mensagens expirarão somente se houver um ouvinte ativo.

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
  • Não há envios
  • Não recebe
  • Não há atualizações para a fila
  • Não há mensagens agendadas
  • Não pesquisar/inspecionar
Tópico
  • Não há envios
  • Não há atualizações para o tópico
  • Não há mensagens agendadas
  • Nenhuma operação nas assinaturas do tópico (consulte a próxima linha)
Assinatura
  • Não recebe
  • Não há atualizações para a assinatura
  • Não há novas regras adicionadas à assinatura
  • Não pesquisar/inspecionar

Importante

Se você tiver configuração de encaminhamento automático na fila ou assinatura, isso equivale a ter um receptor na fila ou assinatura e eles não ficarão ociosos.

SDKs

Próximas etapas

Para saber mais sobre as mensagens do Barramento de Serviço, confira os artigos a seguir: