Best Practices zum Veröffentlichen in einem Pub/Sub-Thema

Bei der Veröffentlichung 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 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 mit der Console, der gcloud CLI oder den Clientbibliotheken ausführen.

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 zu einem Thema beginnen, dem kein Abonnenten zugeordnet ist, werden die Nachrichten nicht aufbewahrt. Diese Nachrichten können nicht an später angehängte Abos zugestellt werden. Bevor Sie also Nachrichten veröffentlichen, führen Sie einen der folgenden Schritte aus:

Batchnachrichten konfigurieren

In Pub/Sub bezieht sich Batch-Messaging auf das Kombinieren mehrerer Nachrichten zu einem Batch, der in einer einzelnen Veröffentlichungsanfrage veröffentlicht wird. Wenn Sie Clientbibliotheken zum Veröffentlichen Ihrer Nachrichten verwenden, ist die Batchverarbeitung standardmäßig aktiviert. Durch das Stapeln (oder Gruppieren) von Nachrichten kann der Verlag oder Webpublisher seine Effizienz verbessern und Nachrichten mit einem höheren Durchsatz senden. Batching reduziert die Kosten für die Veröffentlichung von Daten. Die Batchverarbeitung führt jedoch auch zu Latenz für einzelne Nachrichten, da der Publisher darauf wartet, dass der Batch voll ist, bevor er veröffentlicht wird.

Es gibt zwei Arten von Latenzen in Pub/Sub:

  • 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 Verwendung von Batchverarbeitung stellt die Erhöhung beider Latenzen ein Kompromiss für Effizienz und Durchsatz dar.

Sie können Nachrichten in einer Clientbibliothek basierend auf der Größe der Nachrichtenanfrage, der Anzahl der Nachrichten und der Zeit zusammenfassen. Beim Konfigurieren von Batcheinstellungen können Sie das richtige Gleichgewicht zwischen Kosten, Durchsatz und Latenz für Ihren Anwendungsfall finden.

Die Standardwerte für die Variablen für Batchnachrichten 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 des Batch-Messaging erfüllt ist, veröffentlicht die Clientbibliothek den nächsten Batch von Nachrichten.

Informationen zum Konfigurieren von Batchnachrichten für einen Publisher-Client findest du unter Batchnachrichten 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 Arbeitsspeicher an, bis die Veröffentlichung der Nachrichten mit dem Fehler Deadline exceeded fehlschlägt.

Mit der Ablaufsteuerung in den Publisher-Einstellungen lassen sich vorübergehende Spitzen beim Veröffentlichen von Nachrichten umgehen. Die Ablaufsteuerung auf Publisher-Seite verhindert, dass die Ressourcen des Publisher-Client durch zu viele ausstehende Anfragen überlastet werden. Wenn der Publisher-Client in Bezug auf den Arbeitsspeicher, die CPU oder die Threads eingeschränkt wird, wird eine große Anzahl von Deadline exceeded-Fehlern generiert.

Legen Sie zum Konfigurieren der Ablaufsteuerung in der Clientbibliothek die entsprechenden Werte für die Variablen Maximale Anzahl ausstehender Nachrichten und Maximale Anzahl ausstehender Nachrichtenbyte fest. Diese Werte gleichen den Nachrichtendurchsatz und die Systemkapazität aus.

Unter Ablaufsteuerung erfährst du, wie du prüfen und konfigurieren kannst, ob deine Clientbibliothek die Ablaufsteuerung für Publisher unterstützt.

Informationen zur Netzwerkbandbreite und ‐latenz

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

Der Publisher-Durchsatz ist außerdem CPU- und speichergebunden. Mit mehr verfügbaren Maschinenkernen können Sie eine höhere Thread-Anzahl festlegen, um den Veröffentlichungsdurchsatz zu verbessern. Weitere Informationen zum Maximieren der Streamingleistung finden Sie unter Cloud Pub/Sub-Clients zum Maximieren der Streamingleistung testen.

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

