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

Beim Veröffentlichen sendet ein Publisher-Client eine Nachricht an ein Pub/Sub-Thema. Im Folgenden finden Sie einige Best Practices für das 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 die Kurzanleitungen, um zu erfahren, wie Sie Pub/Sub über die Console, die gcloud CLI oder die Clientbibliotheken ausführen.

Fügen Sie ein Abo hinzu oder aktivieren Sie die Aufbewahrung von Themen, bevor Sie mit der Veröffentlichung beginnen.

Wenn Sie mit der Veröffentlichung von Nachrichten zu einem Thema beginnen, das keinen verknüpften Abonnenten hat, 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, haben Sie folgende Möglichkeiten:

Batch-Mitteilungen konfigurieren

Bei Pub/Sub bezieht sich das Batch-Messaging auf den Vorgang, bei dem mehrere Nachrichten in 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 das Batching (oder Gruppieren) von Nachrichten kann der Publisher seine Effizienz verbessern und Nachrichten mit einem höheren Durchsatz senden. Durch die Batchverarbeitung werden die Kosten für die Veröffentlichung von Daten gesenkt. Die Stapelverarbeitung führt jedoch auch zu einer Latenz bei einzelnen Nachrichten, da der Publisher wartet, bis der Stapel gefüllt ist, bevor er ihn veröffentlicht.

Es gibt zwei Arten von Latenz bei Pub/Sub:

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

  • Die Veröffentlichungslatenz ist die Zeitspanne, die vergeht, bis eine Nachricht veröffentlicht wird.

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

Sie können Nachrichten in einer Clientbibliothek basierend auf der Größe der Nachrichtenanfrage, der Anzahl der Nachrichten und dem Uhrzeitpunkt in Stapeln zusammenfassen. Beim Konfigurieren der Batch-Einstellungen können Sie das richtige Gleichgewicht zwischen Kosten, Durchsatz und Latenz für Ihren Anwendungsfall finden.

Die Standardwerte für die Variablen für die Batch-Messaging-Funktion und die Namen der Variablen können sich je nach Clientbibliothek unterscheiden. Sie können einen oder alle drei Werte in der Clientbibliothek angeben. Wenn einer der Werte für die Variablen für die Batch-Messaging-Funktion erfüllt ist, veröffentlicht die Clientbibliothek die nächste Nachrichtengruppe.

Informationen zum Konfigurieren von Batch-Messaging für einen Publisher-Client findest du 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, sammeln sich Veröffentlichungsanfragen möglicherweise im Speicher an, bis die Nachrichten mit dem Fehler Deadline exceeded nicht veröffentlicht werden können.

Wenn Sie vorübergehende Spitzen bei der Veröffentlichung von Nachrichten beheben möchten, können Sie die Ablaufsteuerung in Ihren Publisher-Einstellungen verwenden. Die publisherseitige Ablaufsteuerung verhindert, dass die Ressourcen des Publisher-Clients durch zu viele ausstehende Anfragen überlastet werden. Wenn der Publisher-Client in Bezug auf Arbeitsspeicher, 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 maximum outstanding messages (maximale Anzahl ausstehender Nachrichten) und maximum outstanding message bytes (maximale Anzahl ausstehender Nachrichten-Bytes) fest. Mit diesen Werten wird der Nachrichtendurchsatz und die Systemkapazität ausgeglichen.

Informationen dazu, ob deine Clientbibliothek die Ablaufsteuerung für Publisher unterstützt und wie du sie konfigurierst, findest du unter Ablaufsteuerung.

Netzwerkbandbreite und Latenz

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

