Este documento pressupõe que você já conhece o processo de assinatura de um tópico do Pub/Sub e o recebimento de mensagens no cliente assinante.
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 Google Cloud CLI ou as bibliotecas de cliente.
Escolha a assinatura certa
O Pub/Sub oferece assinaturas padrão, como assinaturas de push e pull. Além das assinaturas padrão, o Pub/Sub também oferece assinaturas de exportação que permitem armazenar mensagens diretamente em um recurso doGoogle Cloud , sem exigir o Dataflow como intermediário. Por exemplo, as assinaturas do BigQuery armazenam mensagens em uma tabela do BigQuery.
As assinaturas por push são recomendadas para os seguintes cenários:
Não é possível incluir no aplicativo de assinante nenhum código que importe a biblioteca de cliente como uma dependência.
O cliente assinante não pode fazer solicitações de saída.
Você quer usar a mesma instância para processar mensagens de diferentes tópicos e assinaturas em que o cliente assinante não conhece a lista de assinaturas.
Para casos gerais, recomendamos o uso da
biblioteca de cliente de alto nível. Se você estiver
usando pull unário, não defina
returnImmediately
como true. Definir como true afeta negativamente o desempenho de pull.
O campo returnImmediately foi descontinuado.
Para comparar todos os tipos de assinatura e escolher o que melhor se adapta às suas necessidades de negócios, consulte a tabela de comparação de assinaturas do Pub/Sub.
Para saber mais sobre os benefícios de uma assinatura de exportação, consulte Quando usar uma assinatura de exportação.
Processar mensagens antes de confirmá-las
Por padrão, o Pub/Sub descarta uma mensagem de uma assinatura depois que ela é confirmada. Se você não processar uma mensagem antes de enviar uma confirmação e o processamento falhar, o serviço não vai reenviar a mensagem. A exceção é quando você configura a retenção de mensagens confirmadas ou de tópicos e realiza uma operação de busca.
Se você tiver assinantes de alta latência, talvez seja necessário definir valores personalizados para o controle de fluxo e o gerenciamento de locação.
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.
Configurar o controle de fluxo do assinante para picos de tráfego transitórios
O controle de fluxo no lado do assinante permite evitar que os assinantes sejam sobrecarregados por picos de tráfego. Ele pode dar tempo para que os mecanismos de escalonamento automático respondam a um aumento de carga ou pode distribuir o processamento da carga por um período mais longo. O primeiro método reduz a latência, enquanto o segundo reduz os custos.
Para configurar o controle de fluxo, defina
valores apropriados para maximum outstanding messages e
total outstanding message bytes. Os valores padrão dessas variáveis de controle de fluxo e os nomes das variáveis podem ser diferentes entre as bibliotecas de cliente.
Máximo de mensagens pendentes define o número máximo de mensagens entregues ao cliente para as quais o Pub/Sub não recebeu confirmações ou confirmações negativas.
Total de bytes de mensagens pendentes define o tamanho total máximo das mensagens entregues ao cliente para as quais o Pub/Sub não recebeu confirmações ou confirmações negativas.
Se o limite de uma dessas opções for ultrapassado, o cliente assinante não vai extrair mais mensagens. Esse comportamento continua até que as mensagens já extraídas sejam confirmadas ou confirmadas negativamente. Dessa forma, é possível equilibrar a capacidade de processamento com o custo associado à execução de mais assinantes.
Processar entregas duplicadas
Por padrão, o Pub/Sub fornece entrega de mensagens pelo menos uma vez aos assinantes. Isso significa que as mensagens podem ser entregues várias vezes, mesmo que tenham sido confirmadas. As seções a seguir discutem como lidar com cenários comuns de reenvio.
Reenvio consistente de muitas mensagens
Se você estiver enfrentando casos em que muitas mensagens estão sempre sendo reentregues, seus assinantes estão sobrecarregados ou não estão confirmando as mensagens antes que o prazo expire.
Se você estiver usando uma assinatura por pull, talvez seja necessário definir valores personalizados para valores de controle de fluxo ou aumentar os períodos de extensão de locação usando o gerenciamento de locação.
Se você estiver usando assinaturas por push, talvez seja necessário aumentar a configuração do prazo de confirmação. Você também pode seguir as práticas recomendadas sobre como manter uma assinatura saudável.
Reenvio ocasional de mensagens
Quando as mensagens são entregues novamente antes do prazo de confirmação ou depois que as mensagens são confirmadas em alguns segundos, o Pub/Sub está se comportando conforme o esperado. Esses picos de reenvio não devem ocorrer com frequência, mas, quando ocorrem, é provável que aconteçam em várias mensagens simultaneamente. Seu sistema precisa ser criado para tolerar essas duplicações ocasionais.
Nova entrega repetida de algumas mensagens
Quando você notar que um pequeno número de mensagens é entregue várias vezes, primeiro confirme se você as está confirmando. Se não estiver, descubra por que o assinante não está processando as mensagens corretamente. Configure um tópico de mensagens inativas para evitar novas tentativas de entrega. Se você estiver confirmando a mensagem, o Pub/Sub ainda poderá estar funcionando conforme o esperado. Embora seja muito raro, ainda é possível que um pequeno número de mensagens seja entregue várias vezes se houver interrupções internas de rede ou hardware. O serviço tenta se recuperar nesses casos, mas pode levar vários minutos para que as correções sejam ativadas.
Seu sistema precisa ser tolerante a novas entregas. Para reduzir a probabilidade de que isso aconteça, processe e confirme as mensagens o mais rápido possível.
Se o aplicativo não puder tolerar duplicatas, ative a entrega exatamente uma vez. Esse recurso só está disponível para assinaturas por pull e também resulta em maior latência de publicação para assinatura. Avalie se a compensação de uma latência maior é aceitável para seu caso de uso antes de ativar esse recurso.
Práticas recomendadas para mensagens ordenadas na assinatura
Se você usar a ordenação de mensagens, verifique o seguinte:
Escolha assinaturas StreamingPull ou Pull. Para uma assinatura por push, o Pub/Sub aceita apenas uma mensagem pendente para cada chave de ordem por vez. O envio de solicitações de push paralelas em um cenário como esse seria semelhante ao envio de vários lotes de mensagens para a mesma chave de ordenação para assinantes por pull simultaneamente. Portanto, as assinaturas por push não são recomendadas para tópicos em que várias mensagens são publicadas com frequência com a mesma chave de ordenação ou em que a latência é extremamente importante.
Ative a ordenação de mensagens na assinatura. No lado do editor, se você enviar mensagens com uma chave de ordem e na mesma região, poderá configurar os assinantes para receber essas mensagens em ordem. No lado do assinante, ative a propriedade de ordenação de mensagens apenas para as assinaturas em que você quer receber mensagens ordenadas. Dependendo do status da propriedade, cada assinatura anexada ao tópico pode determinar se precisa de entrega ordenada sem afetar as outras.
Confirme as mensagens em ordem. Ao usar a entrega ordenada, as confirmações de mensagens posteriores não são processadas até que as confirmações de mensagens anteriores sejam processadas por chave de ordenação. Por exemplo, se você tiver as mensagens 1, 2 e 3 com a mesma chave de ordem e receber todas elas, mas confirmar apenas a mensagem 3, o serviço não vai considerar a mensagem 3 como confirmada até que as mensagens 1 e 2 também sejam confirmadas. Se as confirmações das mensagens 1 e 2 nunca forem recebidas, as mensagens 1, 2 e 3 serão reenviadas.
Resumo das práticas recomendadas
A tabela a seguir resume as práticas recomendadas neste documento:
| Tópico | Tarefa |
|---|---|
| Escolher um tipo de assinatura | Escolha o tipo de assinatura ideal para as necessidades da sua empresa. Se sua assinatura permitir, use também a biblioteca de cliente de alto nível. |
| Repetir uma mensagem confirmada | Processe uma mensagem antes de confirmá-la. Ou configure para uma operação de busca para não perder as mensagens confirmadas. |
| Controle de fluxo | Configure o controle de fluxo nas configurações do assinante para garantir que os assinantes não fiquem sobrecarregados até que o escalonamento automático seja iniciado ou o tempo passe. |
| Processar entregas duplicadas e preservar IDs de mensagens | Preserve ou ative a geração de registros do messageId recebido para simplificar a solução de problemas de duplicatas, reenvios e mensagens ausentes. |
| Como ordenar mensagens | Ao usar mensagens ordenadas, escolha StreamingPull ou Pull, ative a ordenação de mensagens na assinatura e confirme as mensagens em ordem. |
A seguir
Práticas recomendadas para publicar em um tópico do Pub/Sub.
Práticas recomendadas para usar métricas do Pub/Sub como um indicador de escalonamento.