Best Practices für die Veröffentlichung in einem Pub/Sub-Thema

Bei der Veröffentlichung sendet ein Publisher-Client eine Nachricht an ein Pub/Sub-Thema. Hier sind einige Best Practices für das Veröffentlichen von Nachrichten in Pub/Sub.

In diesem Dokument wird davon ausgegangen, dass Sie bereits mit dem Veröffentlichen von Nachrichten in einem Pub/Sub-Thema vertraut sind.

Wenn Sie Pub/Sub noch nicht kennen, lesen Sie eine der Kurzanleitungen und erfahren Sie, wie Sie Pub/Sub über die Konsole, die gcloud CLI oder die Clientbibliotheken ausführen.

Auf die Antwort der Veröffentlichung reagieren

Wenn der Veröffentlichungsaufruf der Clientbibliothek auf hoher Ebene abgeschlossen ist, wird ein Future-Objekt zurückgegeben, das das Ergebnis des Vorgangs enthält. Um das Blockieren einzelner Veröffentlichungsanfragen zu vermeiden, sollten Sie das Ergebnis asynchron verarbeiten. Sie sollten entscheiden, wie Sie den Fehler für Ihren Anwendungsfall am besten handhaben. Folgende Optionen sind möglich:

  • Protokollieren Sie den Fehler und unternehmen Sie nichts weiter, wenn für Ihren Anwendungsfall nicht alle Nachrichten erfolgreich veröffentlicht werden müssen.
  • Versuchen Sie, die Veröffentlichung noch einmal durchzuführen, wenn es sich um einen möglicherweise vorübergehenden Fehler wie einen Deadline exceeded-Fehler handelt.
  • Speichern Sie die Nachricht in einer Datei oder einem Speicher, um die Veröffentlichung später noch einmal zu versuchen, insbesondere bei einem Fehler, der eine Nutzeraktion erfordert, z. B. Not found oder Permission denied.
  • Leiten Sie die Fehler an den Upstream-Dienst weiter, der Ihnen die Nachricht gesendet hat, die Sie veröffentlichen wollten.

Wenn Sie der Meinung sind, dass Pub/Sub Nachrichten nicht wie erwartet an Ihre Abonnenten sendet, prüfen Sie, ob Sie die Ergebnisse von Veröffentlichungen erfassen und ob die Veröffentlichungen erfolgreich waren.

Abo anhängen oder Themenaufbewahrung aktivieren, bevor Sie mit der Veröffentlichung beginnen

Wenn Sie mit der Veröffentlichung in einem Thema beginnen, dem kein Abonnent angehängt ist, werden die Nachrichten nicht beibehalten. Diese Nachrichten können nicht an später angehängte Abos zugestellt werden. Bevor Sie mit dem Veröffentlichen von Nachrichten beginnen, müssen Sie daher einen der folgenden Schritte ausführen:

Batch-Messaging konfigurieren

Beim Batch-Messaging in Pub/Sub werden mehrere Nachrichten in einem Batch zusammengefasst, der in einer einzelnen Veröffentlichungsanfrage veröffentlicht wird. Wenn Sie Clientbibliotheken zum Veröffentlichen Ihrer Nachrichten verwenden, ist das Batching standardmäßig aktiviert. Durch das Batching (oder Gruppieren) von Nachrichten kann der Publisher die Effizienz steigern und Nachrichten mit einem höheren Durchsatz senden. Durch das Batching werden die Kosten für die Veröffentlichung von Daten gesenkt. Die Stapelverarbeitung führt jedoch auch zu einer Latenz für einzelne Nachrichten, da der Publisher wartet, bis der Stapel gefüllt ist, bevor er ihn veröffentlicht.

Die Latenz in Pub/Sub kann zwei Arten haben:

  • Die Ende-zu-Ende-Latenz ist die Zeit, die benötigt wird, bis eine Nachricht von einem Publisher veröffentlicht und an die entsprechenden Abonnenten zur Verarbeitung gesendet wird.

  • Die Veröffentlichungslatenz ist die Zeit, die zum Veröffentlichen einer Nachricht benötigt wird.

