Sessões de mensagens
As sessões do Azure Service Bus permitem o manuseamento conjunto e ordenado de sequências não vinculadas de mensagens relacionadas. As sessões podem ser usadas em padrões de primeiro a entrar, primeiro a sair (FIFO) e solicitação-resposta . Este artigo mostra como usar sessões para implementar esses padrões ao usar o Service Bus.
Nota
O escalão básico do Service Bus não suporta sessões. Os escalões standard e premium suportam sessões. Para conhecer as diferenças entre esses níveis, consulte Preços do Service Bus.
Padrão FIFO (primeiro a entrar, primeiro a sair)
Para obter uma garantia FIFO no processamento de mensagens em filas ou assinaturas do Service Bus, use sessões. O Service Bus não é prescritivo sobre a natureza da relação entre mensagens e também não define um modelo específico para determinar onde uma sequência de mensagens começa ou termina.
Qualquer remetente pode criar uma sessão ao enviar mensagens para um tópico ou fila definindo a propriedade ID da sessão para algum identificador definido pelo aplicativo que seja exclusivo da sessão. No nível de protocolo AMQP 1.0 , esse valor é mapeado para a propriedade group-id .
Em filas ou assinaturas com reconhecimento de sessão, as sessões surgem quando há pelo menos uma mensagem com a ID da sessão. Uma vez que uma sessão existe, não há tempo definido ou API para quando a sessão expira ou desaparece. Teoricamente, uma mensagem pode ser recebida para uma sessão hoje, a próxima mensagem dentro de um ano, e se o ID da sessão corresponder, a sessão é a mesma da perspetiva do Service Bus.
Normalmente, no entanto, um aplicativo tem uma noção clara de onde um conjunto de mensagens relacionadas começa e termina. O Service Bus não define regras específicas. Por exemplo, seu aplicativo pode definir a propriedade Label para a primeira mensagem iniciar, para mensagens intermediárias para conteúdo e para a última mensagem terminar. A posição relativa das mensagens de conteúdo pode ser calculada como a mensagem atual SequenceNumber delta da mensagem inicial SequenceNumber.
Importante
Quando as sessões são habilitadas em uma fila ou uma assinatura, os aplicativos cliente não podem mais enviar/receber mensagens regulares. Todas as mensagens devem ser enviadas como parte de uma sessão (definindo o ID da sessão) e recebidas aceitando a sessão. Os clientes ainda podem espiar uma fila ou assinatura que tenha sessões habilitadas. Consulte Navegação de mensagens.
As APIs para sessões existem em clientes de fila e assinatura. Há um modelo imperativo que controla quando sessões e mensagens são recebidas e um modelo baseado em manipulador que oculta a complexidade do gerenciamento do loop de recebimento.
Para exemplos, use links na seção Próximas etapas .
Recursos da sessão
As sessões fornecem desmultiplexação simultânea de fluxos de mensagens intercaladas, preservando e garantindo a entrega ordenada.
Um recetor de sessão é criado por um cliente que aceita uma sessão. Quando a sessão é aceita e mantida por um cliente, o cliente mantém um bloqueio exclusivo em todas as mensagens com o ID de sessão dessa sessão na fila ou assinatura. Ele mantém bloqueios exclusivos em todas as mensagens com o ID da sessão que chegam mais tarde.
O bloqueio é liberado quando você chama métodos de fechamento no recetor ou quando o bloqueio expira. Existem métodos no recetor para renovar as fechaduras também. Em vez disso, você pode usar o recurso de renovação automática de bloqueio, onde pode especificar a duração do tempo durante o qual deseja continuar renovando o bloqueio. O bloqueio de sessão deve ser tratado como um bloqueio exclusivo em um arquivo, o que significa que o aplicativo deve fechar a sessão assim que não precisar mais dele e/ou não esperar mais mensagens.
Quando vários recetores simultâneos solicitam dados da fila, as mensagens pertencentes a uma determinada sessão são enviadas para o recetor específico que atualmente mantém o bloqueio dessa sessão. Com essa operação, um fluxo de mensagens intercaladas em uma fila ou assinatura é desmultiplexado para diferentes recetores e esses recetores também podem viver em máquinas clientes diferentes, uma vez que o gerenciamento de bloqueio acontece do lado do serviço, dentro do Service Bus.
A ilustração anterior mostra três recetores de sessão simultâneos. Uma sessão com SessionId = 4 não tem um cliente proprietário ativo, o que significa que nenhuma mensagem é entregue a partir desta sessão específica. Uma sessão age de muitas maneiras como uma subfila.
O bloqueio de sessão mantido pelo recetor de sessão é um guarda-chuva para os bloqueios de mensagem usados pelo modo de liquidação peek-lock . Apenas um recetor pode ter um bloqueio em uma sessão. Um recetor pode ter muitas mensagens a bordo, mas as mensagens são recebidas em ordem. Abandonar uma mensagem faz com que a mesma mensagem seja servida novamente com a próxima operação de recebimento.
Estado da sessão da mensagem
Quando os fluxos de trabalho são processados em sistemas de nuvem de alta escala e alta disponibilidade, o manipulador de fluxo de trabalho associado a uma sessão específica deve ser capaz de se recuperar de falhas inesperadas e pode retomar o trabalho parcialmente concluído em um processo ou máquina diferente de onde o trabalho começou.
O recurso de estado da sessão permite uma anotação definida pelo aplicativo de uma sessão de mensagem dentro do broker, para que o estado de processamento gravado relativo a essa sessão fique instantaneamente disponível quando a sessão for adquirida por um novo processador.
Da perspetiva do Service Bus, o estado da sessão da mensagem é um objeto binário opaco que pode conter dados do tamanho de uma mensagem, que é de 256 KB para o Service Bus Standard e 100 MB para o Service Bus Premium. O estado de processamento relativo a uma sessão pode ser mantido dentro do estado da sessão, ou o estado da sessão pode apontar para algum local de armazenamento ou registro de banco de dados que contenha essas informações.
Os métodos para gerenciar o estado SetState da sessão e GetState, podem ser encontrados no objeto recetor da sessão. Uma sessão que anteriormente não tinha nenhum estado de sessão retorna uma referência nula para GetState. O estado da sessão definido anteriormente pode ser limpo passando null para o SetState método no recetor.
O estado da sessão permanece enquanto não estiver limpo (retornando nulo), mesmo que todas as mensagens em uma sessão sejam consumidas.
O estado da sessão mantido em uma fila ou em uma assinatura conta para a cota de armazenamento dessa entidade. Quando o aplicativo é concluído com uma sessão, portanto, é recomendável que o aplicativo limpe seu estado retido para evitar custos de gerenciamento externo.
Impacto da contagem de entregas
A definição de contagem de entrega por mensagem no contexto de sessões varia ligeiramente da definição na ausência de sessões. Aqui está uma tabela resumindo quando a contagem de entrega é incrementada.
| Cenário | A contagem de entrega da mensagem é incrementada |
|---|---|
| A sessão é aceita, mas o bloqueio da sessão expira (devido ao tempo limite) | Sim |
| A sessão é aceite, as mensagens dentro da sessão não são concluídas (mesmo que estejam bloqueadas) e a sessão é encerrada | Não |
| A sessão é aceita, as mensagens são concluídas e, em seguida, a sessão é explicitamente fechada | N/A (É o fluxo padrão. Aqui, as mensagens são removidas da sessão) |
Padrão de solicitação-resposta
O padrão solicitação-resposta é um padrão de integração bem estabelecido que permite que o aplicativo remetente envie uma solicitação e fornece uma maneira para o destinatário enviar corretamente uma resposta de volta para o aplicativo remetente. Esse padrão normalmente precisa de uma fila ou tópico de curta duração para o aplicativo enviar respostas. Nesse cenário, as sessões fornecem uma solução alternativa simples com semântica comparável.
Vários aplicativos podem enviar suas solicitações para uma única fila de solicitações, com um parâmetro de cabeçalho específico definido para identificar exclusivamente o aplicativo remetente. O aplicativo recetor pode processar as solicitações que entram na fila e enviar respostas na fila habilitada para sessão, definindo o ID da sessão como o identificador exclusivo que o remetente enviou na mensagem de solicitação. O aplicativo que enviou a solicitação pode então receber mensagens no ID de sessão específico e processar corretamente as respostas.
Nota
O aplicativo que envia as solicitações iniciais deve saber sobre o ID da sessão e usá-lo para aceitar a sessão para que a sessão na qual ele está esperando a resposta seja bloqueada. É uma boa ideia usar um GUID que identifique exclusivamente a instância do aplicativo como uma ID de sessão. Não deve haver nenhum manipulador de sessão ou um tempo limite especificado no recetor da sessão para a fila para garantir que as respostas estejam disponíveis para serem bloqueadas e processadas por recetores específicos.
Sequenciamento vs. sessões
O número de sequência por si só garante a ordem de fila e a ordem de extração das mensagens, mas não a ordem de processamento, que requer sessões.
Digamos, há três mensagens na fila e dois consumidores.
- O consumidor 1 capta a mensagem 1.
- O consumidor 2 pega a mensagem 2.
- O consumidor 2 termina o processamento da mensagem 2 e pega a mensagem 3, enquanto o consumidor 1 ainda não terminou o processamento da mensagem 1.
- O consumidor 2 termina o processamento da mensagem 3, mas o consumidor 1 ainda não terminou o processamento da mensagem 1.
- Finalmente, o consumidor 1 conclui o processamento da mensagem 1.
Assim, as mensagens são processadas nesta ordem: mensagem 2, mensagem 3 e mensagem 1. Se você precisar que as mensagens 1, 2 e 3 sejam processadas em ordem, você precisará usar sessões.
Se as mensagens só precisam ser recuperadas em ordem, você não precisa usar sessões. Se as mensagens precisarem ser processadas em ordem, use sessões. O mesmo ID de sessão deve ser definido em mensagens que pertencem juntas, que podem ser as mensagens 1, 4 e 8 em um conjunto e 2, 3 e 6 em outro conjunto.
Expiração da mensagem
Para filas habilitadas para sessão ou assinaturas de tópicos, as mensagens são bloqueadas no nível da sessão. Se o tempo de vida (TTL) de qualquer uma das mensagens expirar, todas as mensagens relacionadas a essa sessão serão descartadas ou com letras mortas com base na configuração de expiração de mensagens na entidade. Em outras palavras, se houver uma única mensagem na sessão que passou pelo TTL, todas as mensagens na sessão expiraram. As mensagens expiram somente se houver um ouvinte ativo. Para obter mais informações, consulte Expiração da mensagem.
Próximos passos
Você pode habilitar sessões de mensagens ao criar uma fila usando o portal do Azure, PowerShell, CLI, modelo do Gerenciador de Recursos, .NET, Java, Python e JavaScript. Para obter mais informações, consulte Habilitar sessões de mensagens.
Experimente os exemplos no idioma de sua escolha para explorar os recursos do Barramento de Serviço do Azure.
- .NET
- Java
- Píton
- JavaScript