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

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

Este documento pressupõe que já está familiarizado com o processo de publicação de mensagens num tópico do Pub/Sub.

Se está a começar a usar o Pub/Sub, consulte um dos guias de início rápido e saiba como executar o Pub/Sub através da consola, da CLI gcloud ou das bibliotecas de cliente.

Tome medidas com base na resposta da publicação

Quando a chamada de publicação da biblioteca cliente de alto nível é concluída, devolve um objeto futuro que contém o resultado da operação. Para evitar o bloqueio de pedidos de publicação individuais, processe o resultado de forma assíncrona. Deve decidir qual a melhor forma de lidar com a falha para o seu exemplo de utilização. Algumas opções incluem:

  • Registe o erro e não faça mais nada (se o seu exemplo de utilização não exigir a publicação bem-sucedida de todas as mensagens).
  • Tente novamente a publicação numa falha potencialmente temporária, como um erro Deadline exceeded.
  • Persista a mensagem num ficheiro ou num armazenamento para tentar publicá-la mais tarde, especialmente num erro que exija a intervenção do utilizador, como Not found ou Permission denied.
  • Propagar os erros ao serviço a montante que lhe enviou a mensagem que tentou publicar.

Se considerar que o Pub/Sub não está a enviar mensagens como esperado aos seus subscritores, verifique se está a acompanhar os resultados das publicações e se as publicações foram bem-sucedidas.

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

Se começar a publicar num tópico que não tenha um subscritor anexado, as mensagens não são retidas. Não é possível entregar estas mensagens a subscrições anexadas posteriormente. Por isso, antes de começar a publicar mensagens, efetue uma das seguintes ações:

Configure o envio de mensagens em lote

No Pub/Sub, as mensagens em lote referem-se ao processo de combinar várias mensagens num lote que é publicado num único pedido de publicação. Se usar bibliotecas de cliente para publicar as suas mensagens, o processamento em lote está ativado por predefinição. O processamento em lote (ou agrupamento) de mensagens ajuda o publicador a melhorar a respetiva eficiência e a enviar mensagens com um débito mais elevado. O processamento em lote reduz o custo de publicação de dados. No entanto, o processamento em lote também cria latência para mensagens individuais, porque o publicador aguarda que o lote seja preenchido antes de o publicar.

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

  • A latência ponto a ponto é o tempo que uma mensagem demora a ser publicada por um publicador e entregue aos subscritores correspondentes para processamento.

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

Quando usa o processamento em lote, o aumento de ambos os tipos de latências é uma compensação para melhorar a eficiência e o débito.

Pode processar mensagens em lote numa biblioteca de cliente com base no tamanho do pedido de mensagens, no número de mensagens e no tempo. Quando configurar as definições de processamento em lote, pode encontrar o equilíbrio certo entre o custo, o débito e a latência para se adequar ao seu exemplo de utilização.

Os valores predefinidos das variáveis de mensagens em lote e os nomes das variáveis podem diferir entre as bibliotecas de cliente. Pode 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 cumprido, a biblioteca de cliente publica o lote seguinte de mensagens.

Para configurar o envio de mensagens em lote para um cliente publicador, consulte o artigo Mensagens em lote num pedido de publicação.

Configure o controlo de fluxo para picos de mensagens transitórios

Se o cliente publicador tiver de processar um grande número de mensagens, os pedidos de publicação podem começar a acumular-se na memória até que a publicação das mensagens falhe com um erro Deadline exceeded.

Para resolver picos transitórios na publicação de mensagens, pode usar o controlo de fluxo nas definições do publicador. O controlo de fluxo do lado do publicador impede que os recursos do cliente do publicador fiquem sobrecarregados com demasiados pedidos pendentes. Se o cliente publicador ficar limitado em termos de memória, CPU ou threads, é gerado um grande número de erros Deadline exceeded.

Para configurar o controlo de fluxo na biblioteca de cliente, defina valores adequados para as variáveis maximum outstanding messages e maximum outstanding message bytes. Estes valores equilibram o débito de mensagens e a capacidade do sistema.

Para verificar se a sua biblioteca de cliente suporta o controlo de fluxo do publicador e para o configurar, consulte Controlo de fluxo.

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

O débito do publicador é limitado pela largura de banda da rede e pelo número de pedidos enviados. Se a sua largura de banda for boa, mas a latência da rede for elevada, não deve sobrecarregar o sistema com muitos pedidos pequenos. O controlo de fluxo do lado do publicador pode ajudar a resolver problemas de rede do lado do cliente.

O débito do publicador também está limitado pela CPU e pela memória. Ter mais núcleos da máquina permite-lhe definir uma contagem de threads mais elevada para um melhor débito de publicação. Para compreender melhor como maximizar o desempenho do streaming, consulte o artigo Testar clientes do Cloud Pub/Sub para maximizar o desempenho do streaming.

