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, um zu erfahren, wie Sie Pub/Sub mit der Console, der gcloud CLI oder den Clientbibliotheken ausführen.

Maßnahmen basierend auf der Antwort der Veröffentlichung ergreifen

Wenn der Veröffentlichungsaufruf der High-Level-Clientbibliothek 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 für Ihren Anwendungsfall am besten beheben. Folgende Optionen sind möglich:

  • Protokollieren Sie den Fehler und tun Sie nichts weiter (wenn Ihr Anwendungsfall nicht die erfolgreiche Veröffentlichung aller Nachrichten erfordert).
  • Wiederholen Sie die Veröffentlichung bei einem potenziell vorübergehenden Fehler wie einem Deadline exceeded-Fehler.
  • Speichern Sie die Nachricht in einer Datei oder einem Speicher, um sie später noch einmal zu veröffentlichen, insbesondere bei einem Fehler, der ein Eingreifen des Nutzers 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 zustellt, prüfen Sie, ob Sie die Ergebnisse von Veröffentlichungen verfolgen und ob die Veröffentlichungen erfolgreich waren.

Wenn die Veröffentlichung erfolgreich ist, ist das Ergebnis des Veröffentlichungsaufrufs die Nachrichten-ID der veröffentlichten Nachricht.

Nachrichten-IDs beibehalten

Um die Fehlerbehebung zu vereinfachen, sollten Publisher und Abonnenten die Nachrichten-IDs veröffentlichter Nachrichten aufbewahren. Sie können entweder die ID jeder veröffentlichten Nachricht speichern oder das Logging von Nachrichten-IDs nach Bedarf aktivieren. Wenn Sie die Nachrichten-IDs beibehalten, können Sie Probleme mit doppelten Nachrichten, erneuten Zustellungen, Datenverlust und andere häufige Probleme leichter beheben. Weitere Informationen finden Sie unter Umgang mit Duplikaten.

Hängen Sie ein Abo an oder aktivieren Sie die Aufbewahrung von Themen, bevor Sie mit der Veröffentlichung beginnen.

Wenn Sie mit der Veröffentlichung in einem Thema beginnen, das keinen angehängten Abonnenten hat, werden die Nachrichten nicht aufbewahrt. Diese Nachrichten können nicht an nachträglich angehängte Abos zugestellt werden. Führen Sie daher einen der folgenden Schritte aus, bevor Sie mit dem Veröffentlichen von Nachrichten beginnen:

Batch-Messaging konfigurieren

In Pub/Sub bezieht sich Batch-Messaging auf den Prozess, bei dem mehrere Nachrichten in einem Batch zusammengefasst 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. Das Batching (oder Gruppieren) von Nachrichten hilft dem Publisher, die Effizienz zu verbessern und Nachrichten mit einem höheren Durchsatz zu senden. Durch die Batchverarbeitung werden die Kosten für die Veröffentlichung von Daten reduziert. Das Batching 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.

Es gibt zwei Arten von Latenz in Pub/Sub:

  • Die End-to-End-Latenz ist die Zeit, die ein Publisher benötigt, um eine Nachricht zu veröffentlichen und an die entsprechenden Abonnenten zur Verarbeitung zu senden.

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

Wenn Sie Batching verwenden, ist die Erhöhung beider Latenztypen ein Kompromiss, um die Effizienz und den Durchsatz zu verbessern.

Sie können Nachrichten in einer Clientbibliothek nach Größe der Nachrichtenanfrage, Anzahl der Nachrichten und Zeit bündeln. Bei der Konfiguration der Batcheinstellungen können Sie die richtige Balance 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 oder alle drei Werte in der Clientbibliothek angeben. Wenn einer der Werte für die Batch-Messaging-Variablen erfüllt 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 Batch-Nachrichten in einer Veröffentlichungsanfrage.

Flusssteuerung für vorübergehende Nachrichtenspitzen konfigurieren

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

Um vorübergehende Spitzen beim Veröffentlichen von Nachrichten zu bewältigen, können Sie die Ablaufsteuerung in Ihren Publisher-Einstellungen verwenden. Die Flusssteuerung auf Publisher-Seite 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 Flusssteuerung in der Clientbibliothek konfigurieren möchten, legen Sie entsprechende Werte für die Variablen Maximale Anzahl ausstehender Nachrichten und Maximale Anzahl ausstehender Nachrichtenbytes fest. Diese Werte sorgen für ein ausgewogenes Verhältnis zwischen Nachrichtendurchsatz und Systemkapazität.

Informationen dazu, ob Ihre Clientbibliothek die Publisher-Flusssteuerung unterstützt, und wie Sie sie konfigurieren, finden Sie unter Flusssteuerung.

Bandbreite und Latenz Ihres Netzwerks ermitteln

Der Publisher-Durchsatz wird durch die Netzwerkbandbreite und die Anzahl der gesendeten Anfragen eingeschränkt. Wenn Ihre Bandbreite gut ist, aber die Netzwerklatenz hoch, sollten Sie das System nicht mit vielen kleinen Anfragen überlasten. Die publisherseitige Flusssteuerung kann bei clientseitigen Netzwerkproblemen helfen.

