Dieses Dokument enthält einige allgemeine Tipps zur Fehlerbehebung für Pub/Sub-StreamingPull-Abos. StreamingPull-Abos verwenden die StreamingPull API.
Weitere Informationen zu StreamingPull-Abos finden Sie im Pull-Abonnentenleitfaden.
StreamingPull hat eine Fehlerrate von 100 %
StreamingPull-Streams werden immer mit einem Fehlerstatus geschlossen. Im Gegensatz zu unären RPCs ist dieser Status für StreamingPull lediglich ein Hinweis darauf, dass der Stream fehlerhaft ist. Die Anfragen schlagen nicht fehl. Obwohl die StreamingPull API eine überraschende Fehlerrate von 100% haben kann, ist dieses Verhalten beabsichtigt.
Fehler „Nicht gefunden“, „Nicht verfügbar“ oder „Nicht gefunden“
Da StreamingPull-Streams immer mit einem Fehler geschlossen werden, ist es nicht hilfreich, die Messwerte zum Beenden von Streams bei der Fehlerdiagnose zu untersuchen. Konzentrieren Sie sich stattdessen auf den Antwortmesswert von StreamingPull, z. B. subscription/streaming_pull_response_count.
Suchen Sie nach diesen Fehlern:
Fehler des Typs Fehlgeschlagene Voraussetzung, die in folgenden Fällen auftreten können:
Pub/Sub versucht, eine Nachricht mit einem deaktivierten Cloud KMS-Schlüssel zu entschlüsseln.
Abos werden vorübergehend gesperrt, wenn sich im Aborückstand Nachrichten befinden, die mit einem deaktivierten Cloud KMS-Schlüssel verschlüsselt sind.
Fehler, die nicht verfügbar sind, die auftreten können, wenn Pub/Sub eine Anfrage nicht verarbeiten kann. Dies ist höchstwahrscheinlich ein vorübergehender Zustand und die Clientbibliothek wiederholt die Anfragen.
Fehler vom Typ „Nicht gefunden“, die auftreten können, wenn das Abo gelöscht wird oder es nie existiert hat. Der letztere Fall tritt auf, wenn Sie einen ungültigen Abopfad angeben.
Großer Rückstand kleiner Nachrichten in einem StreamingPull-Abo
Das gRPC-StreamingPull-Paket ist für einen hohen Durchsatz optimiert, sodass Nachrichten zwischengespeichert werden. Wenn Sie versuchen, große Rückstände kleiner Nachrichten zu verarbeiten, werden Nachrichten möglicherweise mehrmals zugestellt. Diese Nachrichten lassen sich möglicherweise nicht effektiv auf die Clients verteilen.
Der Zwischenspeicher zwischen dem Pub/Sub-Dienst und dem Nutzerbereich der Clientbibliothek beträgt etwa 10 MB. Sehen Sie sich dieses Beispiel an, um die Auswirkungen dieses Zwischenspeichers auf das Verhalten der Clientbibliothek zu verstehen:
Für ein Abo gibt es einen Rückstand von 10.000 1-KB-Nachrichten.
Jede Nachricht benötigt eine Sekunde für die sequenzielle Verarbeitung durch eine Clientinstanz mit einem einzigen Thread.
Die erste Clientinstanz, die eine StreamingPull-Verbindung zum Dienst für dieses Abo herstellt, füllt den Zwischenspeicher mit allen 10.000 Nachrichten.
Es dauert 10.000 Sekunden (fast drei Stunden), um den Zwischenspeicher zu verarbeiten.
In dieser Zeit überschreiten einige gepufferte Nachrichten ihre Bestätigungsfristen und werden noch einmal an denselben Client gesendet, was zu Duplikaten führt.
Wenn mehrere Clientinstanzen ausgeführt werden, sind die im Zwischenspeicher eines Clients hängenden Nachrichten für keine andere Clientinstanz verfügbar. Dies tritt nicht auf, wenn Sie die Ablaufsteuerung für StreamingPull verwenden. Der Dienst hat niemals die gesamten 10 MB an Nachrichten gleichzeitig und kann Nachrichten effektiv über mehrere Abonnenten verteilen.