Compartilhar via

Sessões de mensagem

As sessões do Barramento de Serviço do Azure permitem o processamento conjunto e ordenado de sequências não associadas de mensagens relacionadas. As sessões podem ser usadas em padrões FIFO (primeiro a entrar, primeiro a sair) e requisição-resposta. Este artigo mostra como usar sessões para implementar esses padrões ao usar o Barramento de Serviço.

Observação

A camada básica do Barramento de Serviço não dá suporte a sessões. As camadas standard e premium dão suporte a sessões. Para conferir as diferenças entre essas camadas, consulte preços do Barramento de Serviço.

Padrão FIFO (primeiro a entrar, primeiro a sair)

Para garantir o processamento FIFO ao lidar com mensagens de filas ou assinaturas do Barramento de Serviço, use sessões. O Barramento de Serviço não é restritivo quanto à natureza da relação entre as mensagens e também não define um modelo específico para determinar onde uma sequência de mensagens começa ou termina.

Um remetente pode iniciar uma sessão ao enviar mensagens para um tópico ou fila definindo a propriedade ID da sessão como um identificador exclusivo definido pelo aplicativo. No nível do protocolo AMQP 1.0 , esse valor é mapeado para a propriedade de ID de grupo .

Em filas ou assinaturas com reconhecimento de sessão, as sessões passam a existir quando há pelo menos uma mensagem na ID de sessão. Quando 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 daqui a um ano, e se a ID da sessão coincidir, a sessão será considerada a mesma do ponto de vista do Bus de Serviço.

Normalmente, no entanto, um aplicativo define onde um conjunto de mensagens relacionadas começa e termina. O Barramento de Serviço não impõe regras específicas. Por exemplo, seu aplicativo pode definir a propriedade Label para a primeira mensagem como início, para mensagens intermediárias como conteúdo e para que a última mensagem termine. A posição relativa das mensagens de conteúdo pode ser computada como o delta de SequenceNumber da mensagem atual com relação ao SequenceNumber da mensagem start.

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. Os clientes devem enviar mensagens como parte de uma sessão, definindo a ID da sessão, e receber mensagens aceitando a sessão. Os clientes ainda podem espiar uma fila ou assinatura que tenha sessões habilitadas. Consulte a navegação por mensagens.

As APIs para sessões existem nos clientes de fila e de assinatura. Há duas maneiras de receber sessões e mensagens: o modelo imperativo, em que você controla manualmente quando e como as mensagens são recebidas, e o modelo baseado em manipulador, que simplifica as coisas gerenciando automaticamente o loop e o processamento da mensagem.

Para exemplos, use links na seção Exemplos .

Recursos de sessão

As sessões fornecem demultiplexação simultânea de fluxos de mensagens intercaladas enquanto preserva e garante a entrega ordenada.

Diagrama que mostra como o recurso de Sessões preserva a entrega ordenada.

Um cliente cria um receptor de sessão para aceitar uma sessão. Quando o cliente aceita e mantém uma sessão, ele detém um bloqueio exclusivo em todas as mensagens com a ID da sessão correspondente na fila ou assinatura. Ele mantém bloqueios exclusivos em todas as mensagens com a ID da sessão que chegam posteriormente.

O bloqueio é liberado quando você chama métodos de fechamento no receptor ou quando o bloqueio expira. Também existem métodos no receptor para renovar os bloqueios. Em vez disso, você pode usar o recurso de renovação automática de bloqueio, no qual você pode especificar a duração do tempo para a qual deseja manter a renovação do 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 ele não precisar mais dele e/ou não esperar mais nenhuma mensagem adicional.

Quando vários destinatários simultâneos efetuam o pull da fila, as mensagens que pertencem a uma sessão específica são expedidas para um destinatário específico que atualmente mantém o bloqueio para a sessão. Com essa operação, um fluxo de mensagens intercaladas em uma fila ou assinatura é corretamente desmultiplexado para diferentes destinatários e esses destinatários também podem residir em computadores cliente diferentes, uma vez que o gerenciamento de bloqueio ocorre no lado do servidor, dentro do Barramento de Serviço.

A ilustração anterior mostra três receptores de sessão concomitantes. Uma sessão com SessionId = 4 não tem nenhum cliente ativo e proprietário, o que significa que nenhuma mensagem é entregue desta sessão específica. Uma sessão atua de várias maneiras, como uma subfila.

O bloqueio da sessão mantido pelo destinatário da sessão é uma proteção abrangente para os bloqueios de mensagem usados pelo modo de liquidação de bloqueio de pico. Somente um destinatário pode ter um bloqueio em uma sessão. Um destinatário pode ter muitas mensagens em andamento, mas as mensagens são recebidas na ordem. Abandonar uma mensagem faz com que a mesma mensagem seja atendida novamente com a próxima operação de recebimento.

