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.

Neste documento, presumimos que você já conhece 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 saiba como executar o Pub/Sub usando o console, a 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. Decida 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 o caso de uso não exigir a publicação de todas as mensagens).
  • Tente publicar novamente em uma falha potencialmente temporária, como um erro Deadline exceeded.
  • Persista a mensagem em um arquivo ou armazenamento para tentar publicá-la novamente 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 conforme o esperado para seus assinantes, verifique se está acompanhando os resultados das publicações e se elas foram bem-sucedidas.

Se a publicação for bem-sucedida, o resultado da chamada de publicação será o ID da mensagem publicada.

Preservar IDs de mensagens

Para facilitar a solução de problemas, os editores e assinantes precisam preservar os IDs das mensagens publicadas. É possível armazenar o ID de cada mensagem publicada ou ativar a geração de registros de IDs de mensagens, conforme necessário. Manter os IDs de mensagem facilita a solução de problemas de mensagens duplicadas, reenvios, perda de dados e outros problemas comuns. Para mais informações, consulte Como lidar com duplicatas.

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 o seguinte:

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ê usa bibliotecas de cliente para publicar suas mensagens, o lote é ativado por padrão. O loteamento (ou agrupamento) de mensagens ajuda o editor a melhorar a eficiência e enviar mensagens com uma capacidade de processamento maior. O processamento em 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 leva para uma mensagem ser publicada por um editor e entregue aos assinantes correspondentes para processamento.

  • A latência de publicação é o tempo que leva para publicar uma mensagem.

Ao usar o lote, aumentar os 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 definir as configurações de lote, é possível 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 ser diferentes entre as bibliotecas de cliente. É possível especificar um ou todos os três valores na biblioteca de cliente. Se qualquer um 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 temporários

Se o cliente do 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 fiquem sobrecarregados com muitas solicitações pendentes. Se o cliente do 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 apropriados para as variáveis de máximo de mensagens pendentes e máximo de bytes de mensagens pendentes. Esses valores equilibram a capacidade de processamento de mensagens e a capacidade do sistema.

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

Entender a largura de banda e a latência da 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 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. Com mais núcleos de máquina disponíveis, é possível definir uma contagem de linhas de execução mais alta 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 no lado do cliente, como CPUs de serviço insuficientes, integridade de thread ruim ou congestionamento de rede. O publisher retry policy determina o comportamento em caso de falha na entrega da mensagem. A política de repetição define o número de vezes que o Pub/Sub tenta entregar a mensagem e o tempo entre cada tentativa.

Por exemplo, na biblioteca de cliente Java para Pub/Sub, o cliente do 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 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 RPC seja concluída. O valor padrão é 5 seconds.

  • rpcTimeoutMultiplier. O fator de multiplicação usado para calcular o tempo limite da 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 nova tentativa e de até 10 seconds * 4 = 40 seconds para a terceira.

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

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

Só faça ajustes nos valores especificados se as configurações de repetição 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 lote nessas circunstâncias. Se você estiver publicando de 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ó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 regiões doGoogle Cloud que você especificar, independentemente de onde as solicitações de publicação se originam.

Use a política de armazenamento de mensagens para especificar uma lista de regiões do Google Cloud 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 da organização 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 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 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, somente 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 regiões, eles vão receber todas as mensagens em ordem. Use um endpoint de local para publicar mensagens na mesma região.

  • Configurar uma função de retomada de publicação. Quando uma biblioteca de cliente tenta novamente uma solicitação e a mensagem tem uma chave de ordenação, a biblioteca de cliente tenta novamente a solicitação, independentemente das configurações de nova tentativa. Se ocorrer um erro não repetível, 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 você estiver pronto para continuar publicando em uma chave de ordenação que teve uma falha na publicação, 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.
Agrupar mensagens em uma solicitação de publicação Agrupar mensagens em lote ou em grupo para aumentar a eficiência do editor e enviar mensagens com uma capacidade de processamento maior.
Controle de fluxo Configure o controle de fluxo nas configurações do editor para lidar com picos de tráfego temporários.
Como testar clientes do Pub/Sub para maximizar o desempenho de streaming Escalone a capacidade do editor com um aumento nos núcleos de máquina e na largura de banda de rede disponíveis.
Solicitações de nova tentativa Faça ajustes nos valores especificados da política de repetição 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.
Use um endpoint de local ao usar chaves de ordem 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