Neste documento, você encontra algumas dicas comuns de solução de problemas para assinaturas StreamingPull do Pub/Sub. As assinaturas do StreamingPull usam a API StreamingPull.
Leia mais sobre assinaturas do StreamingPull no Guia do assinante de pull.
StreamingPull tem uma taxa de erro de 100%
Os streams do StreamingPull sempre fecham com um status não OK. Ao contrário de RPCs unárias, esse status para StreamingPull é simplesmente uma indicação de que o stream está corrompido. As solicitações não estão falhando. Portanto, embora a API StreamingPull possa ter uma taxa de erro surpreendentemente de 100%, esse comportamento é intencional.
Erros de pré-condição com falha, indisponíveis ou não encontrados
Como os streams do StreamingPull sempre são fechados com um erro, não é útil examinar as métricas de encerramento do stream ao diagnosticar erros. Em vez disso, concentre-se na métrica de resposta do StreamingPull, como subscription/streaming_pull_response_count.
Procure por estes erros:
Erros de pré-condição com falha que podem ocorrer nestes casos:
O Pub/Sub tenta descriptografar uma mensagem com uma chave desativada do Cloud KMS.
As assinaturas serão temporariamente suspensas se houver mensagens no backlog da assinatura criptografadas com uma chave desativada do Cloud KMS.
Erros indisponíveis que podem ocorrer quando o Pub/Sub não processa uma solicitação. Provavelmente, essa é uma condição temporária, e a biblioteca de cliente tenta realizar as solicitações novamente.
Erros não encontrados que podem ocorrer quando a assinatura é excluída ou nunca existiu. O último caso acontece quando você fornece um caminho de assinatura inválido.
Grande backlog de pequenas mensagens em uma assinatura StreamingPull
A pilha gRPC StreamingPull está otimizada para alta capacidade e, portanto, armazena mensagens em buffers. Se você estiver tentando processar grandes backlogs de pequenas mensagens, poderá ver mensagens entregues várias vezes. Talvez essas mensagens não tenham um balanceamento de carga eficaz entre os clientes.
O buffer entre o serviço Pub/Sub e o espaço de usuário da biblioteca de cliente é de aproximadamente 10 MB. Para entender o efeito desse buffer no comportamento da biblioteca de cliente, considere este exemplo:
Há um backlog de 10.000 mensagens de 1 KB em uma assinatura.
Cada mensagem leva um segundo para o processamento sequencial por uma instância de cliente com uma linha de execução única.
a primeira instância do cliente a estabelecer uma conexão StreamingPull com o serviço para essa assinatura preenche o buffer com todas as 10.000 mensagens.
O buffer leva 10.000 segundos (quase três horas).
Nesse período, algumas mensagens em buffer excedem os prazos de confirmação e são reenviadas para o mesmo cliente, resultando em duplicatas.
Quando várias instâncias de cliente estão em execução, as mensagens presas no buffer de um cliente não ficam disponíveis para nenhuma outra instância de cliente. Essa situação não ocorrerá se você usar o controle de fluxo para o StreamingPull. O serviço nunca tem todos os 10 MB de mensagens por vez e é possível balancear a carga de mensagens com eficiência entre vários assinantes.