Wenn Sie die Batchverarbeitung verwenden, ist die Erhöhung beider Arten von Latenzen ein Kompromiss, um Effizienz und Durchsatz zu verbessern.

Sie können Nachrichten in einer Clientbibliothek anhand der Größe der Nachrichtenanfrage, der Anzahl der Nachrichten und des Zeitpunkts in Batches zusammenfassen. Wenn Sie Batch-Einstellungen konfigurieren, können Sie das richtige Verhältnis zwischen Kosten, Durchsatz und Latenz für Ihren Anwendungsfall finden.

Die Standardwerte für die Variablen für Batch-Messaging und die Namen der Variablen können sich je nach Clientbibliothek unterscheiden. Sie können einen, zwei oder alle drei Werte in der Clientbibliothek angeben. Wenn einer der Werte für die Variablen für Batch-Messaging erreicht wird, veröffentlicht die Clientbibliothek den nächsten Batch von Nachrichten.

Informationen zum Konfigurieren von Batch-Messaging für einen Publisher-Client finden Sie unter Batch-Nachrichten in einer Veröffentlichungsanfrage.

Ablaufsteuerung für vorübergehende Nachrichtenspitzen konfigurieren

Wenn der Publisher-Client eine große Anzahl von Nachrichten verarbeiten muss, können sich Veröffentlichungsanfragen im Speicher ansammeln, bis die Nachrichten mit dem Fehler Deadline exceeded nicht mehr veröffentlicht werden können.

Um vorübergehende Spitzen bei der Veröffentlichung von Nachrichten zu bewältigen, können Sie die Ablaufsteuerung in den Publisher-Einstellungen verwenden. Die Flusssteuerung auf Publisherseite verhindert, dass die Clientressourcen des Publishers durch zu viele ausstehende Anfragen überlastet werden. Wenn der Publisher-Client in Bezug auf Arbeitsspeicher, CPU oder Threads eingeschränkt ist, wird eine große Anzahl von Deadline exceeded-Fehlern generiert.

Wenn Sie die Ablaufsteuerung in der Clientbibliothek konfigurieren möchten, legen Sie entsprechende Werte für die Variablen maximum outstanding messages (maximale Anzahl ausstehender Nachrichten) und maximum outstanding message bytes (maximale Anzahl ausstehender Nachrichtenbytes) fest. Diese Werte gleichen den Nachrichtendurchsatz und die Systemkapazität aus.

Informationen dazu, ob Ihre Clientbibliothek die Ablaufsteuerung für Publisher unterstützt und wie Sie sie konfigurieren, finden Sie unter Ablaufsteuerung.

Netzwerkbandbreite und ‑latenz verstehen

Der Durchsatz Ihres Publishers wird durch Ihre Netzwerkbandbreite und die Anzahl der gesendeten Anfragen begrenzt. Wenn Ihre Bandbreite gut, aber Ihre Netzwerklatenz hoch ist, sollten Sie das System nicht mit vielen kleinen Anfragen überlasten. Die flusskontrolle auf Publisher-Seite kann bei clientseitigen Netzwerkproblemen helfen.

Der Durchsatz des Publishers ist auch an CPU und Arbeitsspeicher gebunden. Mit mehr verfügbaren Maschinenkernen können Sie eine höhere Anzahl von Threads für einen besseren Veröffentlichungsdurchsatz festlegen. Weitere Informationen dazu, wie Sie die Streaming-Leistung maximieren können, finden Sie unter Cloud Pub/Sub-Clients testen, um die Streaming-Leistung zu maximieren.

Variablen für Wiederholungsanfragen für fehlgeschlagene Veröffentlichungen anpassen

Wenn eine Nachricht von einem Publisher-Client veröffentlicht wird, können Veröffentlichungsfehler auftreten. Diese Fehler werden in der Regel durch clientseitige Engpässe verursacht, z. B. unzureichende Dienst-CPUs, eine schlechte Threadintegrität oder Netzwerküberlastung. Die publisher retry policy bestimmt das Verhalten im Falle eines Fehlers bei der Nachrichtenzustellung. Die Wiederholungsrichtlinie definiert, wie oft Pub/Sub versucht, die Nachricht zuzustellen, und wie viel Zeit zwischen den einzelnen Versuchen vergeht.

