Ordenar mensagens

A ordenação de mensagens é um recurso do Pub/Sub que permite receber mensagens nos clientes assinantes na ordem em que foram publicadas pelos clientes publisher.

Por exemplo, suponha que um cliente publisher em uma região publique as mensagens 1, 2 e 3 em ordem. Com a ordenação de mensagens, o cliente assinante recebe as mensagens publicadas na mesma ordem. Para serem entregues em ordem, o cliente publisher precisa publicar as mensagens na mesma região. No entanto, os assinantes podem se conectar a qualquer região, e a garantia de ordenação ainda é mantida.

A ordenação de mensagens é um recurso útil para cenários como captura de mudanças no banco de dados, rastreamento de sessões de usuários e aplicativos de streaming em que a preservação da cronologia de eventos é importante.

Esta página explica o conceito de ordenação de mensagens e como configurar os clientes assinantes para receber mensagens em ordem. Para configurar os clientes publisher para ordenação de mensagens, consulte Usar chaves de ordem para publicar uma mensagem.

Visão geral da ordenação de mensagens

A ordenação no Pub/Sub é determinada pelo seguinte:

• Chave de ordem. Uma chave de ordem é uma string que identifica mensagens relacionadas que precisam ser ordenadas. Exemplos de chaves de ordem incluem IDs de clientes ou a chave primária de uma linha em um banco de dados. Uma chave de ordem pode ter até 1 KB de comprimento.

  Para conseguir a ordenação de mensagens, defina a mesma chave de ordem em todas as mensagens relacionadas que precisam ser recebidas em ordem. Além disso, é necessário publicar todas as mensagens com a mesma chave de ordem na mesma região. Para mais informações, consulte Usar chaves de ordem para publicar uma mensagem.

  As mensagens com uma chave de ordem vazia não são ordenadas.

• Ativar a ordem das mensagens. Para receber mensagens em ordem, é necessário ativar a ordem das mensagens na assinatura. Para mais informações, consulte Ativar a ordem das mensagens.

  Se a ordem das mensagens não estiver ativada, uma assinatura receberá mensagens sem uma ordem esperada. Por exemplo, suponha que as assinaturas A e B estejam anexadas ao mesmo tópico T e que a ordenação esteja ativada na assinatura A, mas não na assinatura B. Embora ambas as assinaturas recebam o mesmo conjunto de mensagens do tópico T, a ordenação só é preservada para a assinatura A.

A capacidade de processamento de publicação em cada chave de ordem é limitada a 1 MBps. A capacidade de processamento em todas as chaves de ordem em um tópico é limitada à cota disponível em uma região de publicação. Esse limite pode ser aumentado para vários GBps.

Em geral, se a solução exigir que os clientes publisher enviem mensagens ordenadas e não ordenadas, crie tópicos separados, um para mensagens ordenadas e outro para mensagens não ordenadas.

Considerações ao usar mensagens ordenadas

A lista a seguir contém informações importantes sobre o comportamento das mensagens ordenadas no Pub/Sub:

• Cardinalidade. Uma chave de ordem não é equivalente a uma partição em um sistema de mensagens baseado em partição, porque as chaves de ordem precisam ter uma cardinalidade muito maior do que as partições.

• Ordenação dentro da chave: as mensagens publicadas com a mesma chave de ordem precisam ser recebidas em ordem. Suponha que, para a chave de ordem A, você publique as mensagens 1, 2 e 3. Com a ordenação ativada, a mensagem 1 precisa ser entregue antes da 2, e a 2 precisa ser entregue antes da 3.

• Ordenação entre chaves: as mensagens publicadas com chaves de ordem diferentes não precisam ser recebidas em ordem. Suponha que você tenha as chaves de ordem A e B. Para a chave de ordem A, as mensagens 1 e 2 são publicadas em ordem. Para a chave de ordem B, as mensagens 3 e 4 são publicadas em ordem. No entanto, a mensagem 1 pode chegar antes ou depois da mensagem 4.

