Práticas recomendadas para publicar em um tópico do Pub/Sub

Na publicação, um cliente editor envia uma mensagem para um tópico do Pub/Sub. Confira algumas práticas recomendadas para publicar mensagens no Pub/Sub.

Este documento pressupõe que você já esteja familiarizado com o processo de publicação de mensagens em um tópico do Pub/Sub.

Se você não conhece o Pub/Sub, consulte um dos guias de início rápido e aprenda a executar o Pub/Sub usando o console, CLI gcloud ou as bibliotecas de cliente.

Entre em ação com base na resposta da publicação

Quando a chamada de publicação da biblioteca de cliente de alto nível é concluída, ela retorna um objeto futuro que contém o resultado da operação. Para evitar o bloqueio de solicitações de publicação individuais, processe o resultado de forma assíncrona. Você precisa decidir a melhor maneira de lidar com a falha para seu caso de uso. Veja algumas opções:

  • Registre o erro e não faça mais nada (se o caso de uso não exigir a publicação bem-sucedida de todas as mensagens).
  • Tente publicar novamente em uma falha potencialmente transitória, como um erro Deadline exceeded.
  • Persista a mensagem em um arquivo ou armazenamento para tentar publicá-la mais tarde, especialmente em um erro que exige intervenção do usuário, como Not found ou Permission denied.
  • Propague os erros para o serviço upstream que enviou a mensagem que você tentou publicar.

Se você acredita que o Pub/Sub não está entregando mensagens conforme o esperado aos assinantes, verifique se você está rastreando os resultados das publicações e se elas foram bem-sucedidas.

Anexe uma assinatura ou ative a retenção de tópicos antes de começar a publicar

Se você começar a publicar em um tópico que não tem um assinante anexado, as mensagens não serão retidas. Essas mensagens não podem ser entregues a assinaturas anexadas posteriormente. Portanto, antes de começar a publicar mensagens, faça uma das seguintes ações:

  • Anexe uma assinatura a um tópico. Escolha um dos seguintes métodos:

  • Ative a retenção de mensagens de tópicos.

    A retenção de mensagens de tópicos permite que uma assinatura reproduza mensagens publicadas antes de você criar uma assinatura. Se a retenção de mensagens de tópicos estiver ativada, os custos de armazenamento das mensagens retidas pelo tópico serão faturados no projeto em que o tópico está localizado.

Configurar mensagens em lote

No Pub/Sub, as mensagens em lote se referem ao processo de combinar várias mensagens em um lote que é publicado em uma única solicitação de publicação. Se você usar bibliotecas de cliente para publicar suas mensagens, o lote será ativado por padrão. O lote (ou agrupamento) de mensagens ajuda o editor a melhorar a eficiência e enviar mensagens com maior capacidade de processamento. O lote reduz o custo de publicação de dados. No entanto, o lote também cria latência para mensagens individuais, porque o editor aguarda o lote ser preenchido antes de publicá-lo.

A latência no Pub/Sub pode ser de dois tipos:

  • A latência de ponta a ponta é o tempo que uma mensagem leva para ser publicada por um editor e entregue aos assinantes correspondentes para processamento.

  • A latência de publicação é o tempo necessário para publicar uma mensagem.

Ao usar o lote, o aumento dos dois tipos de latência é uma compensação para melhorar a eficiência e a capacidade de processamento.

É possível agrupar mensagens em uma biblioteca de cliente com base no tamanho da solicitação de mensagem, no número de mensagens e no tempo. Ao configurar as configurações de lote, você pode encontrar o equilíbrio certo entre custo, capacidade de processamento e latência para atender ao seu caso de uso.

Os valores padrão das variáveis de mensagens em lote e os nomes das variáveis podem variar entre as bibliotecas de cliente. É possível especificar um ou todos os três valores na biblioteca de cliente. Se algum dos valores das variáveis de mensagens em lote for atendido, a biblioteca de cliente publicará o próximo lote de mensagens.

