Questo documento fornisce alcuni suggerimenti comuni per la risoluzione dei problemi relativi alle sottoscrizioni StreamingPull di Pub/Sub. Le sottoscrizioni StreamingPull utilizzano l'API StreamingPull.
Leggi ulteriori informazioni sulle sottoscrizioni StreamingPull nella guida per gli abbonati Pull.
StreamingPull ha una percentuale di errore del 100%
Gli stream StreamingPull si chiudono sempre con uno stato non OK. A differenza delle RPC unari, questo stato per StreamingPull è semplicemente un'indicazione che il flusso è interrotto. Le richieste non vengono completate. Pertanto, anche se l'API StreamingPull potrebbe avere una sorprendente percentuale di errore del 100%, questo comportamento è stato progettato.
Errore condizione preliminare, errore non disponibile o non trovato
Poiché i flussi StreamingPull si chiudono sempre con un errore, non è utile esaminare le metriche di terminazione dei flussi durante la diagnosi degli errori. Concentrati invece sulla metrica di risposta StreamingPull, come subscription/streaming_pull_response_count.
Cerca questi errori:
Errori di precondizione non riuscita che possono verificarsi nei seguenti casi:
Pub/Sub tenta di decriptare un messaggio con una chiave Cloud KMS disabilitata.
Gli abbonamenti sono temporaneamente sospesi se nel backlog dell'abbonamento sono presenti messaggi criptati con una chiave Cloud KMS disattivata.
Errori non disponibili che possono verificarsi quando Pub/Sub non è in grado di elaborare una richiesta. Molto probabilmente si tratta di una condizione temporanea e la libreria client ritenta le richieste.
Errori Non trovato che possono verificarsi quando l'abbonamento viene eliminato o non è mai esistito. Il secondo caso si verifica quando fornisci un percorso di abbonamento non valido.
Backlog di grandi dimensioni di messaggi di piccole dimensioni in una sottoscrizione StreamingPull
Lo stack gRPC StreamingPull è ottimizzato per una velocità effettiva elevata e quindi memorizza nel buffer i messaggi. Se stai tentando di elaborare arretrati di grandi dimensioni di messaggi di piccole dimensioni, potresti vedere che i messaggi sono recapitati più volte. Il bilanciamento del carico di questi messaggi potrebbe non essere efficace tra i client.
Il buffer tra il servizio Pub/Sub e lo spazio utente della libreria client è di circa 10 MB. Per comprendere l'effetto di questo buffer sul comportamento della libreria client, considera questo esempio:
In una sottoscrizione è presente un backlog di 10.000 messaggi da 1 kB.
Ogni messaggio impiega un secondo per l'elaborazione sequenziale da parte di un'istanza client a thread singolo.
La prima istanza client che stabilisce una connessione StreamingPull al servizio per quella sottoscrizione riempie il buffer con tutti i 10.000 messaggi.
L'elaborazione del buffer richiede 10.000 secondi (quasi tre ore).
Durante questo intervallo di tempo, alcuni messaggi nel buffer superano le scadenze di conferma e vengono inviati di nuovo allo stesso client, generando duplicati.
Quando sono in esecuzione più istanze client, i messaggi bloccati nel buffer di un client non sono disponibili per le altre istanze client. Questa situazione non si verifica se utilizzi il controllo del flusso per StreamingPull. Il servizio non include mai tutti i 10 MB di messaggi alla volta ed è in grado di bilanciare in modo efficace il carico dei messaggi tra più sottoscrittori.