Der Publisher-Durchsatz ist auch CPU- und arbeitsspeichergebunden. Wenn mehr Maschinenkerne verfügbar sind, können Sie eine höhere Threadanzahl für einen besseren Veröffentlichungsdurchsatz festlegen. Weitere Informationen zur Maximierung der Streaming-Leistung 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, kann es zu Veröffentlichungsfehlern kommen. Diese Fehler werden in der Regel durch clientseitige Engpässe verursacht, z. B. unzureichende Dienst-CPUs, schlechter Thread-Zustand oder Netzwerküberlastung. publisher retry policy bestimmt das Verhalten im Falle eines Fehlers bei der Nachrichtenzustellung. In der Wiederholungsrichtlinie wird festgelegt, 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 wartet, bevor er einen Veröffentlichungsvorgang wiederholt. Der Standardwert ist 100 milliseconds.

  • retryDelayMultiplier. Der Multiplikationsfaktor, der zur Berechnung der Verzögerung zwischen Wiederholungsversuchen 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 beträgt.

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

  • initialRpcTimeout. Das anfängliche Zeitlimit, das der Publisher auf den Abschluss des RPC-Aufrufs wartet. Der Standardwert ist 5 seconds.

  • rpcTimeoutMultiplier. Der Multiplikationsfaktor, der zur Berechnung des RPC-Zeitlimits 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 auf den Abschluss des RPC-Aufrufs wartet. Der Standardwert ist 600 seconds.

  • totalTimeout. Das Gesamtzeitlimit für den Veröffentlichungsvorgang. Dazu gehört die Zeit, die auf den Abschluss des RPC-Aufrufs gewartet wird, und die Zeit, die zwischen Wiederholungsversuchen gewartet wird. 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 unter solchen Umständen 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.

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

Mit der Pub/Sub-Richtlinie für den Nachrichtenspeicher eines Themas können Sie dafür sorgen, dass Nachrichten, die in einem Thema veröffentlicht werden, nie außerhalb einer von Ihnen angegebenen Gruppe vonCloud de Confiance by S3NS -Regionen gespeichert werden, unabhängig davon, woher die Veröffentlichungsanfragen stammen.

Verwenden Sie die Richtlinie für die Nachrichtenspeicherung, um eine Liste von Cloud de Confiance 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, können einzelne Themenrichtlinien nur so geändert werden, dass sie nicht gegen die Organisationsrichtlinie verstoßen.

Ein in Europa tätiges Unternehmen kann beispielsweise die Richtlinie zur Nachrichtenspeicherung verwenden, um sicherzustellen, dass alle Daten in EU-Regionen gespeichert werden, um die lokalen Gesetze einzuhalten.

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

Best Practices für die geordnete Nachrichtenübermittlung beim Veröffentlichen

Wenn Sie die Nachrichtenreihenfolge verwenden, achten Sie auf Folgendes:

  • Standortendpunkte verwenden Die Reihenfolge der Nachrichten bleibt auf der Veröffentlichungsseite und innerhalb einer Region erhalten. Wenn Sie also Nachrichten in mehreren Regionen veröffentlichen, werden nur Nachrichten innerhalb derselben Region in einer konsistenten Reihenfolge zugestellt. Wenn alle Ihre Nachrichten in derselben Region veröffentlicht werden, Ihre Abonnenten aber über mehrere 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 Sortierschlüssel hat, wiederholt die Clientbibliothek die Anfrage unabhängig von den Wiederholungseinstellungen. Wenn ein nicht wiederholbarer Fehler auftritt, veröffentlicht die Clientbibliothek die Nachricht nicht und beendet die Veröffentlichung anderer Nachrichten mit demselben Reihenfolgeschlüssel. Wenn Sie bereit sind, die Veröffentlichung mit einem Bestellschlüssel fortzusetzen, bei dem die Veröffentlichung fehlgeschlagen ist, rufen Sie die Methode resumePublish auf.

Zusammenfassung der Best Practices

In der folgenden Tabelle sind die in diesem Dokument empfohlenen Best Practices zusammengefasst:

Thema Aufgabe
Nachrichtenspeicherung konfigurieren Hängen Sie ein Abo an, bevor Sie die Nachrichtenaufbewahrung veröffentlichen oder aktivieren.
Nachrichten in einer Veröffentlichungsanfrage im Batch verarbeiten Nachrichten im Batch oder in Gruppen senden, um die Effizienz des Publishers zu erhöhen und Nachrichten mit einem höheren Durchsatz zu senden.
Ablaufsteuerung Konfigurieren Sie die Ablaufsteuerung in Ihren Publisher-Einstellungen, um vorübergehende Trafficspitzen zu bewältigen.
Pub/Sub-Clients testen, um die Streaming-Leistung zu maximieren Skalieren Sie den Publisher-Durchsatz, indem Sie die Anzahl der verfügbaren Maschinenkerne und die Netzwerkbandbreite erhöhen.
Anfragen wiederholen Nehmen Sie nur dann Anpassungen an den angegebenen Werten der Wiederholungsrichtlinie für Publisher vor, wenn die Standardeinstellungen für Ihren Anwendungsfall nicht ausreichen.
Richtlinien für die Speicherung von Nachrichten konfigurieren Verwenden Sie die Richtlinie für den Nachrichtenspeicher, um Nachrichtendaten nur an bestimmten Standorten auf dem Laufwerk zu speichern.
Standortendpunkt verwenden, wenn Sortierschlüssel beim Veröffentlichen verwendet werden 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