Partilhar via

Filas, tópicos e subscrições do Service Bus

  • Artigo

O Barramento de Serviço do Azure dá suporte ao enfileiramento de mensagens confiável e a mensagens duráveis de publicação/assinatura. As entidades de mensagens que formam o núcleo dos recursos de mensagens no Service Bus são filas, tópicos e assinaturas.

Importante

Se você é novo no Barramento de Serviço do Azure, leia O que é o Barramento de Serviço do Azure? antes de passar por este artigo.

Queues

As filas oferecem uma entrega de mensagens First In, First Out (FIFO) para um ou mais consumidores concorrentes. Ou seja, os recetores normalmente recebem e processam mensagens na ordem em que foram adicionadas à fila. E apenas uma mensagem o consumidor recebe e processa cada mensagem.

Imagem mostrando como as filas de serviço funcionam.

Um dos principais benefícios do uso de filas é conseguir o desacoplamento temporal dos componentes do aplicativo. Em outras palavras, os produtores (remetentes) e consumidores (recetores) não precisam enviar e receber mensagens ao mesmo tempo, porque as mensagens são armazenadas de forma durável na fila. Além disso, o produtor não precisa esperar por uma resposta do consumidor para continuar a processar e enviar mensagens.

Um benefício conexo é o nivelamento de carga, que permite que produtores e consumidores enviem e recebam mensagens a taxas diferentes. Em muitas aplicações, a carga do sistema varia ao longo do tempo. No entanto, o tempo de processamento necessário para cada unidade de trabalho é normalmente constante. Intermediar produtores de mensagens e consumidores com uma fila significa que o aplicativo consumidor só precisa ser capaz de lidar com a carga média em vez da carga de pico. A profundidade da fila aumenta e contrai à medida que a carga a receber varia. Esse recurso economiza dinheiro diretamente em relação à quantidade de infraestrutura necessária para atender à carga do aplicativo. À medida que a carga aumenta, mais processos de trabalho podem ser adicionados para leitura da fila. Cada mensagem é processada apenas por um dos processos de trabalho. Além disso, esse balanceamento de carga baseado em pull permite o melhor uso dos computadores de trabalho, mesmo que os computadores de trabalho com poder de processamento puxem mensagens em sua própria taxa máxima. Este padrão é frequentemente denominado padrão de consumidor concorrente.

O uso de filas para intermediar entre produtores de mensagens e consumidores fornece um acoplamento flexível inerente entre os componentes. Como produtores e consumidores não estão cientes um do outro, um consumidor pode ser atualizado sem ter qualquer efeito sobre o produtor.

Criar filas

Você pode criar filas usando uma das seguintes opções:

Em seguida, envie e receba mensagens usando clientes escritos em linguagens de programação, incluindo as seguintes:

Modos de receção

Você pode especificar dois modos diferentes nos quais os consumidores podem receber mensagens do Service Bus.

  • Receber e excluir. Nesse modo, quando o Service Bus recebe a solicitação do consumidor, ele marca a mensagem como sendo consumida e a retorna ao aplicativo do consumidor. Este modo é o modelo mais simples. Ele funciona melhor para cenários em que o aplicativo pode tolerar não processar uma mensagem se ocorrer uma falha. Para entender esse cenário, considere um cenário em que o consumidor emite a solicitação de recebimento e, em seguida, falha antes de processá-la. Como o Service Bus marca a mensagem como consumida, o aplicativo começa a consumir mensagens ao reiniciar. Ele perderá a mensagem que consumiu antes do acidente. Este processo é muitas vezes chamado de processamento no máximo uma vez .
  • Espreite a fechadura. Neste modo, a operação de receção torna-se numa operação de duas etapas, que permite o suporte de aplicações que não toleram mensagens em falta.

    1. Localiza a próxima mensagem a ser consumida, bloqueia-a para impedir que outros consumidores a recebam e, em seguida, retorna a mensagem para o aplicativo.

    2. Depois de a aplicação terminar de processar a mensagem, pede ao Service Bus para concluir a segunda fase do processo de receção. Em seguida, o serviço marca a mensagem como consumida.

      Se o aplicativo não conseguir processar a mensagem por algum motivo, ele poderá solicitar que o serviço Service Bus abandone a mensagem. O Service Bus desbloqueia a mensagem e a disponibiliza para ser recebida novamente, seja pelo mesmo consumidor ou por outro consumidor concorrente. Em segundo lugar, há um tempo limite associado ao bloqueio. Se a aplicação não conseguir processar a mensagem antes de o tempo limite de bloqueio expirar, o Service Bus desbloqueará a mensagem e ficará disponível para ser recebida novamente.

      Se a aplicação falhar depois de processar a mensagem, mas antes de pedir ao serviço do Service Bus para concluir a mensagem, o Service Bus voltará a enviar a mensagem para a aplicação quando for reiniciada. Este processo é muitas vezes chamado de processamento pelo menos uma vez . Ou seja, cada mensagem é processada, pelo menos, uma vez. No entanto, em certas situações, a mesma mensagem pode ser retransmitida. Se o seu cenário não tolerar processamento duplicado, adicione lógica extra em seu aplicativo para detetar duplicatas. Para obter mais informações, consulte Deteção de duplicatas, que é conhecida como processamento exatamente uma vez .

      Nota

      Para obter mais informações sobre esses dois modos, consulte Liquidando operações de recebimento.

Tópicos e subscrições