• Reentrega de mensagens: o Pub/Sub entrega cada mensagem pelo menos uma vez, para que o serviço do Pub/Sub possa reenviar as mensagens. As reentregas de uma mensagem acionam a reentrega de todas as mensagens subsequentes para essa chave, mesmo as confirmadas. Suponha que um cliente assinante receba as mensagens 1, 2 e 3 para uma chave de ordem específica. Se a mensagem 2 for reenviada (porque o prazo de confirmação expirou ou a confirmação de melhor esforço não persistiu no Pub/Sub), a mensagem 3 também será reenviada. Se a ordem das mensagens e um tópico de mensagens inativas estiverem ativados em uma assinatura, esse comportamento poderá não ser verdadeiro, já que o Pub/Sub encaminha mensagens para tópicos de mensagens inativas com base no melhor esforço.

• Atrasos de confirmação e tópicos de mensagens inativas: as mensagens não confirmadas para uma determinada chave de ordem podem atrasar a entrega de mensagens para outras chaves de ordem, especialmente durante reinicializações do servidor ou mudanças de tráfego. Para manter a ordem em todos esses eventos, confirme todas as mensagens em tempo hábil. Se a confirmação oportuna não for possível, considere usar um tópico de mensagens inativas para evitar a retenção indefinida de mensagens. A ordem pode não ser preservada quando as mensagens são gravadas em um tópico de mensagens inativas.

• Afinidade de mensagens (clientes streamingPull): as mensagens para a mesma chave são geralmente entregues ao mesmo cliente assinante streamingPull. A afinidade é esperada quando as mensagens estão pendentes para uma chave de ordem para um cliente assinante específico. Se não houver mensagens pendentes, a afinidade poderá mudar para balanceamento de carga ou desconexões do cliente.

  Para garantir um processamento tranquilo, mesmo com possíveis mudanças de afinidade, é fundamental projetar o aplicativo streamingPull de forma que ele possa processar mensagens em qualquer cliente para uma determinada chave de ordem.

• Integração com o Dataflow: não ative a ordem das mensagens para assinaturas ao configurar o Dataflow com o Pub/Sub. O Dataflow tem um mecanismo próprio para a ordem total de mensagens, garantindo a ordem cronológica em todas as mensagens como parte das operações de janela. Esse método de ordenação é diferente da abordagem baseada em chave de ordem do Pub/Sub. O uso de chaves de ordem com o Dataflow pode reduzir o desempenho do pipeline.

• Escalonamento automático: a entrega ordenada do Pub/Sub é escalonada para bilhões de chaves de ordem. Um número maior de chaves de ordem permite mais entrega paralela aos assinantes, já que a ordenação se aplica a todas as mensagens com a mesma chave de ordem.

• Compensações de desempenho: a entrega ordenada tem algumas compensações. Em comparação com a entrega não ordenada, a entrega ordenada diminui a disponibilidade de publicação e aumenta a latência de entrega de mensagens de ponta a ponta. No caso de entrega ordenada, o failover exige coordenação para garantir que as mensagens sejam gravadas e lidas na ordem correta.

• Chave ativa: ao usar a ordem das mensagens, todas as mensagens com a mesma chave de ordem são enviadas ao cliente assinante na ordem em que são recebidas pelo serviço. O retorno de chamada do usuário não é executado até que o retorno de chamada seja concluído para a mensagem anterior. A capacidade de processamento máxima de mensagens que compartilham a mesma chave de ordem ao entregar aos assinantes não é limitada pelo Pub/Sub , mas pela velocidade de processamento do cliente assinante. Uma chave ativa ocorre quando um backlog é criado em uma chave de ordem individual porque o número de mensagens produzidas por segundo excede o número de mensagens que o assinante pode processar por segundo. Para atenuar as chaves ativas, use as chaves mais granulares possíveis e minimize o tempo de processamento por mensagem. Também é possível monitorar a métrica subscription/oldest_unacked_message_age para um valor crescente, o que pode indicar uma chave ativa.

Para mais informações sobre como usar a ordem das mensagens, consulte os seguintes tópicos de práticas recomendadas:

• Práticas recomendadas para mensagens ordenadas na publicação

• Práticas recomendadas para mensagens ordenadas na assinatura

Comportamento do cliente assinante para ordenação de mensagens

Os clientes assinantes recebem mensagens na ordem em que foram publicadas em uma região específica. O Pub/Sub oferece suporte a diferentes maneiras de receber mensagens, como clientes assinantes conectados a assinaturas de pull e push. As bibliotecas de cliente usam streamingPull (com exceção do PHP).

Para saber mais sobre esses tipos de assinatura, consulte Escolher um tipo de assinatura.

As seções a seguir discutem o que significa receber mensagens em ordem para cada tipo de cliente assinante.

Clientes assinantes de StreamingPull

Ao usar as bibliotecas de cliente com streamingPull, é necessário especificar um retorno de chamada do usuário que é executado sempre que uma mensagem é recebida por um cliente assinante. Com as bibliotecas de cliente, para qualquer chave de ordem, o retorno de chamada é executado até a conclusão das mensagens na ordem correta. Se as mensagens forem confirmadas nesse retorno de chamada, todos os cálculos em uma mensagem ocorrerão em ordem. No entanto, se o retorno de chamada do usuário programar outro trabalho assíncrono em mensagens, o cliente assinante precisará garantir que o trabalho assíncrono seja feito em ordem. Uma opção é adicionar mensagens a uma fila de trabalho local que é processada em ordem.

Clientes assinantes de pull

Para clientes assinantes conectados a assinaturas de pull, a ordem de mensagens do Pub/Sub oferece suporte ao seguinte:

• Todas as mensagens de uma chave de ordem no PullResponse estão na ordem correta na lista.

• Apenas um lote de mensagens pode estar pendente para uma chave de ordem por vez.

O requisito de que apenas um lote de mensagens possa estar pendente por vez é necessário para manter a entrega ordenada, já que o serviço do Pub/Sub não pode garantir o sucesso ou a latência da resposta enviada para uma solicitação de envio do assinante.

Clientes assinantes de push

As restrições de push são ainda mais rigorosas do que as de pull. Para uma assinatura por push, o Pub/Sub oferece suporte a apenas uma mensagem pendente para cada chave de ordem por vez. Cada mensagem é enviada a um endpoint push como uma solicitação separada. Assim, o envio das solicitações em paralelo teria o mesmo problema que a entrega de vários lotes de mensagens para a mesma chave de ordem para assinantes de pull simultaneamente. As assinaturas push podem não ser uma boa opção para tópicos em que as mensagens são publicadas com frequência com a mesma chave de ordem ou em que a latência é extremamente importante.

Clientes assinantes de exportação

As assinaturas de exportação oferecem suporte a mensagens ordenadas. Para assinaturas do BigQuery, as mensagens com a mesma chave de ordem são gravadas na tabela do BigQuery em ordem. Para assinaturas do Cloud Storage, as mensagens com a mesma chave de ordem podem não ser gravadas no mesmo arquivo. Quando estão no mesmo arquivo, as mensagens de uma chave de ordem estão em ordem. Quando distribuídas em vários arquivos, as mensagens posteriores de uma chave de ordem podem aparecer em um arquivo com um nome que tem um carimbo de data/hora anterior ao carimbo de data/hora no nome do arquivo com as mensagens anteriores.

Ativar a ordem das mensagens

Para receber as mensagens em ordem, defina a propriedade de ordenação de mensagens na assinatura que as recebe. O recebimento de mensagens pode aumentar a latência. Não é possível mudar a propriedade de ordenação de mensagens depois de criar uma assinatura.

É possível definir a propriedade de ordenação de mensagens ao criar uma assinatura usando o Google Cloud console, a Google Cloud CLI ou a API Pub/Sub.