In der Java-Clientbibliothek für Pub/Sub enthält der Publisher-Client beispielsweise die folgenden Werte:

  • initialRetryDelay Die anfängliche Verzögerung, die der Publisher abwartet, bevor er einen Veröffentlichungsvorgang wiederholt. Der Standardwert ist 100 milliseconds.

  • retryDelayMultiplier: Der Multiplikationsfaktor, der zum Berechnen der Verzögerung zwischen Neuversuchen verwendet wird. Der Standardwert ist 4. Das bedeutet, dass die Verzögerung zwischen den Wiederholungsversuchen beim zweiten Wiederholungsversuch bis zu 100 milliseconds * 4 = 400 milliseconds und beim dritten Wiederholungsversuch bis zu 400 milliseconds * 4 = 1600 milliseconds betragen kann.

  • maxRetryDelay: Die maximale Verzögerung, die der Publisher vor dem Wiederholen eines Veröffentlichungsvorgangs abwartet. Der Standardwert ist 60 seconds.

  • initialRpcTimeout Das anfängliche Zeitlimit, das der Publisher abwartet, bis der RPC-Aufruf abgeschlossen ist. Der Standardwert ist 5 seconds.

  • rpcTimeoutMultiplier Der Multiplikationsfaktor, der zum Berechnen des RPC-Timeouts verwendet wird. Der Standardwert ist 4.0. Das bedeutet, dass das Zeitlimit für den RPC-Aufruf beim zweiten Wiederholungsversuch bis zu 5 seconds * 4 = 20 seconds und beim dritten Wiederholungsversuch bis zu 10 seconds * 4 = 40 seconds beträgt.

  • maxRpcTimeout Das maximale Zeitlimit, das der Publisher für den Abschluss des RPC-Aufrufs abwartet. Der Standardwert ist 600 seconds.

  • totalTimeout Die Gesamtzeitüberschreitung für den Veröffentlichungsvorgang. Dazu gehören die Wartezeit auf den Abschluss des RPC-Aufrufs und die Wartezeit zwischen den Wiederholungsversuchen. Der Standardwert ist 600 seconds.

Nehmen Sie nur dann Anpassungen an den angegebenen Werten vor, wenn die Standardeinstellungen für Wiederholungsversuche für Ihren Anwendungsfall nicht ausreichen. Wenn Sie beispielsweise eine große Anzahl von Nachrichten veröffentlichen, müssen Sie die Werte für initialRetryDelay und maxRetryDelay nicht erhöhen. Sie können jedoch die Flusssteuerung und das Batching in solchen Fällen anpassen. Wenn Sie über eine instabile oder bandbreitenbeschränkte Internetverbindung veröffentlichen, können Sie mit den Werten für die Variablen initialRpcTimeout, maxRpcTimeout und rpcTimeoutMultiplier experimentieren. Empfohlene Werte finden Sie unter Publish-Vorgänge schlagen mit DEADLINE_EXCEEDED fehl.

Mit Richtlinien für den Nachrichtenspeicher die Datenlokalität sicherstellen

Die Richtlinie für den Nachrichtenspeicher von Pub/Sub-Themen bietet eine Möglichkeit, dafür zu sorgen, dass Nachrichten, die für ein Thema veröffentlicht werden, niemals außerhalb einer von Ihnen angegebenen Gruppe vonGoogle Cloud Regionen gespeichert werden, unabhängig davon, wo die Veröffentlichungsanfragen ihren Ursprung haben.

Mit der Richtlinie für die Nachrichtenspeicherung können Sie eine Liste von Google Cloud Regionen angeben, in denen Pub/Sub Nachrichtendaten auf der Festplatte speichern darf. Wenn eine Nachricht in einer Region veröffentlicht wird, die nicht in dieser Liste enthalten ist, wird die Anfrage zur Verarbeitung an die nächstgelegene zulässige Region weitergeleitet. Die Richtlinie kann für ein Thema oder als Organisationsrichtlinie für ein Projekt, einen Projektordner oder eine gesamte Organisation konfiguriert werden. Wenn eine Organisationsrichtlinie konfiguriert ist, kann die Richtlinie für einzelne Themen nur so geändert werden, dass die Organisationsrichtlinie nicht verletzt wird.

