Filas, tópicos e assinaturas do Barramento de Serviço
O Barramento de Serviço do Azure dá suporte ao serviço de enfileiramento de mensagens confiável e ao sistema de mensagens de publicação/assinatura durável. As entidades de mensagens que formam o núcleo dos recursos do sistema de mensagens agenciado no Barramento de Serviço 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 ler este artigo.
Filas
As filas oferecem entrega de mensagem do tipo FIFO (primeiro a entrar, primeiro a sair) para um ou mais consumidores concorrentes. Ou seja, os receptores geralmente recebem e processam mensagens na ordem em que foram adicionados à fila. E, somente um consumidor de mensagem recebe e processa cada mensagem.
Um dos principais benefícios do uso de filas é obter o desacoplamento temporal de componentes do aplicativo. Em outras palavras, os produtores (remetentes) e os consumidores (receptores) não precisam enviar e receber mensagens ao mesmo tempo, pois 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 processando e enviando mensagens.
Um benefício relacionado é o nivelamento de carga, que permite que produtores e consumidores enviem e recebam mensagens em taxas diferentes. Em muitos aplicativos, a carga do sistema varia ao longo do tempo. No entanto, o tempo de processamento necessário para cada unidade de trabalho é normalmente constante. A intermediação de produtores e de consumidores de mensagem com uma fila significa que o aplicativo que está consumindo só precisa ser provisionado para poder lidar com a carga média em vez da carga de pico. A profundidade da fila aumentará e diminuirá conforme a carga de entrada variar. Essa capacidade economiza dinheiro diretamente com relação à quantidade de infraestrutura necessária para atender à carga do aplicativo. À medida que a carga aumenta, mais processos de trabalho poderão ser adicionados à leitura da fila. Cada mensagem é processada por apenas umdos processos de trabalho. Além disso, esse balanceamento de carga baseado em pull permite o uso ideal dos computadores de trabalho, mesmo se os computadores de trabalho com poder de processamento receberem mensagens em sua própria taxa máxima. Esse padrão é geralmente denominado de consumidor concorrente.
A utilização de filas para intermediar entre produtores e consumidores oferece um acoplamento flexível inerente entre os componentes. Como produtores e consumidores não têm conhecimento uns dos outros, um consumidor poderá ser atualizado sem afetar o produtor.
Criar filas
Você pode criar filas usando uma das seguintes opções:
Em seguida, envie e receba mensagens usando clientes gravados em linguagens de programação, incluindo as seguintes:
Modos de recepção
Você pode especificar dois modos diferentes nos quais os consumidores podem receber mensagens do Barramento de Serviço.
- Receber e excluir. Nesse modo, quando o Barramento de Serviço recebe a solicitação do consumidor, ele marca a mensagem como sendo consumida e a retorna ao aplicativo do consumidor. Esse modo é o modelo mais simples. Funciona melhor em cenários em que o aplicativo pode tolerar o não processamento de uma mensagem em caso de falha. Para reconhecer esse cenário, considere um cenário no qual o consumidor emite a solicitação de recebimento e, em seguida, ocorre falha antes de processá-la. Como o Barramento de Serviço marca a mensagem como consumida, o aplicativo começa a consumir mensagens após a reinicialização. Ele perderá a mensagem consumida antes da falha. Esse processo geralmente é chamado de processamento de no máximo uma vez.
- Bloqueio de inspeção. Nesse modo, a operação de recebimento torna-se uma operação de duas etapas, possibilitando o suporte a aplicativos que não podem tolerar mensagens ausentes.
Ele localiza a próxima mensagem a ser consumida, bloqueia-a para evitar que outros consumidores a recebam e a retornem para o aplicativo.
Depois que o aplicativo termina de processar a mensagem, ele solicita que o serviço do Barramento de Serviço conclua o segundo estágio do processo de recebimento. Em seguida, o serviço marca a mensagem como consumida.
Se o aplicativo não puder processar a mensagem por algum motivo, ele poderá solicitar que o serviço do Barramento de Serviço abandone a mensagem. O Barramento de Serviço desbloqueia a mensagem e a disponibiliza para que ela possa ser recebida novamente pelo mesmo consumidor ou por outro consumidor concorrente. Em segundo lugar, há um tempo limite associado ao bloqueio. Se o aplicativo não conseguir processar a mensagem antes que o tempo limite de bloqueio expire, o Barramento de Serviço desbloqueia a mensagem e a disponibiliza para ser recebida novamente.
Se o aplicativo falhar depois de processar a mensagem, mas antes de solicitar que o serviço do Barramento de Serviço conclua a mensagem, o Barramento de Serviço entregará a mensagem novamente ao aplicativo quando ele for reiniciado. Esse processo geralmente é chamado de processamento de pelo menos uma vez. Ou seja, cada mensagem é processada pelo menos uma vez. No entanto, em determinadas situações, a mesma mensagem pode ser revivido novamente. Se o cenário não puder tolerar o processamento duplicado, adicione lógica extra ao aplicativo para detectar duplicatas. Para obter mais informações, consulte a Detecção de duplicidade, que é conhecida como processamento exatamente uma vez.
Observação
Para obter mais informações sobre esses dois modos, veja Liquidar operações de recebimento.
Tópicos e assinaturas
Uma fila permite o processamento de uma mensagem por um único consumidor. Diferente das filas, os tópicos e as assinaturas fornecem uma forma de comunicação de 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 assinatura registrada no tópico. O editor envia uma mensagem para um tópico e um ou mais assinantes recebem uma cópia da mensagem.
Os editores enviam mensagens para um tópico da mesma forma que enviam mensagens para uma fila. No entanto, os consumidores não recebem mensagens diretamente do tópico. Em vez disso, os consumidores recebem mensagens de assinaturas do tópico. Uma assinatura de tópico é semelhante a uma fila virtual que recebe cópias das mensagens enviadas para o tópico. Os consumidores recebem mensagens de uma assinatura de forma idêntica à maneira como recebem mensagens de uma fila. A funcionalidade de envio de mensagens de uma fila é diretamente mapeada para um tópico e sua funcionalidade de recebimento de mensagens é mapeada para uma assinatura. Entre outras coisas, esse recurso significa que as assinaturas dão suporte aos mesmos padrões descritos anteriormente nesta seção no que diz respeito a filas: consumidor concorrente, desacoplamento temporal, nivelamento de carga e balanceamento de carga.
As assinaturas podem definir quais mensagens desejam receber de um tópico. Essas mensagens são especificadas na forma de uma ou mais regras de assinatura nomeadas. Cada regra consiste em uma condição de filtro que seleciona mensagens específicas e como opção contém uma ação que anota a mensagem selecionada. Por padrão, uma assinatura para 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 ao tópico.
Para obter mais detalhes sobre filtros, confira Filtros e ações.
Criar tópicos e assinaturas
A criação de um tópico é semelhante à criação de 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 gravados em linguagens de programação, incluindo as seguintes:
Regras e ações
Em muitos cenários, as mensagens com características específicas precisam ser processadas de maneiras diferentes. Para habilitar esse processamento, você pode configurar assinaturas para localizar as mensagens com as propriedades desejáveis e, em seguida, realizar determinadas modificações nessas propriedades. Embora as assinaturas do Barramento de Serviço vejam todas as mensagens enviadas ao tópico, só é possível copiar um subconjunto dessas mensagens para a fila de assinatura virtual. 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 opere nas propriedades da mensagem. As propriedades podem ser ambas as propriedades do sistema (por exemplo, Rótulo) e propriedades de aplicativo personalizadas (por exemplo, StoreName). A expressão de filtro SQL é opcional nesse 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 ver um exemplo em pleno funcionamento, confira a amostra de filtros de tópicos no GitHub. Para saber mais sobre filtros, consulte Filtros e ações de tópico.
Entidades do JMS (Serviço de Mensagens Java) 2.0
As entidades a seguir podem ser acessadas por meio da API do Java Message Service (JMS) 2.0.
- Filas temporárias
- Tópicos temporários
- Assinaturas duráveis compartilhadas
- Assinaturas duráveis não compartilhadas
- Assinaturas não duráveis compartilhadas
- Assinaturas não duráveis não compartilhadas
Saiba mais sobre as Entidades JMS 2.0 e sobre como usá-las.
Entidades expressas
As entidades expressas foram criadas para cenários de alta taxa de transferência e de latência reduzida. Com entidades expressas, se uma mensagem é enviada a uma fila ou tópico, ela não é imediatamente armazenada no repositório de mensagens. Em vez disso, a mensagem é armazenada inicialmente em cache na memória. As mensagens que permanecem na entidade são gravadas no repositório de mensagens após um atraso, momento em que elas são protegidas contra perda devido a uma interrupção.
Em entidades regulares, qualquer operação de runtime (como Enviar, Concluir, Abandonar, Colocar mensagem na fila de mensagens mortas) é mantida primeiro no repositório e somente depois disso é confirmada para o cliente como bem-sucedida. Em entidades expressas, uma operação de runtime é confirmada para o cliente como bem-sucedida primeiro e, somente mais tarde, persistida lentamente no repositório. Como resultado, no caso de uma reinicialização do computador ou quando ocorre um problema de hardware, algumas operações de runtime confirmadas podem não ser persistidas. Isso significa que o cliente obtém menor latência e maior taxa de transferência com entidades expressas, em detrimento de potencial perda de dados e/ou resgate de mensagens.
Além disso, ao longo do tempo, muitas otimizações foram feitas no Barramento de Serviço, o que significa que as vantagens de taxa de transferência e latência das entidades expressas são mínimas no momento. Além disso, a camada Premium do Barramento de Serviço não dá suporte a Entidades expressas. Devido a isso, atualmente não é recomendável usar esse recurso.
Próximas etapas
Experimente os exemplos no idioma de sua escolha:
- Exemplos da biblioteca de clientes do Barramento de Serviço do Azure para .NET (mais recentes)
- Amostras da biblioteca de clientes do Barramento de Serviço do Azure para Java (mais recentes)
- Exemplos da biblioteca de clientes do Barramento de Serviço do Azure para Python
- Exemplos da biblioteca de clientes do Barramento de Serviço do Azure para JavaScript
- Exemplos da biblioteca de clientes do Barramento de Serviço do Azure para TypeScript
Para exemplos que usam as bibliotecas de clientes .NET e Java mais antigas, use os seguintes links:
- Exemplos da biblioteca de clientes do Barramento de Serviço do Azure para .NET (herdado)
- Amostras da biblioteca de cliente do Barramento de Serviço do Azure para Java (herdado)
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, portanto, ele não poderá mais ser usado após 30 de setembro de 2026. Antes dessa data, migre para as bibliotecas mais recentes do SDK do Azure, que oferecem atualizações de segurança críticas e funcionalidades aprimoradas.
Embora as bibliotecas mais antigas ainda poderão 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, confira o anúncio de desativação do suporte.