Ajuste as variáveis do pedido de nova tentativa para publicações com falhas

Quando uma mensagem é publicada por um cliente publicador, podem ocorrer falhas de publicação. Normalmente, estas falhas são causadas por gargalos do lado do cliente, como CPUs de serviço insuficientes, estado de funcionamento dos threads deficiente ou congestionamento da rede. O elemento 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 período entre cada tentativa.

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

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

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

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

  • initialRpcTimeout. O tempo limite inicial que o publicador aguarda pela conclusão da chamada RPC. O valor predefinido é 5 seconds.

  • rpcTimeoutMultiplier. O fator de multiplicação usado para calcular o tempo limite de RPC. O valor predefinido é 4.0. Isto significa que o limite de tempo 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 tentativa.

  • maxRpcTimeout. O tempo limite máximo que o publicador aguarda pela conclusão da chamada RPC. O valor predefinido é 600 seconds.

  • totalTimeout. O tempo limite total para a operação de publicação. Isto inclui o tempo gasto à espera que a chamada RPC seja concluída e o tempo gasto à espera entre novas tentativas. O valor predefinido é 600 seconds.

Ajuste apenas os valores especificados se considerar que as definições de repetição predefinidas não são suficientes para o seu exemplo de utilização. Por exemplo, a publicação de um grande número de mensagens não requer que aumente os valores de initialRetryDelay e maxRetryDelay. No entanto, pode ajustar o controlo de fluxo e o processamento em lote nestas circunstâncias. Se estiver a publicar a partir de uma ligação à Internet instável ou uma ligação com restrições de largura de banda, pode experimentar os valores das variáveis initialRpcTimeout, maxRpcTimeout e rpcTimeoutMultiplier. Para ver os valores recomendados, consulte o artigo As operações de publicação falham com DEADLINE_EXCEEDED.

Use 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 forma de garantir que as mensagens publicadas num tópico nunca são mantidas fora de um conjunto deGoogle Cloud regiões que especifica, independentemente da origem dos pedidos de publicação.

Use a política de armazenamento de mensagens para especificar uma lista de Google Cloud regiões onde o Pub/Sub tem autorização para armazenar dados de mensagens no disco. Quando uma mensagem é publicada numa região que não consta desta lista, o pedido é encaminhado para a região permitida mais próxima para processamento. A política pode ser configurada num tópico ou como uma política organizacional para um projeto, uma pasta de projetos ou uma organização inteira. Quando uma política da organização está configurada, a política de tópicos individual só pode ser alterada de formas 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 são armazenados em regiões da UE de modo a agir em conformidade com as leis locais.

Para mais informações, consulte o artigo Configure políticas de armazenamento de mensagens.

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

Se usar a ordenação de mensagens, certifique-se do seguinte:

  • Use pontos finais de localização. A ordem das mensagens é preservada no lado de publicação e numa região. Por outras palavras, se estiver a publicar mensagens em várias regiões, apenas as mensagens na mesma região são entregues numa ordem consistente. Se as suas mensagens forem todas publicadas na mesma região, mas os seus subscritores estiverem distribuídos por várias regiões, os subscritores recebem todas as mensagens por ordem. Use um ponto final de localização para publicar mensagens na mesma região.

  • Configure uma função de publicação de currículos. Quando uma biblioteca cliente tenta novamente um pedido e a mensagem tem uma chave de ordenação, a biblioteca cliente tenta novamente o pedido repetidamente, independentemente das definições de repetição. Se ocorrer um erro não repetível, a biblioteca de cliente não publica a mensagem e para de publicar outras mensagens com a mesma chave de ordenação. Quando tiver tudo pronto para continuar a publicação numa chave de ordenação com uma publicação com falhas, chame o método resumePublish.

Resumo das práticas recomendadas

A tabela seguinte resume as práticas recomendadas neste documento:

Tópico Tarefa
Configure a retenção de mensagens Anexe uma subscrição antes de publicar ou ativar a retenção de mensagens.
Agrupe mensagens num pedido de publicação Agrupe as mensagens para aumentar a eficiência do publicador e envie mensagens com um débito mais elevado.
Controlo do fluxo Configure o controlo de fluxo nas definições do publicador para processar picos de tráfego transitórios.
Testar clientes do Pub/Sub para maximizar o desempenho do streaming Aumente o débito do publicador com um aumento nos núcleos da máquina disponíveis e na largura de banda da rede.
Pedidos de nova tentativa Ajuste os valores especificados da política de repetição do publicador apenas se considerar que as predefinições não são suficientes para o seu exemplo de utilização.
Configure as políticas de armazenamento de mensagens Use a política de armazenamento de mensagens para armazenar dados de mensagens no disco apenas em localizações específicas.
Use um ponto final de localização quando usar chaves de ordenação na publicação Quando usar mensagens ordenadas, use um ponto final de localização e configure uma função de retoma da publicação para falhas de publicação.

O que se segue?