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 zum Veröffentlichen von Nachrichten in Pub/Sub.

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

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

Maßnahmen basierend auf der Antwort der Veröffentlichung

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, verarbeiten Sie das Ergebnis asynchron. Sie sollten entscheiden, wie Sie den Fehler am besten für Ihren Anwendungsfall behandeln. 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).
  • Wiederholen Sie die Veröffentlichung bei einem potenziell vorübergehenden Fehler wie einem Deadline exceeded-Fehler.
  • Speichern Sie die Nachricht in einer Datei oder im Speicher, um die Veröffentlichung später zu wiederholen, 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 der Veröffentlichungen verfolgen 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 aufbewahrt. Diese Nachrichten können nicht an später angehängte Abos gesendet werden. Bevor Sie mit dem Veröffentlichen von Nachrichten beginnen, haben Sie folgende Möglichkeiten:

Batch-Messaging konfigurieren

In Pub/Sub bezieht sich Batch-Messaging auf den Prozess, bei dem mehrere Nachrichten zu einem Batch kombiniert werden, der in einer einzigen Veröffentlichungsanfrage veröffentlicht wird. Wenn Sie Clientbibliotheken zum Veröffentlichen Ihrer Nachrichten verwenden, ist die Batchverarbeitung standardmäßig aktiviert. Durch die Batchverarbeitung (oder Gruppierung) von Nachrichten kann der Publisher seine Effizienz verbessern und Nachrichten mit einem höheren Durchsatz senden. Die Batchverarbeitung reduziert die Kosten für die Veröffentlichung von Daten. Die Batchverarbeitung führt jedoch auch zu einer Latenz für einzelne Nachrichten, da der Publisher wartet, bis der Batch gefüllt ist, bevor er ihn veröffentlicht.

In Pub/Sub kann es zwei Arten von Latenz geben:

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

  • Die Veröffentlichungslatenz ist die Zeit, die für die Veröffentlichung einer Nachricht benötigt wird.

Bei der Batchverarbeitung ist die Erhöhung beider Arten von Latenz ein Kompromiss, um die Effizienz und den Durchsatz zu verbessern.

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

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

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

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 Veröffentlichung von Nachrichten mit dem Fehler Deadline exceeded fehlschlägt.

Um vorübergehende Spitzen bei der Veröffentlichung von Nachrichten zu vermeiden, können Sie die Ablaufsteuerung in den Publisher-Einstellungen verwenden. Die abonnentenseitige Ablaufsteuerung verhindert, dass die Ressourcen des Publisher-Clients durch zu viele ausstehende Anfragen überlastet werden. Wenn der Publisher-Client in Bezug auf Speicher, CPU oder Threads eingeschränkt ist, werden viele Deadline exceeded-Fehler generiert.

Um die Ablaufsteuerung in der Clientbibliothek zu konfigurieren, legen Sie geeignete Werte für die Variablen Maximale Anzahl ausstehender Nachrichten und 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 abonnentenseitige Ablaufsteuerung kann bei netzwerkseitigen Problemen helfen.

Der Durchsatz Ihres Publishers ist auch durch CPU und Speicher begrenzt. Mit mehr verfügbaren Maschinenkernen können Sie eine höhere Anzahl von Threads für einen besseren Veröffentlichungsdurchsatz festlegen. Weitere Informationen zum Maximieren der Streamingleistung finden Sie unter Cloud Pub/Sub-Clients testen, um die Streamingleistung 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 bei einem Fehler bei der Zustellung von Nachrichten. Die Wiederholungsrichtlinie definiert, wie oft Pub/Sub versucht, die Nachricht zuzustellen, und die Zeitspanne zwischen den einzelnen Versuchen.

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 vor dem Wiederholen eines Veröffentlichungsvorgangs wartet. Der Standardwert ist 100 milliseconds.

  • retryDelayMultiplier. Der Multiplikationsfaktor, mit dem die Verzögerung zwischen den Wiederholungen berechnet wird. Der Standardwert ist 4. Das bedeutet, dass die Verzögerung zwischen den Wiederholungen für den zweiten Versuch bis zu 100 milliseconds * 4 = 400 milliseconds und für den dritten Versuch bis zu 400 milliseconds * 4 = 1600 milliseconds beträgt.

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

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

  • rpcTimeoutMultiplier. Der Multiplikationsfaktor, mit dem das RPC-Zeitlimit berechnet wird. Der Standardwert ist 4.0. Das bedeutet, dass das Zeitlimit für den RPC-Aufruf für den zweiten Versuch bis zu 5 seconds * 4 = 20 seconds und für den dritten Versuch bis zu 10 seconds * 4 = 40 seconds beträgt.

  • maxRpcTimeout. Das maximale Zeitlimit, das der Publisher wartet, bis der RPC-Aufruf abgeschlossen ist. Der Standardwert ist 600 seconds.

  • totalTimeout. Das Gesamtzeitlimit für den Veröffentlichungsvorgang. Dazu gehören die Wartezeit, bis der RPC-Aufruf abgeschlossen ist, und die Wartezeit zwischen den Wiederholungen. Der Standardwert ist 600 seconds.