Ein Unternehmen, das in Europa tätig ist, kann beispielsweise die Richtlinie zur Nachrichtenspeicherung verwenden, um sicherzustellen, dass alle Daten in EU-Regionen gespeichert werden, um den lokalen Gesetzen zu entsprechen.

Weitere Informationen finden Sie unter Richtlinien für die Nachrichtenspeicherung konfigurieren.

Best Practices für die geordnete Nachrichtenübermittlung bei der Veröffentlichung

Wenn Sie die Nachrichtenreihenfolge verwenden, achten Sie auf Folgendes:

  • Standortendpunkte verwenden: Die Reihenfolge der Nachrichten wird auf der Veröffentlichungsseite und innerhalb einer Region beibehalten. Wenn Sie Nachrichten in mehreren Regionen veröffentlichen, werden nur Nachrichten innerhalb derselben Region in einer konsistenten Reihenfolge zugestellt. Wenn Ihre Nachrichten alle in derselben Region veröffentlicht werden, Ihre Abonnenten jedoch auf verschiedene Regionen verteilt sind, erhalten die Abonnenten alle Nachrichten in der richtigen Reihenfolge. Verwenden Sie einen Standortendpunkt, um Nachrichten in derselben Region zu veröffentlichen.

  • Funktion zum Fortsetzen der Veröffentlichung konfigurieren Wenn eine Clientbibliothek eine Anfrage wiederholt und die Nachricht einen Reihenfolgeschlüssel hat, wiederholt die Clientbibliothek die Anfrage unabhängig von den Wiederholungseinstellungen wiederholt. Wenn ein nicht wiederholbarer Fehler auftritt, veröffentlicht die Clientbibliothek die Nachricht nicht und veröffentlicht keine weiteren Nachrichten mit demselben Reihenfolgeschlüssel. Wenn Sie die Veröffentlichung mit einem Sortierungsschlüssel fortsetzen möchten, bei dem ein Fehler aufgetreten ist, rufen Sie die Methode resumePublish auf.

Zusammenfassung der Best Practices

In der folgenden Tabelle sind die Best Practices zusammengefasst, die in diesem Dokument empfohlen werden:

Thema Aufgabe
Nachrichtenspeicherung konfigurieren Hängen Sie ein Abo an, bevor Sie die Nachrichtenaufbewahrung veröffentlichen oder aktivieren.
Nachrichten in einer Veröffentlichungsanfrage in Batches zusammenfassen Fassen Sie Nachrichten in Batches oder Gruppen zusammen, um die Effizienz des Publishers zu steigern und Nachrichten mit einem höheren Durchsatz zu senden.
Ablaufsteuerung Konfigurieren Sie die Ablaufsteuerung in den Publisher-Einstellungen, um vorübergehende Trafficspitzen zu bewältigen.
Pub/Sub-Clients testen, um die Streamingleistung zu maximieren Den Publisher-Durchsatz durch Erhöhung der verfügbaren Maschinenkerne und der Netzwerkbandbreite steigern.
Anfragen noch einmal senden Passen Sie die angegebenen Werte der Richtlinie für Wiederholungsversuche des Publishers nur an, wenn die Standardeinstellungen für Ihren Anwendungsfall nicht ausreichen.
Richtlinien für den Nachrichtenspeicher konfigurieren Mit der Nachrichtenspeicherrichtlinie können Sie festlegen, dass Nachrichtendaten nur an bestimmten Orten auf der Festplatte gespeichert werden.
Standortendpunkt verwenden, wenn Sortierschlüssel beim Veröffentlichen verwendet werden Wenn Sie die geordnete Nachrichtenübermittlung verwenden, nutzen Sie einen Standortendpunkt und konfigurieren Sie eine Funktion zum Fortsetzen der Veröffentlichung für Veröffentlichungsfehler.

Nächste Schritte