Der Publisher-Durchsatz ist auch von der CPU und dem Arbeitsspeicher abhängig. Je mehr verfügbare Maschinenkerne vorhanden sind, desto höher kann die Anzahl der Threads festgelegt werden, um den Veröffentlichungsdurchsatz zu verbessern. Weitere Informationen dazu, wie Sie die Streamingleistung maximieren, 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, kann es zu Veröffentlichungsfehlern kommen. Diese Fehler werden in der Regel durch clientseitige Engpässe verursacht, z. B. unzureichende Dienst-CPUs, eine schlechte Threadintegrität oder Netzwerküberlastung. Mit publisher retry policy wird das Verhalten bei einem Zustellungsfehler festgelegt. Die Wiederholungsrichtlinie definiert, wie oft Pub/Sub versucht, die Nachricht zuzustellen, und wie lange die Zeit zwischen den einzelnen Versuchen ist.

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 noch einmal versucht. Der Standardwert ist 100 milliseconds.

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

  • maxRetryDelay Die maximale Verzögerung, die der Publisher abwartet, bevor er einen Veröffentlichungsvorgang wiederholt. Der Standardwert ist 60 seconds.

  • initialRpcTimeout Die anfängliche Zeitüberschreitung, die der Publisher wartet, bis der RPC-Aufruf abgeschlossen ist. Der Standardwert ist 5 seconds.

  • rpcTimeoutMultiplier Der Multiplikator, mit dem die RPC-Zeitüberschreitung berechnet 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 Die maximale Zeitüberschreitung, die der Publisher für den Abschluss des RPC-Aufrufs wartet. Der Standardwert ist 600 seconds.

  • totalTimeout Die Gesamtzeitüberschreitung für den Veröffentlichungsvorgang. Dazu gehört die Zeit, die zum Warten auf den Abschluss des RPC-Aufrufs und zwischen den Wiederholungsversuchen vergeht. Der Standardwert ist 600 seconds.

Nehmen Sie nur dann Anpassungen an den angegebenen Werten vor, wenn die Standardeinstellungen für Wiederholungen 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 die Ablaufsteuerung und die Batchverarbeitung in solchen Fällen jedoch anpassen. Wenn du über eine labile Internetverbindung oder eine Verbindung mit begrenzter Bandbreite veröffentlichst, kannst du 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.

Richtlinien für den Nachrichtenspeicher verwenden, um Datenlokalität zu gewährleisten

Die Pub/Sub-Themenspeicherrichtlinie 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.

Mit der Nachrichtenspeicherrichtlinie können Sie eine Liste der Google Cloud-Regionen angeben, in denen Pub/Sub-Nachrichtendaten auf dem Laufwerk gespeichert werden dürfen. 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, können einzelne Themenrichtlinien nur so geändert werden, dass sie nicht gegen die Organisationsrichtlinie verstoßen.

Ein in Europa ansässiges Unternehmen kann beispielsweise die Richtlinie zum Speichern von Nachrichten 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 angeordnete Nachrichten in der Verlagsbranche

Wenn Sie die Nachrichtensortierung verwenden, beachten Sie Folgendes:

  • Verwenden Sie Standortendpunkte. 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 einheitlichen Reihenfolge zugestellt. Wenn Ihre Nachrichten alle in derselben Region veröffentlicht werden, Ihre Abonnenten aber in verschiedenen Regionen sind, erhalten sie alle Nachrichten in der richtigen Reihenfolge. Verwenden Sie einen standortbezogenen Endpunkt, um Nachrichten in derselben Region zu veröffentlichen.

  • Konfiguriere eine Funktion zum Fortsetzen der Veröffentlichung. 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 für einen Sortierungsschlüssel fortsetzen möchten, bei dem die Veröffentlichung fehlgeschlagen 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 eine Nachricht veröffentlichen oder die Nachrichtenaufbewahrung aktivieren.
Nachrichten in einer Veröffentlichungsanfrage gruppieren Nachrichten per Batch oder Gruppe senden, um die Effizienz des Publishers zu erhöhen und Nachrichten mit einem höheren Durchsatz zu senden.
Ablaufsteuerung Konfiguriere die Ablaufsteuerung in deinen Publisher-Einstellungen, um vorübergehende Traffic-Spitzen zu bewältigen.
Pub/Sub-Clients testen, um die Streamingleistung zu maximieren Publisher-Durchsatz durch mehr verfügbare CPU-Kerne und Netzwerkbandbreite skalieren
Anfragen noch einmal senden Passen Sie die angegebenen Werte der Richtlinie für Publisher-Wiederholungen 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 Speicherorten auf dem Laufwerk gespeichert werden.
Standortendpunkt verwenden, wenn bei der Veröffentlichung Sortierschlüssel verwendet werden Wenn Sie geordnete Nachrichten verwenden, verwenden Sie einen Standortendpunkt und konfigurieren Sie eine Funktion zum Fortsetzen der Veröffentlichung bei Fehlern.

Nächste Schritte