Uma fila permite o processamento de uma mensagem por um único consumidor. Em contraste com as filas, os tópicos e as assinaturas fornecem uma forma de comunicação um-para-muitos em um padrão de publicação e assinatura . É útil para dimensionar para um grande número de destinatários. Cada mensagem publicada é disponibilizada para cada subscrição registada com o tópico. O Publisher envia uma mensagem para um tópico e um ou mais subscritores recebem uma cópia da mensagem.

Imagem mostrando um tópico do Service Bus com três assinaturas.

Os editores enviam mensagens para um tópico da mesma forma que enviam mensagens para uma fila. Mas, os consumidores não recebem mensagens diretamente do tema. Em vez disso, os consumidores recebem mensagens de assinaturas do tópico. Uma assinatura de tópico se assemelha a uma fila virtual que recebe cópias das mensagens enviadas para o tópico. Os consumidores recebem mensagens de uma subscrição de forma idêntica à forma como recebem mensagens de uma fila. A funcionalidade de envio de mensagens de uma fila é mapeada diretamente para um tópico e sua funcionalidade de recebimento de mensagens é mapeada para uma assinatura. Entre outras coisas, esse recurso significa que as assinaturas suportam os mesmos padrões descritos anteriormente nesta seção em relação às filas: consumidor concorrente, dissociação temporal, nivelamento de carga e balanceamento de carga.

As assinaturas podem definir quais mensagens desejam receber de um tópico. Estas mensagens são especificadas na forma de uma ou mais regras de subscrição denominadas. Cada regra consiste em uma condição de filtro que seleciona mensagens específicas e , opcionalmente , contém uma ação que anota a mensagem selecionada. Por padrão, uma assinatura de um tópico recebe todas as mensagens enviadas para o tópico. A assinatura tem uma regra padrão inicial com um filtro verdadeiro que permite que todas as mensagens sejam selecionadas na assinatura. A regra padrão não tem nenhuma ação associada. Você pode definir filtros com regras e ações em uma assinatura para que a assinatura receba apenas um subconjunto de mensagens enviadas para o tópico.

Para obter mais detalhes sobre filtros, filtros e ações.

Criar tópicos e subscrições

Criar um tópico é semelhante a criar uma fila, conforme descrito na seção anterior. Você pode criar tópicos e assinaturas usando uma das seguintes opções:

Em seguida, envie mensagens para um tópico e receba mensagens de assinaturas usando clientes escritos em linguagens de programação, incluindo as seguintes:

Regras e ações

Em muitos cenários, as mensagens que têm características específicas devem ser processadas de maneiras diferentes. Para habilitar esse processamento, você pode configurar assinaturas para localizar mensagens que tenham propriedades desejadas e, em seguida, executar determinadas modificações nessas propriedades. Embora as assinaturas do Barramento de Serviço vejam todas as mensagens enviadas para o tópico, é possível copiar apenas um subconjunto dessas mensagens para a fila de assinaturas virtuais. Essa filtragem é realizada usando filtros de assinatura. Tais modificações são chamadas de ações de filtro. Quando uma assinatura é criada, você pode fornecer uma expressão de filtro que opera nas propriedades da mensagem. As propriedades podem ser as propriedades do sistema (por exemplo, Label) e as propriedades personalizadas do aplicativo (por exemplo, StoreName). A expressão de filtro SQL é opcional neste caso. Sem uma expressão de filtro SQL, qualquer ação de filtro definida em uma assinatura é feita em todas as mensagens dessa assinatura.

Para obter um exemplo de trabalho completo, consulte o exemplo TopicFilters no GitHub. Para obter mais informações sobre filtros, consulte Filtros e ações de tópicos.

Entidades Java Message Service (JMS) 2.0

As entidades a seguir podem ser acessadas por meio da API Java Message Service (JMS) 2.0.

  • Filas temporárias
  • Tópicos temporários
  • Subscrições duradouras partilhadas
  • Subscrições duradouras não partilhadas
  • Subscrições partilhadas não duráveis
  • Subscrições não partilhadas não duradouras

Saiba mais sobre as entidades JMS 2.0 e sobre como usá-las.

Entidades Express

As entidades Express foram criadas para cenários de alta taxa de transferência e latência reduzida. Com entidades expressas, se uma mensagem for enviada para uma fila ou tópico, ela não será armazenada imediatamente no armazenamento de mensagens. Em vez disso, a mensagem é inicialmente armazenada em cache na memória. As mensagens que permanecem na entidade são gravadas no armazenamento de mensagens após um atraso, momento em que são protegidas contra perda devido a uma interrupção.

Em entidades regulares, qualquer operação de tempo de execução (como Enviar, Concluir, Abandonar, Deadletter) é persistida para a loja primeiro, e somente depois que isso é reconhecido ao cliente como bem-sucedido. Em entidades expressas, uma operação de tempo de execução é reconhecida ao cliente como bem-sucedida primeiro e só depois persiste preguiçosamente para a loja. Como resultado, no caso de uma reinicialização da máquina ou quando ocorre um problema de hardware, algumas operações de tempo de execução reconhecidas podem não ser persistidas. Isso significa que o cliente obtém menor latência e maior taxa de transferência com entidades expressas, às custas de potencial perda de dados e/ou reentrega de mensagens.

Além disso, ao longo do tempo, muitas otimizações foram feitas no Service Bus, o que significa que as vantagens de taxa de transferência e latência das entidades expressas são atualmente mínimas. Além disso, a camada Premium do Service Bus não suporta entidades Express. Devido a isso, atualmente não é recomendado usar esse recurso.

Próximos passos

Experimente as amostras no idioma de sua escolha:

Para exemplos que usam as bibliotecas de cliente .NET e Java mais antigas, use os seguintes links:

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.