Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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 das capacidades de mensagens no Service Bus são filas, tópicos e assinaturas.
Este artigo explica estas entidades centrais de mensagens, os seus benefícios e quando usar cada uma delas na arquitetura da sua aplicação.
Importante
Se é novo no Azure Service Bus, leia a Introdução ao Azure Service Bus antes de ler este artigo.
Escolha entre filas e tópicos
A tabela seguinte resume as principais diferenças entre filas e tópicos para o ajudar a escolher a entidade de mensagens certa para o seu cenário.
| Característica | Queues | Tópicos e subscrições |
|---|---|---|
| Padrão de comunicação | Ponto a ponto | Publicar/subscrever (muitos destinatários) |
| Entrega de mensagens | Consumidor singular para cada mensagem | Vários subscritores podem receber cópias |
| Caso de uso | Distribuição de tarefas, nivelamento de carga | Transmissão de eventos, cenários de dispersão |
| Filtragem | Não suportado | Filtros de subscrição para entrega seletiva de mensagens |
Queues
As filas fornecem entrega de mensagens First In, First Out (FIFO) a um ou mais consumidores concorrentes. Ou seja, os recetores normalmente recebem e processam mensagens na ordem em que foram adicionadas à fila. E apenas um consumidor de mensagens recebe e processa cada mensagem.
Benefícios de usar filas
| Benefício | Description |
|---|---|
| Desacoplamento temporal | Produtores (emissores) e consumidores (recetores) não têm de enviar e receber mensagens ao mesmo tempo, porque as mensagens são armazenadas de forma permanente na fila. O produtor não precisa de esperar por uma resposta do consumidor para continuar o processamento. |
| Nivelamento de carga | Produtores e consumidores podem enviar e receber mensagens a taxas diferentes. A aplicação consumidora só precisa de gerir a carga média em vez da carga máxima, poupando custos de infraestrutura. |
| Consumidores concorrentes | Múltiplos processos de trabalho podem ler da fila, com cada mensagem processada por apenas um trabalhador. Este balanceamento de carga baseado em pull permite aos trabalhadores processar à sua própria taxa máxima. |
| Acoplamento solto | Como produtores e consumidores não têm conhecimento mútuo, um consumidor pode ser atualizado sem afetar o produtor. |
Criar filas
Você pode criar filas usando uma das seguintes opções:
O Service Bus suporta nomes hierárquicos de entidades com barras oblíquas como separadores, por exemplo orders/region/west. Ao utilizar ferramentas baseadas em ARM (portal, CLI, PowerShell ou modelos), substitua / por ~ nos nomes das entidades. Para mais detalhes, consulte nomes de entidades com barras oblíquas.
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.
Modo de receber e eliminar
Quando o Service Bus recebe o pedido do consumidor, marca a mensagem como consumida e devolve-a à aplicação do consumidor. Este modo é o modelo mais simples e funciona melhor em cenários onde a aplicação pode tolerar não processar uma mensagem caso ocorra uma falha.
Se o consumidor falhar antes de processar a mensagem, a mensagem perde-se porque o Service Bus já a marcou como consumida. Este processo é muitas vezes chamado de processamento no máximo uma única vez.
modo de bloqueio de espreitar
A operação de receção torna-se em dois estágios, o que permite suportar aplicações que não toleram mensagens perdidas:
- Encontra a próxima mensagem a ser consumida, bloqueia-a para impedir que outros consumidores a recebam e depois devolve a mensagem à aplicação.
- Depois de a aplicação concluir o processamento da mensagem, solicita ao Service Bus que conclua a segunda fase do processo de receção. Em seguida, o serviço marca a mensagem como consumida.
Gestão de falhas no modo peek lock:
- Abandonar: Se a aplicação não conseguir processar a mensagem, pode pedir ao Service Bus que abandone a mensagem. O Service Bus desbloqueia a mensagem e torna-a disponível para receber novamente.
- Tempo de espera do bloqueio: Se a aplicação não processar a mensagem antes do tempo limite do bloqueio expirar, o Service Bus desbloqueia a mensagem e torna-a disponível para receber novamente.
- Crash da aplicação: Se a aplicação crashar após processar a mensagem mas antes de a concluir, o Service Bus volta a entregar a mensagem quando a aplicação reinicia. Este processo é muitas vezes chamado de processamento pelo menos uma vez.
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 duplicados, que é conhecida como processamento de exatamente uma vez.
Nota
Para obter mais informações sobre esses dois modos, consulte Liquidação das 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 oferecem uma forma de comunicação um-para-muitos num padrão de publicação e subscrição. É útil para escalonar 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.
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 tópico. Em vez disso, os consumidores recebem mensagens provenientes das 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 está mapeada diretamente para um tópico, e a funcionalidade de recebimento de mensagens está mapeada para uma subscrição. 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.
Filtros de subscrição
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 numa 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 mais informações sobre filtros, consulte 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 permitir este processamento, pode configurar subscrições para encontrar mensagens com propriedades desejadas e depois realizar certas 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 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 não duradouras partilhadas
- Subscrições não duradouras não partilhadas
Saiba mais sobre as entidades JMS 2.0 e sobre como usá-las.
Entidades expressas
Importante
Entidades Express não são recomendadas para novas candidaturas. As vantagens em termos de throughput e latência são presentemente reduzidas devido às otimizações no Service Bus. O nível Premium do Service Bus não suporta 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 é imediatamente armazenada no repositório de mensagens. Em vez disso, a mensagem é inicialmente armazenada em cache na memória. As mensagens que permanecem na entidade são escritas para o armazenamento de mensagens após um atraso, altura em que ficam protegidas contra perdas devido a uma falha.
Em entidades normais, qualquer operação em tempo de execução (como Send, Complete, Abandon, Deadletter) é primeiro persistida no armazenamento, e só depois é que a operação é reconhecida como bem-sucedida para o cliente. 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, quando uma máquina reinicia ou ocorre um problema de hardware, algumas operações de execução reconhecidas podem não ser mantidas de todo. Neste caso, o cliente obtém menor latência e maior débito (throughput) com entidades expressas, à custa de uma potencial perda de dados e/ou de reentrega de mensagens.
Próximos passos
Experimente as amostras no idioma de sua escolha:
- Exemplos da biblioteca de cliente do Azure Service Bus para .NET (mais recente)
- Exemplos da biblioteca cliente do Azure Service Bus para Java (atual)
- Exemplos de biblioteca de cliente do Barramento de Serviço do Azure para Python
- Exemplos de biblioteca de cliente do Barramento de Serviço do Azure para JavaScript
- Exemplos da biblioteca do cliente do Azure Service Bus para TypeScript
Para exemplos que usam as bibliotecas de cliente .NET e Java mais antigas, use os seguintes links:
- Exemplos de biblioteca de cliente do Barramento de Serviço do Azure para .NET (legado)
- Exemplos da biblioteca do cliente do Azure Service Bus para Java (legado)
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.