Partilhar via

Azure Service Bus - Expiração da mensagem (Time to Live)

  • Artigo

A carga útil em uma mensagem, ou um comando ou consulta que uma mensagem transmite a um recetor, está quase sempre sujeita a algum tipo de prazo de expiração no nível do aplicativo. Após esse prazo, o conteúdo não é mais entregue, ou a operação solicitada não é mais executada.

Para ambientes de desenvolvimento e teste nos quais filas e tópicos são frequentemente usados no contexto de execuções parciais de aplicativos ou partes de aplicativos, também é desejável que mensagens de teste bloqueadas sejam coletadas automaticamente para que a próxima execução de teste possa começar limpa.

Nota

Se você ainda não estiver familiarizado com os conceitos do Service Bus, consulte Conceitos do Service Bus e filas, tópicos e assinaturas do Service Bus.

A expiração de qualquer mensagem individual pode ser controlada definindo a propriedade time-to-live system, que especifica uma duração relativa. A expiração torna-se um instante absoluto quando a mensagem é enfileirada na entidade. Nesse momento, a propriedade expires-at-utc assume o valor enqueued-time-utc + time-to-live. A configuração de tempo de vida (TTL) em uma mensagem intermediada não é imposta quando não há clientes escutando ativamente.

Nota

As mensagens que expiraram podem não ser removidas imediatamente pelo corretor. O corretor pode optar por expirar preguiçosamente essas mensagens, com base em se a entidade está em uso ativo no momento em que uma mensagem expira. Consequentemente, os clientes podem observar uma contagem incorreta de mensagens ao usar a expiração de mensagens e podem até ver essas mensagens durante uma operação de visualização. No entanto, ao receber mensagens, a mensagem expirada não será incluída.

Após o instante expirar no utc, as mensagens tornam-se inelegíveis para recuperação. A expiração não afeta as mensagens que estão atualmente bloqueadas para entrega. Essas mensagens ainda são tratadas normalmente. Se o bloqueio expirar ou a mensagem for abandonada, a expiração terá efeito imediato. Enquanto a mensagem estiver bloqueada, 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.

TTL extremamente baixo na ordem de milissegundos ou segundos pode fazer com que as mensagens expirem antes que os aplicativos recetores as recebam. Considere o TTL mais alto que funciona para seu aplicativo.

Nota

Para mensagens agendadas, especifique o tempo de fila no qual deseja que a mensagem se materialize na fila para recuperação. A hora em que a mensagem é enviada para o Service Bus é diferente da hora em que a mensagem é enfileirada. O tempo de expiração da mensagem depende do tempo enfileirado, não do momento em que a mensagem é enviada para o Service Bus. Portanto, o expira-at-utc ainda é tempo enfileirado + tempo de vida.

Por exemplo, se você definir o ScheduledEnqueueTimeUtc para 5 minutos de UtcNow, e TimeToLive para 10 minutos, a mensagem expirará após 5 + 10 = 15 minutos a partir de agora. A mensagem materializa-se na fila após 5 minutos e o contador de 10 minutos começa a partir daí.

Expiração no nível da entidade

Todas as mensagens enviadas para uma fila ou tópico estão sujeitas a uma expiração padrão definida no nível da entidade. Também pode ser definido no portal durante a criação e ajustado posteriormente. A expiração padrão é usada para todas as mensagens enviadas para a entidade onde o tempo de vida não está definido explicitamente. A expiração padrão também funciona como um teto para o valor de tempo de vida. As mensagens que têm uma expiração de tempo de vida mais longa do que o valor padrão são silenciosamente ajustadas para o valor padrão de tempo de vida da mensagem antes de serem enfileiradas.

Nota

  • O valor padrão de tempo de vida para uma mensagem intermediada é o maior valor possível para um inteiro de 64 bits assinado, se não 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 inteiro de 64 bits assinado para as camadas padrão e premium do Service Bus. 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 menor do que a assinatura, o TTL do tópico será aplicado.