Wenn eine Nachricht von einem Publisher-Client veröffentlicht wird, treten möglicherweise Veröffentlichungsfehler auf. Diese Fehler werden in der Regel durch clientseitige Engpässe verursacht, z. B. unzureichende Dienst-CPUs, ein fehlerhafter Threadstatus oder eine Netzwerküberlastung. publisher retry policy bestimmt das Verhalten bei einem Fehler bei der Nachrichtenzustellung. Die Wiederholungsrichtlinie definiert, wie oft Pub/Sub versucht, die Nachricht zuzustellen, und die Zeitdauer zwischen den einzelnen Versuchen.

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

  • initialRepeatDelay. Die anfängliche Verzögerung, die der Verlag oder Webpublisher wartet, bevor er einen Veröffentlichungsvorgang wiederholt. Der Standardwert ist 100 milliseconds.

  • retryDelayMultiplikator. Der Multiplikationsfaktor, der zum Berechnen der Verzögerung zwischen Wiederholungen verwendet wird. Der Standardwert ist 4. Das bedeutet, dass die Verzögerung zwischen Wiederholungen bis zu 100 milliseconds * 4 = 400 milliseconds für den zweiten Wiederholungsversuch und bis zu 400 milliseconds * 4 = 1600 milliseconds für den dritten Wiederholungsversuch beträgt.

  • maxRepeatDelay. Die maximale Verzögerung, die der Verlag oder Webpublisher 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.

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

  • 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. Dies schließt die Wartezeit für den Abschluss des RPC-Aufrufs und die Wartezeit zwischen den Wiederholungsversuchen ein. 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 initialRetryDelay und maxRetryDelay nicht erhöhen. Unter diesen Umständen können Sie jedoch die Ablaufsteuerung und Batchverarbeitung anpassen. Wenn die Veröffentlichung über eine unzuverlässige Internetverbindung oder eine bandbreitenbeschränkte Verbindung erfolgt, 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.

Speicherrichtlinie für Nachrichten verwenden, um den Speicherort von Daten sicherzustellen

Mit der Nachrichtenspeicherrichtlinie von Pub/Sub können Sie dafür sorgen, dass zu einem Thema veröffentlichte Nachrichten nie außerhalb einer von Ihnen angegebenen Gruppe von Google Cloud-Regionen gespeichert werden, unabhängig davon, woher die Veröffentlichungsanfragen stammen.

Geben Sie mithilfe der Nachrichtenspeicherrichtlinie eine Liste von Google Cloud-Regionen an, 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 nicht gegen die Organisationsrichtlinie verstoßen wird.

Beispielsweise kann ein in Europa tätiges Unternehmen mithilfe der Nachrichtenspeicherrichtlinie sicherstellen, dass alle Daten gemäß lokalen Gesetzen in EU-Regionen gespeichert werden.

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

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

Achten Sie bei der Nachrichtensortierung auf Folgendes:

  • Standortendpunkte verwenden Die Reihenfolge der Nachrichten wird sowohl auf der Publish-Seite als auch innerhalb einer Region beibehalten. Wenn Sie also 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 aber auf Regionen verteilt sind, erhalten die Abonnenten alle Nachrichten der Reihe nach. Verwenden Sie einen Standortendpunkt, um Nachrichten in derselben Region zu veröffentlichen.

  • Konfigurieren Sie eine Funktion zum Veröffentlichen von Lebensläufen. Wenn eine Clientbibliothek eine Anfrage wiederholt und die Nachricht einen Reihenfolgeschlüssel enthält, 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 beendet die Veröffentlichung anderer Nachrichten mit demselben Reihenfolgeschlüssel. Wenn Sie bereit sind, die Veröffentlichung für einen Reihenfolgeschlüssel fortzusetzen, dessen 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
Nachrichtenaufbewahrung konfigurieren Hängen Sie ein Abo an, bevor Sie die Nachrichtenaufbewahrung veröffentlichen oder aktivieren.
Nachrichten in einer Veröffentlichungsanfrage im Batch verarbeiten Stapel- oder Gruppennachrichten, um die Effizienz des Publishers zu steigern und Nachrichten mit einem höheren Durchsatz zu senden.
Ablaufsteuerung Konfiguriere die Ablaufsteuerung in den Publisher-Einstellungen, um vorübergehende Trafficspitzen zu verarbeiten.
Pub/Sub-Clients zum Maximieren der Streamingleistung testen Skalieren Sie den Durchsatz des Publishers, indem Sie die verfügbaren Maschinenkerne und die Netzwerkbandbreite erhöhen.
Anfragen wiederholen Nimm nur dann Anpassungen an den angegebenen Werten der Wiederholungsrichtlinie des Verlags oder Webpublishers vor, wenn die Standardeinstellungen für deinen 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 Sortierungsschlüsseln bei der Veröffentlichung einen Standortendpunkt verwenden Verwenden Sie bei der geordneten Nachrichtenfunktion einen Standortendpunkt und konfigurieren Sie bei Veröffentlichungsfehlern eine Funktion zur Veröffentlichung des Lebenslaufs.

Nächste Schritte