Nehmen Sie nur dann Anpassungen an den angegebenen Werten vor, wenn die Standardeinstellungen für die Wiederholung für Ihren Anwendungsfall nicht ausreichen. Wenn Sie beispielsweise eine große Anzahl von Nachrichten veröffentlichen, müssen Sie die Werte initialRetryDelay und maxRetryDelay nicht erhöhen. Unter solchen Umständen können Sie jedoch die Ablaufsteuerung und die Batchverarbeitung anpassen. Wenn Sie über eine instabile Internetverbindung oder eine Verbindung mit begrenzter Bandbreite veröffentlichen, können Sie mit den Werten für die Variablen initialRpcTimeout, maxRpcTimeout und rpcTimeoutMultiplier experimentieren. Empfohlene Werte finden Sie unter Veröffentlichungsvorgänge schlagen mit DEADLINE_EXCEEDED fehl.

Nachrichtenspeicherrichtlinie verwenden, um die Datenlokalität sicherzustellen

Die Pub/Sub-Thema Nachrichtenspeicherrichtlinie bietet eine Möglichkeit, zu gewährleisten dass Nachrichten, die zu einem Thema veröffentlicht werden, niemals außerhalb einer von Ihnen angegebenen Google Cloud Region gespeichert werden, unabhängig davon, wo die Veröffentlichungsanfragen ihren Ursprung haben.

Verwenden Sie die Nachrichtenspeicherrichtlinie, um eine Liste von Google Cloud Regionen anzugeben, in denen Pub/Sub Nachrichtendaten auf dem Laufwerk 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 sie nicht gegen die Organisationsrichtlinie verstößt.

Ein Unternehmen, das in Europa tätig ist, kann beispielsweise die Nachrichtenspeicherrichtlinie verwenden, um sicherzustellen, dass alle Daten in EU-Regionen gespeichert werden, um die lokalen Gesetze einzuhalten.

Weitere Informationen finden Sie unter Richtlinien für den Nachrichtenspeicher konfigurieren.

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

Wenn Sie die Nachrichtenreihenfolge verwenden, beachten Sie Folgendes:

  • Standortendpunkte verwenden. Die Reihenfolge der Nachrichten bleibt auf der Veröffentlichungsseite und innerhalb einer Region erhalten. Wenn Sie Nachrichten in mehreren Regionen veröffentlichen, werden also nur Nachrichten innerhalb derselben Region in einer konsistenten Reihenfolge gesendet. Wenn alle Ihre Nachrichten in derselben Region veröffentlicht werden, Ihre Abonnenten sich aber in verschiedenen Regionen befinden, 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 Reihenfolgeschlüssel fortsetzen möchten, bei dem die Veröffentlichung fehlgeschlagen ist, rufen Sie die resumePublish Methode 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 Nachrichten veröffentlichen, oder aktivieren Sie die Nachrichtenspeicherung
Nachrichten in einer Veröffentlichungsanfrage in Batches zusammenfassen Fassen Sie Nachrichten in Batches zusammen oder gruppieren Sie sie, 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 vermeiden.
Testen von Cloud Pub/Sub-Clients zur Maximierung der Streaming leistung Skalieren Sie den Durchsatz des Publishers mit einer Erhöhung der verfügbaren Maschinen Kerne und der Netzwerkbandbreite.
Anfragen wiederholen Nehmen Sie nur dann Anpassungen an den angegebenen Werten der Wiederholungsrichtlinie des Publishers vor, wenn die Standardeinstellungen für Ihren Anwendungsfall nicht ausreichen.
Richtlinien für den Nachrichtenspeicher konfigurieren Verwenden Sie die Nachrichtenspeicherrichtlinie, um Nachrichtendaten nur an bestimmten Standorten auf dem Laufwerk zu speichern.
Bei der Verwendung von Sortierschlüsseln bei der Veröffentlichung einen Standortendpunkt verwenden Wenn Sie geordnete Nachrichten verwenden, verwenden Sie einen Standortendpunkt und konfigurieren Sie eine Funktion zum Fortsetzen der Veröffentlichung für Veröffentlichungsfehler.

Nächste Schritte