Estado da sessão de 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 computador diferente de onde o trabalho começou.

O recurso de estado de sessão permite uma anotação definida pelo aplicativo de uma sessão de mensagem no broker, de modo que o estado de processamento registrado em relação a essa sessão fique disponível instantaneamente quando a sessão for adquirida por um novo processador.

Do ponto de vista do Service Bus, o estado da sessão de 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 contém essas informações.

Os métodos para gerenciar o estado da sessão, SetState e GetState, podem ser encontrados no objeto do receptor de sessão. Uma sessão que anteriormente não tinha nenhum estado de sessão retorna uma referência nula para GetState. O estado de sessão definido anteriormente pode ser limpo passando NULL para o método SetState no receptor.

O estado da sessão permanece enquanto não for limpo (retornando nulo), mesmo que todas as mensagens em uma sessão sejam consumidas.

O estado de sessão mantido em uma fila ou em uma assinatura conta para a cota de armazenamento dessa entidade. Quando o aplicativo termina uma sessão, é recomendável que limpe seu estado armazenado para evitar custos de gerenciamento externo.

Impacto da contagem de entrega

A definição de contagem de entregas por mensagem no contexto de sessões varia um pouco da definição na ausência de sessões. Confira uma tabela que resume quando a contagem de entregas é incrementada.

Cenário A contagem de entregas da mensagem é incrementada
A sessão é aceita, mas o bloqueio da sessão expira (devido ao tempo limite) Sim
A sessão é aceita, as mensagens dentro da sessão não são concluídas (mesmo que estejam bloqueadas) e a sessão é fechada Não
A sessão é aceita, as mensagens são concluídas e, em seguida, a sessão é fechada explicitamente N/A (é o fluxo padrão. Aqui, as mensagens são removidas da sessão)

Padrão de solicitação-resposta

O padrão de 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 de o receptor enviar corretamente uma resposta de volta ao aplicativo remetente. Esse padrão normalmente precisa de uma fila ou tópico de curta duração para que o aplicativo envie 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ção, com um parâmetro de cabeçalho específico definido para identificar exclusivamente o aplicativo remetente. O aplicativo receptor pode processar as solicitações que chegam na fila e enviar respostas na fila habilitada para sessão, definindo a ID da sessão para o identificador exclusivo que o remetente enviou na mensagem de solicitação. O aplicativo que enviou a solicitação pode receber mensagens na ID de sessão específica e processar corretamente as respostas.

Observação

O aplicativo que envia as solicitações iniciais deve saber sobre a ID da sessão e usá-la para aceitar a sessão para que a sessão na qual ela espera que 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 um manipulador de sessão nem um tempo limite especificado no receptor da sessão para a fila, a fim de garantir que as respostas estejam disponíveis para serem bloqueadas e processadas por receptores específicos.

Sequenciamento versus sessões

O número de sequência, por si só, garante a ordem de enfileiramento e a ordem de extração das mensagens, mas não a ordem de processamento, que requer sessões.

Digamos que haja três mensagens na fila e dois consumidores.

  1. O consumidor 1 pega a mensagem 1.
  2. O consumidor 2 pega a mensagem 2.
  3. O Consumidor 2 conclui o processamento da mensagem 2 e pega a mensagem 3, enquanto o Consumidor 1 ainda não terminou de processar a mensagem 1.
  4. O consumidor 2 conclui o processamento da mensagem 3, mas o consumidor 1 ainda não terminou o processamento da mensagem 1.
  5. Por fim, o consumidor 1 conclui o processamento da mensagem 1.

Portanto, as mensagens foram processadas nesta ordem: mensagem 2, mensagem 3 e mensagem 1. Se você precisar que as mensagens 1, 2 e 3 sejam processadas em ordem, será necessário usar sessões.

Se as mensagens só precisarem ser recuperadas em ordem, você não precisará usar sessões. Se as mensagens precisarem ser processadas em ordem, use sessões. A mesma ID de sessão deve ser definida em mensagens que pertencem juntas, que podem ser a mensagem 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 a vida útil (TTL) de qualquer uma das mensagens expirar, todas as mensagens relacionadas a essa sessão serão descartadas ou enviadas para a fila de mensagens mortas, dependendo da configuração de mensagens mortas ativada para a expiração de mensagens na entidade. Em outras palavras, se houver uma única mensagem na sessão que tenha passado o TTL, todas as mensagens na sessão expirarão. As mensagens expirarão somente se houver um ouvinte ativo. Para obter mais informações, consulte a expiração da mensagem.

Exemplos

Você pode habilitar sessões de mensagem ao criar uma fila usando o portal do Azure, o PowerShell, a CLI, o modelo do Resource Manager, o .NET, o Java, o Python e o JavaScript. Para obter mais informações, consulte Habilitar sessões de mensagem.

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

Conteúdo relacionado