Para configurar mensagens em lote para um cliente editor, consulte Mensagens em lote em uma solicitação de publicação.

Configurar o controle de fluxo para picos de mensagens transitórios

Se o cliente editor tiver que processar um grande número de mensagens, as solicitações de publicação poderão começar a se acumular na memória até que as mensagens não sejam publicadas com um erro Deadline exceeded.

Para resolver picos transitórios na publicação de mensagens, use o controle de fluxo nas configurações do editor. O controle de fluxo do lado do editor impede que os recursos do cliente editor fiquem sobrecarregados com muitas solicitações pendentes. Se o cliente editor ficar restrito em termos de memória, CPU ou linhas de execução, um grande número de erros Deadline exceeded será gerado.

Para configurar o controle de fluxo na biblioteca de cliente, defina valores adequados para as variáveis maximum outstanding messages e maximum outstanding message bytes. Esses valores equilibram a capacidade de processamento de mensagens e a capacidade do sistema.

Para verificar se a biblioteca de cliente oferece suporte ao controle de fluxo do editor e para configurar isso, consulte Controle de fluxo.

Entender a largura de banda e a latência da rede

A capacidade de processamento do editor é limitada pela largura de banda da rede e pelo número de solicitações enviadas. Se a largura de banda for boa, mas a latência da rede for alta, não sobrecarregue o sistema com muitas solicitações pequenas. O controle de fluxo do lado do editor pode ajudar com problemas de rede do lado do cliente.

A capacidade de processamento do editor também é limitada pela CPU e pela memória. Mais núcleos de máquina disponíveis permitem definir uma contagem de linhas de execução maior para melhorar a capacidade de publicação. Para entender melhor como maximizar o desempenho do streaming, consulte Como testar clientes do Cloud Pub/Sub para maximizar o desempenho do streaming.

Ajustar as variáveis de solicitação de nova tentativa para publicações com falha

Quando uma mensagem é publicada por um cliente editor, podem ocorrer falhas de publicação. Essas falhas são normalmente causadas por gargalos do lado do cliente, como CPUs de serviço insuficientes, integridade da linha de execução ruim ou congestionamento da rede. A publisher retry policy determina o comportamento em caso de falha na entrega de mensagens. A política de nova tentativa define o número de vezes que o Pub/Sub tenta entregar a mensagem e o período entre cada tentativa.

Por exemplo, na biblioteca de cliente Java para Pub/Sub, o cliente editor contém os seguintes valores:

  • initialRetryDelay. O atraso inicial que o editor aguarda antes de tentar novamente uma operação de publicação. O valor padrão é 100 milliseconds.

  • retryDelayMultiplier. O fator de multiplicação usado para calcular o atraso entre as novas tentativas. O valor padrão é 4. Isso significa que o atraso entre as novas tentativas é de até 100 milliseconds * 4 = 400 milliseconds para a segunda tentativa e até 400 milliseconds * 4 = 1600 milliseconds para a terceira.

  • maxRetryDelay. O atraso máximo que o editor aguarda antes de tentar novamente uma operação de publicação. O valor padrão é 60 seconds.

  • initialRpcTimeout. O tempo limite inicial que o editor aguarda para que a chamada de RPC seja concluída. O valor padrão é 5 seconds.

  • rpcTimeoutMultiplier. O fator de multiplicação usado para calcular o tempo limite de RPC. O valor padrão é 4.0. Isso significa que o tempo limite para a chamada de RPC é de até 5 seconds * 4 = 20 seconds para a segunda tentativa e até 10 seconds * 4 = 40 seconds para a terceira.

  • maxRpcTimeout. O tempo limite máximo que o editor aguarda para que a chamada de RPC seja concluída. O valor padrão é 600 seconds.

  • totalTimeout. O tempo limite total para a operação de publicação. Isso inclui o tempo gasto esperando a conclusão da chamada de RPC e o tempo gasto esperando entre as novas tentativas. O valor padrão é 600 seconds.