Opcionalmente, as mensagens expiradas podem ser movidas para uma fila de mensagens mortas. Você pode definir essa configuração programaticamente ou usando o portal do Azure. Se a opção for deixada desativada, as mensagens expiradas serão descartadas. As mensagens expiradas movidas para a fila de letras mortas podem ser distinguidas de outras mensagens com letras mortas avaliando a propriedade de razão de letra morta que o agente armazena na seção de propriedades do usuário.

Se a mensagem estiver protegida contra expiração enquanto estiver bloqueada e se o sinalizador estiver definido na entidade, a mensagem será movida para a fila de letras mortas à medida que o bloqueio for abandonado ou expirar. No entanto, ele não é movido se a mensagem for liquidada com êxito, o que pressupõe 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 mensagens.

A combinação de time-to-live e dead-lettering automático (e transacional) no vencimento é uma ferramenta valiosa para estabelecer a confiança em saber se um trabalho dado a um manipulador ou a um grupo de manipuladores dentro de um prazo é recuperado para processamento à medida que o prazo é atingido.

Por exemplo, considere um site que precisa executar trabalhos de forma confiável em um back-end com restrição de escala e que ocasionalmente enfrenta picos de tráfego ou deseja ser isolado contra episódios de disponibilidade desse back-end. No caso normal, o manipulador do lado do servidor para os dados do usuário enviados envia as informações para uma fila e, posteriormente, recebe uma resposta confirmando o tratamento bem-sucedido da transação em uma fila de resposta. Se houver um pico de tráfego e o manipulador de back-end não puder processar seus itens da lista de pendências a tempo, os trabalhos expirados serão retornados na fila de mensagens mortas. O usuário interativo pode ser notificado de que a operação solicitada leva um pouco mais de tempo do que o normal, e a solicitação pode ser colocada em uma fila diferente para um caminho de processamento onde o resultado do processamento final é enviado ao usuário por e-mail.

Entidades temporárias

Filas, tópicos e assinaturas do Barramento de Serviço podem ser criados como entidades temporárias, que são removidas automaticamente quando não foram usadas por um período de tempo especificado.

A limpeza automática é útil em cenários de desenvolvimento e teste nos quais as 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. Também é útil quando um aplicativo cria entidades dinâmicas, como uma fila de respostas, para receber respostas de volta em um processo de servidor Web ou em outro objeto de vida relativamente curta onde é difícil limpar essas entidades de forma confiável quando a instância do objeto desaparece.

O recurso é habilitado usando a propriedade auto delete on idle na entidade. Esta propriedade é definida para a duração durante a qual uma entidade deve estar ociosa (não utilizada) antes de ser excluída automaticamente. O valor mínimo para esta propriedade é de 5 minutos.

Importante

Definir o nível de bloqueio do Azure Resource Manager como CanNotDelete, no namespace ou em um nível superior não impede que entidades com AutoDeleteOnIdle sejam excluídas. Se você não quiser que a entidade seja excluída, defina a AutoDeleteOnIdle propriedade como DataTime.MaxValue.

Ociosidade

Veja o que considerou ociosidade de entidades (filas, tópicos e assinaturas):

Entidade O que é considerado ocioso
Queue
  • Sem envios
  • Não recebe
  • Sem atualizações na fila
  • Sem mensagens agendadas
  • Sem navegar/espreitar
Tópico
  • Sem envios
  • Sem atualizações do tópico
  • Sem mensagens agendadas
  • Nenhuma operação nas assinaturas do tópico (veja a próxima linha)
Subscrição
  • Não recebe
  • Sem atualizações à subscrição
  • Nenhuma nova regra adicionada à assinatura
  • Sem navegar/espreitar

Importante

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

SDKs

Próximos passos

Para saber mais sobre as mensagens do Service Bus, consulte os seguintes artigos: