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á conhece o processo de publicação de mensagens em um tópico do Pub/Sub.

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

Realizar ações 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 no seu caso de uso. Veja algumas opções:

  • Registre o erro e não faça mais nada se seu caso de uso não exigir a publicação bem-sucedida de todas as mensagens.
  • Tente publicar de novo em caso de uma falha potencialmente temporá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 exija 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 aos assinantes conforme o esperado, 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 sem 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 o seguinte:

Configurar mensagens em lote

No Pub/Sub, o envio de mensagens em lote se refere ao processo de combinar várias mensagens em um lote que é publicado em uma única solicitação de publicação. Se você usa bibliotecas de cliente para publicar mensagens, o loteamento é ativado por padrão. O agrupamento de mensagens ajuda o editor a melhorar a eficiência e enviar mensagens com maior capacidade. O agrupamento em lotes reduz o custo de publicação de dados. No entanto, o agrupamento também cria latência para mensagens individuais porque o editor aguarda o preenchimento do lote 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 agrupamento em lote, aumentar os dois tipos de latências é uma troca 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 opções de lote, você pode encontrar o equilíbrio certo entre custo, capacidade de processamento e latência para se adequar 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 um dos valores das variáveis de mensagens em lote for atendido, a biblioteca de cliente vai 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 transitórios de mensagens

Se o cliente editor precisar 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 lidar com 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 do editor sejam sobrecarregados com muitas solicitações pendentes. Se o cliente editor ficar limitado 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 máximo de mensagens pendentes e máximo de bytes de mensagens pendentes. Esses valores equilibram a capacidade do sistema e a capacidade de processamento de mensagens.

Para verificar se a biblioteca de cliente é compatível com o controle de fluxo do editor e para configurá-lo, consulte Controle de fluxo.

Entenda a largura de banda e a latência da sua rede

A capacidade de processamento do publisher é 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 de 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.

O throughput do editor também é limitado pela CPU e pela memória. Com mais núcleos de máquina disponíveis, é possível 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 geralmente são causadas por gargalos do lado do cliente, como CPUs de serviço insuficientes, integridade da linha de execução ruim ou congestionamento da rede. O publisher retry policy determina o comportamento em caso de falha na entrega da mensagem. A política de nova tentativa define o número de vezes que o Pub/Sub tenta entregar a mensagem e o intervalo de tempo 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 tentativas. O valor padrão é 4. Isso significa que o atraso entre as tentativas é de até 100 milliseconds * 4 = 400 milliseconds para a segunda tentativa e de 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 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 a conclusão da chamada de RPC. O valor padrão é 600 seconds.

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

Faça ajustes nos valores especificados apenas se as configurações de nova tentativa padrão não forem suficientes para seu caso de uso. Por exemplo, publicar um grande número de mensagens não exige que você aumente os valores initialRetryDelay e maxRetryDelay. No entanto, é possível ajustar o controle de fluxo e o agrupamento em lote nessas circunstâncias. Se você estiver publicando com uma conexão de Internet instável ou com largura de banda limitada, teste os valores das variáveis initialRpcTimeout, maxRpcTimeout e rpcTimeoutMultiplier. Para valores recomendados, consulte As operações de publicação falham 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ópico 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 que você especificar, 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, uma pasta de projeto ou uma organização inteira. Quando uma política da organização é configurada, a política de um tópico individual só pode ser alterada de maneiras que não violem a política da organização.

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 e cumprir as 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:

  • Use endpoints de localização. A ordem das 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 espalhados por várias regiões, eles vão receber todas as mensagens em ordem. Use um endpoint de local para publicar mensagens na mesma região.

  • Configure 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 ordenação, a biblioteca de cliente repete a solicitação várias vezes, independente das configurações de repetição. 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 ordenação. Quando estiver tudo pronto para continuar publicando em uma chave de pedido que teve uma publicação com falha, chame o método resumePublish.

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 envie mensagens em lote para aumentar a eficiência do publisher e enviar mensagens com uma capacidade maior.
Controle de fluxo Configure o controle de fluxo nas configurações do editor para lidar com picos de tráfego transitórios.
Teste de clientes do Pub/Sub para maximizar o desempenho do streaming Aumente a capacidade de processamento do editor com um aumento nos núcleos de máquina e na largura de banda da rede disponíveis.
Repetir solicitações Ajuste os 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 em disco apenas em locais específicos.
Use um endpoint de local ao usar chaves de ordenação na publicação Ao usar mensagens ordenadas, use um endpoint de local e configure uma função de retomada de publicação para falhas de publicação.

A seguir