Faça ajustes nos valores especificados somente se as configurações de nova tentativa padrão não forem suficientes para seu caso de uso. Por exemplo, a publicação de um grande número de mensagens não exigiria que você aumentasse os valores initialRetryDelay e maxRetryDelay. No entanto, é possível ajustar o controle de fluxo e o lote nessas circunstâncias. Se você estiver publicando de uma conexão de Internet instável ou de uma conexão com largura de banda limitada, experimente os valores das variáveis initialRpcTimeout, maxRpcTimeout e rpcTimeoutMultiplier. Para valores recomendados, consulte Falha nas operações de publicação com DEADLINE_EXCEEDED.

Usar a política de armazenamento de mensagens para garantir a localidade dos dados

A política de armazenamento de mensagens de tópicos do Pub/Sub oferece uma maneira de garantir que as mensagens publicadas em um tópico nunca sejam mantidas fora de um conjunto de Google Cloud regiões especificadas, independentemente da origem das solicitações de publicação.

Use a política de armazenamento de mensagens para especificar uma lista de Google Cloud regiões em que o Pub/Sub pode armazenar dados de mensagens no disco. Quando uma mensagem é publicada em uma região que não está nessa lista, a solicitação é encaminhada para a região permitida mais próxima para processamento. A política pode ser configurada em um tópico ou como uma política organizacional para um projeto, pasta de projeto ou uma organização inteira. Quando uma política organizacional é configurada, a política de tópico individual só pode ser alterada de maneiras que não violem a política organizacional.

Por exemplo, uma empresa que opera na Europa pode usar a política de armazenamento de mensagens para garantir que todos os dados sejam armazenados em regiões da UE para obedecer às leis locais.

Para mais informações, consulte Configurar políticas de armazenamento de mensagens.

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

Se você usar a ordenação de mensagens, verifique o seguinte:

  • Usar endpoints de localização. A ordenação de mensagens é preservada no lado da publicação e em uma região. Em outras palavras, se você estiver publicando mensagens em várias regiões, apenas as mensagens na mesma região serão entregues em uma ordem consistente. Se todas as mensagens forem publicadas na mesma região, mas os assinantes estiverem distribuídos por regiões, eles receberão todas as mensagens em ordem. Use um endpoint de localização para publicar mensagens na mesma região.

  • Configurar uma função de publicação de currículo. Quando uma biblioteca de cliente repete uma solicitação e a mensagem tem uma chave de ordem, ela repete repetidamente a solicitação, independentemente das configurações de tentativa. Se ocorrer um erro não passível de repetição, a biblioteca de cliente não publicará a mensagem e interromperá a publicação de outras mensagens com a mesma chave de ordem. Quando estiver tudo pronto para continuar a publicação em uma chave de ordem que tenha uma publicação com falha, chame o resumePublish método.

Resumo das práticas recomendadas

A tabela a seguir resume as práticas recomendadas neste documento:

Tópico Tarefa
Configurar a retenção de mensagens Anexe uma assinatura antes de publicar ou ativar a retenção de mensagens.
Mensagens em lote em uma solicitação de publicação Agrupe ou agrupe mensagens para aumentar a eficiência do editor e enviar mensagens com maior capacidade de processamento.
Controle de fluxo Configure o controle de fluxo nas configurações do editor para lidar com picos de tráfego transitórios.
Testar clientes do Pub/Sub para maximizar o desempenho do streaming performance Escalar a capacidade de processamento do editor com um aumento nos núcleos de máquina e na largura de banda da rede disponíveis.
Tentar novamente solicitações Faça ajustes nos valores especificados da política de nova tentativa do editor somente se as configurações padrão não forem suficientes para seu caso de uso.
Configurar políticas de armazenamento de mensagens Use a política de armazenamento de mensagens para armazenar dados de mensagens no disco apenas em locais específicos.
Usar um endpoint de localização ao usar chaves de ordenação na publicação Ao usar mensagens ordenadas, use um endpoint de localização e configure uma função de publicação de currículo para falhas de publicação.

A seguir