Share via

Pré-buscar mensagens do Barramento de Serviço do Azure

  • Artigo

Quando você ativa o recurso de pré-busca para qualquer um dos clientes oficiais do Service Bus, o recetor adquire mais mensagens do que o que o aplicativo pediu inicialmente, até a contagem de pré-busca especificada. À medida que as mensagens são retornadas ao aplicativo, o cliente adquire mais mensagens em segundo plano, para preencher o buffer de pré-busca.

Ativar Obtenção Prévia

Para habilitar o recurso de pré-busca, defina a contagem de pré-busca da fila ou do cliente de assinatura como um número maior que zero. Definir o valor como zero desativa a pré-busca.

Defina a propriedade prefetch count nos objetos ServiceBusReceiver e ServiceBusProcessor .

Nota

O Java Script SDK não suporta o recurso de pré-busca .

Enquanto as mensagens estão disponíveis no buffer de pré-busca, todas as chamadas de recebimento subsequentes são imediatamente atendidas a partir do buffer. O buffer é reabastecido em segundo plano à medida que o espaço fica disponível. Se não houver mensagens disponíveis para entrega, a operação de recebimento esvazia o buffer e, em seguida, aguarda ou bloqueia, conforme o esperado.

Por que a pré-busca não é a opção padrão?

A pré-busca acelera o fluxo de mensagens ao ter uma mensagem prontamente disponível para recuperação local antes que o aplicativo solicite uma. Esse ganho de taxa de transferência é o resultado de uma compensação que o autor do aplicativo deve fazer explicitamente.

Quando você usa o modo de recebimento e exclusão , todas as mensagens adquiridas no buffer de pré-busca não estão mais disponíveis na fila. As mensagens permanecem apenas no buffer de pré-busca na memória até serem recebidas no aplicativo. Se o aplicativo terminar antes que as mensagens sejam recebidas no aplicativo, essas mensagens serão irrecuperáveis (perdidas).

Quando você usa o modo de recebimento peek lock , as mensagens buscadas no buffer de pré-busca são adquiridas no buffer em um estado bloqueado. Eles têm o relógio de tempo limite para o tique-taque de bloqueio. Se o buffer de pré-busca for grande e o processamento demorar tanto que os bloqueios de mensagem expiram enquanto permanecem no buffer de pré-busca ou mesmo enquanto o aplicativo está processando a mensagem, pode haver alguns eventos confusos para o aplicativo manipular. O aplicativo pode adquirir uma mensagem com um bloqueio expirado ou expirando iminentemente. Em caso afirmativo, o aplicativo pode processar a mensagem, mas descobrir que não pode concluí-la devido a uma expiração de bloqueio. O aplicativo pode verificar a propriedade (que está sujeita a LockedUntilUtc distorção de relógio entre o corretor e o relógio da máquina local).

Se o bloqueio de mensagem tiver expirado, o aplicativo deverá ignorá-la e não deverá fazer nenhuma chamada de API na mensagem. Se a mensagem não tiver expirado, mas a expiração for iminente, o bloqueio poderá ser renovado e estendido por outro período de bloqueio padrão. Se o bloqueio expirar silenciosamente no buffer de pré-busca, a mensagem será tratada como abandonada e será novamente disponibilizada para recuperação da fila. Isso pode fazer com que a mensagem seja buscada no buffer de pré-busca e colocada no final. Se o buffer de pré-busca geralmente não puder ser trabalhado durante a expiração da mensagem, as mensagens serão repetidamente pré-buscadas, mas nunca efetivamente entregues em um estado utilizável (validamente bloqueado) e, eventualmente, serão movidas para a fila de mensagens mortas quando a contagem máxima de entrega for excedida.

Se um aplicativo abandonar explicitamente uma mensagem, a mensagem pode estar novamente disponível para recuperação da fila. Quando a pré-busca está ativada, a mensagem é buscada no buffer de pré-busca novamente e colocada no final. Como as mensagens do buffer de pré-busca são drenadas na ordem FIFO (first-in, first-out), o aplicativo pode receber mensagens fora de ordem. Por exemplo, o aplicativo pode receber uma mensagem com ID 2 e, em seguida, uma mensagem com ID 1 (que foi abandonada anteriormente) do buffer.

Se você precisa de um alto grau de confiabilidade para o processamento de mensagens, e o processamento leva trabalho e tempo significativos, recomendamos que você use o recurso de pré-busca de forma conservadora, ou não use nada. Se você precisar de alta taxa de transferência e o processamento de mensagens for geralmente barato, a pré-busca produz benefícios significativos de taxa de transferência.

A contagem máxima de pré-busca e a duração do bloqueio configuradas na fila ou na assinatura precisam ser balanceadas para que o tempo limite de bloqueio exceda pelo menos o tempo de processamento de mensagem acumulado esperado para o tamanho máximo do buffer de pré-busca, além de uma mensagem. Ao mesmo tempo, o tempo limite de bloqueio não deve ser tão longo que as mensagens possam exceder seu tempo máximo de vida quando são acidentalmente descartadas, exigindo assim que seu bloqueio expire antes de ser entregue novamente.

Próximos passos

Experimente os exemplos no idioma de sua escolha para explorar os recursos do Barramento de Serviço do Azure.

Exemplos para as bibliotecas de cliente .NET e Java mais antigas:

Em 30 de setembro de 2026, desativaremos as bibliotecas do SDK do Barramento de Serviço do Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, que não estão em conformidade com as diretrizes do SDK do Azure. Também encerraremos o suporte ao protocolo SBMP, para que você não possa mais usar esse protocolo após 30 de setembro de 2026. Migre para as bibliotecas mais recentes do SDK do Azure, que oferecem atualizações de segurança críticas e recursos aprimorados, antes dessa data.

Embora as bibliotecas mais antigas ainda possam ser usadas após 30 de setembro de 2026, elas não receberão mais suporte e atualizações oficiais da Microsoft. Para obter mais informações, consulte o anúncio de aposentadoria de suporte.