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ê é novo no Pub/Sub, consulte um dos guias de início rápido e aprenda a executar o Pub/Sub usando o console, a CLI do gCloud ou as bibliotecas de cliente.

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 uma destas ações:

Configurar mensagens em lote

No Pub/Sub, a mensagem 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 suas mensagens, o agrupamento é ativado por padrão. O agrupamento de mensagens ajuda o editor a melhorar a eficiência e enviar mensagens com uma capacidade maior. A execução em lote reduz o custo de publicação de dados. No entanto, o agrupamento também cria latência para mensagens individuais, porque o editor espera que o lote seja preenchido antes de publicar.

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 que leva para publicar uma mensagem.

Ao usar o lote, aumentar os dois tipos de latência é uma troca para melhorar a eficiência e o throughput.

É possível agrupar mensagens em uma biblioteca de cliente com base no tamanho da solicitação de mensagem, número de mensagens e tempo. Ao configurar as configuraçõ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 e os nomes das variáveis de mensagens em lote podem ser diferentes nas 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 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 de mensagens temporárias

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 falhem com um erro Deadline exceeded.

Para resolver picos temporários na publicação de mensagens, use o controle de fluxo nas configurações do editor. O controle de fluxo do editor impede que os recursos do cliente do editor sejam sobrecarregados com muitas solicitações pendentes. Se o cliente do 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 mensagens pendentes máximas e bytes de mensagens pendentes máximos. Esses valores equilibram a capacidade do sistema e a taxa de transferência de mensagens.

Para verificar se a biblioteca de cliente oferece suporte ao controle de fluxo do editor e configurá-la, 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 editor pode ajudar com problemas de rede do lado do cliente.

A taxa de transferência do editor também está vinculada à CPU e à memória. Mais núcleos de máquina disponíveis permitem que você defina uma contagem de linhas 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 do 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 tempo entre cada tentativa.

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

  • initialRetryDelay. O atraso inicial que o editor espera 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 intervalo 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 espera 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 de até 10 seconds * 4 = 40 seconds para a terceira.

  • maxRpcTimeout. O tempo limite máximo que o editor espera para 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 aguardando a conclusão da chamada de RPC e o tempo de espera entre as novas tentativas. O valor padrão é 600 seconds.

Faça ajustes nos valores especificados apenas se as configurações padrão de repetição não forem suficientes para seu caso de uso. Por exemplo, a publicação de 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 nessas circunstâncias. Se você estiver publicando com uma conexão de Internet instável ou com restrição de largura de banda, experimente 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 de 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 armazenadas fora de um conjunto de regiões do Google Cloud especificado, independente da origem das solicitações de publicação.

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á nesta lista, a solicitação é encaminhada para a região permitida mais próxima para processamento. A política pode ser configurada em um tema 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 tópicos individuais 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 em conformidade com 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ê usa a ordenação de mensagens, confira o seguinte:

  • Usar endpoints de localização. A ordem das mensagens é preservada no lado da publicação e dentro de 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 regiões, eles vão receber todas as mensagens na ordem. Use um endpoint de localização para publicar mensagens na mesma região.

  • Configure uma função de publicação de currículos. Quando uma biblioteca de cliente repete uma solicitação e a mensagem tem uma chave de ordenação, ela 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 vai parar de publicar outras mensagens com a mesma chave de ordenação. Quando estiver tudo 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.
Mensagens em lote em uma solicitação de publicação Envie mensagens em lote ou em grupo para aumentar a eficiência do editor 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 temporários.
Teste de clientes do Pub/Sub para maximizar o desempenho do streaming Aumente a capacidade do editor com um aumento no número de núcleos de máquina disponíveis e na largura de banda da rede.
Repetir 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 em disco apenas em locais específicos.
Usar 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 da publicação para falhas de publicação.

A seguir