Pub/Sub: Einführung in die Zuverlässigkeit

Dieser Leitfaden bietet einen Überblick über die Zuverlässigkeitsfunktionen von Pub/Sub. In diesem Dokument werden folgende Themen behandelt:

• Warum Pub/Sub?
• Failover
• Publisher optimieren
• Abonnenten optimieren
• Snapshot verwenden und nach sicheren Bereitstellungen suchen

Warum Pub/Sub?

Als Messaging-Paradigma ist Publish-Subscribe darauf ausgelegt, die Ersteller von Nachrichten von den Nutzern dieser Nachrichten zu entkoppeln. Anstatt dass die Produzenten direkte Anfragen mit den Daten an die Verbraucher senden, veröffentlichen sie diese Daten stattdessen in einem Pub/Sub-Dienst wie Pub/Sub. Der Dienst stellt diese Nachrichten asynchron an interessierte Nutzer bereit, die sich angemeldet haben.

Der Dienst übernimmt also die gesamte Komplexität der Suche nach Nutzern, die an den Daten interessiert sind. Der Dienst verwaltet auch die Rate, mit der die Verbraucher die Daten basierend auf ihrer Kapazität erhalten. Durch die Entkopplung können Datenproduzenten Nachrichten unabhängig vom Verhalten der Verbraucher in großem Umfang und mit niedriger Latenz schreiben.

Pub/Sub bietet eine hoch skalierbare und zuverlässige Nachrichtenübermittlung. Viele dieser Aufgaben werden zwar automatisch vom Dienst ausgeführt, du hast aber die Möglichkeit, verschiedene Aspekte deiner Publisher und Abonnenten zu steuern, die sich auf Verfügbarkeit und Leistung auswirken können. Im Rest dieses Leitfadens finden Sie einige Details zu diesen Aspekten.

Failover

Pub/Sub ist ein globaler Dienst: Themen und Abos sind nicht an bestimmte Regionen gebunden und Nachrichten werden bei Bedarf innerhalb des Pub/Sub-Dienstes zwischen Regionen übertragen. Wenn der globale Endpunkt pubsub.googleapis.com verwendet wird, stellen Publisher und Abonnenten eine Verbindung zur nächstgelegenen Region her, in der Pub/Sub ausgeführt wird. Wenn Sie Standortendpunkte wie us-central1-pubsub.googleapis.com verwenden, stellen Publisher und Abonnenten eine Verbindung zu Pub/Sub in der angegebenen Region her. Wenn Sie Publisher oder Abonnenten außerhalb von Google Cloud ausführen, sollten Sie Standortendpunkte verwenden, damit Nachrichten konsistent zwischen den erwarteten Regionen fließen. Im Rest dieses Abschnitts erfahren Sie, wie Sie Themen und Abos erstellen. Außerdem wird erläutert, wie Publisher und Abonnenten angeordnet werden, um verschiedene Arten von Failover und Datenredundanz zu unterstützen.

Standard-Failover-Semantik

Angenommen, es gibt ein einzelnes Thema und Abo. Die Publisher befinden sich in Regionen der USA und Australien und die Abonnenten in den Google Cloud-Regionen Europa und Australien. Wenn alle Abonnenten genügend Kapazität haben, um Nachrichten zu empfangen, sieht der Nachrichtenfluss so aus:

Die P stehen für Publisher, die S für Abonnenten. Das blaue Sechseck steht für den Pub/Sub-Dienst. Die Zylinder stehen für die Speicherorte von Nachrichten. Nachrichten werden immer in mehreren Zonen in der Region gespeichert, in der sie veröffentlicht werden. Pub/Sub sendet Nachrichten vorzugsweise innerhalb der Region, in der sie veröffentlicht wurden, wenn Abonnenten verfügbar sind. Andernfalls werden die Nachrichten an die Region gesendet, die dem Netzwerk am nächsten ist und Abonnenten mit Kapazitäten hat. Daher werden, wie in der vorherigen Abbildung dargestellt, in den USA veröffentlichte Nachrichten an Abonnenten in Europa gesendet und in Australien veröffentlichte Nachrichten bleiben in Australien.

In den folgenden Abschnitten wird beschrieben, was bei verschiedenen Fehlerszenarien passiert.

Abos für Nutzer in Europa sind nicht verfügbar

Angenommen, Abonnenten in Europa wurden abgelehnt oder die App stürzte häufig ab und konnte keine Verbindung zu Pub/Sub herstellen. In diesem Fall werden Nachrichten über den Dienst an Abonnenten in Australien gesendet:

Für Abonnenten in Europa und Australien nicht verfügbar

Falls alle Abonnenten nicht verfügbar sind, speichert Pub/Sub die Nachrichten bis zur konfigurierten Aufbewahrungsdauer der Nachricht.

Sobald die Verbindung wiederhergestellt ist, werden die Nachrichten zugestellt, es sei denn, die Störung dauert länger als die konfigurierte Nachrichtenaufbewahrungsdauer. Standardmäßig ist die Aufbewahrungsdauer für Nachrichten für Abos auf 7 Tage festgelegt. Sie können auch die Aufbewahrung von Nachrichten für ein Thema für bis zu 31 Tage konfigurieren. Die Nachrichtenaufbewahrungsdauer darf nicht kürzer sein als die maximale Ausfallzeit, die Sie erwarten oder tolerieren möchten.

Pub/Sub ist in Europa nicht verfügbar

In seltenen Fällen kann es auch vorkommen, dass Pub/Sub selbst nicht verfügbar ist. Die Nichtverfügbarkeit von Pub/Sub äußert sich in längeren Zeiträumen mit unerwarteten Fehlern bei Veröffentlichungs- oder Aboanfragen oder in der Unfähigkeit, veröffentlichte Nachrichten an Abonnenten zu senden. Wenn beispielsweise Pub/Sub in der Region Europa ausfällt, sieht das Szenario in etwa so aus wie bei einem Ausfall von Abonnenten:

In diesem Fall werden die Abonnenten in Europa nicht auf eine andere Region umgeleitet, auch wenn der globale Endpunkt verwendet wird. Bei Pub/Sub wird bewusst kein automatisches Failover durchgeführt. Angenommen, die Abonnenten selbst verursachen ein unerwartetes Problem in Pub/Sub, das zu einer Nichtverfügbarkeit führt. Ein solches Problem wird als größerer Ausfall behandelt. Die Auswirkungen des Ausfalls können sich jedoch auf die Region beschränken, in der sich die Abonnenten befinden. Wenn der Dienst einen Failover zu einer anderen Region zulässt, können die Abonnenten dort ebenfalls zu einer Nichtverfügbarkeit führen, was zu einem kaskadierenden Ausfall des gesamten Dienstes führt.

Publisher in Australien sind nicht verfügbar

Wenn die Publisher in einer Region nicht mehr verfügbar sind, werden die bereits veröffentlichten Nachrichten weiterhin an die nächstgelegenen Abonnenten gesendet:

Letztendlich werden alle Nachrichten von Abonnenten abgerufen und bestätigt. Beim Senden von Nachrichten versucht Pub/Sub, die Netzwerkdistanz zu minimieren. Daher können Abonnenten in der Region Australien keine Nachrichten mehr erhalten, wenn die Abonnenten in Europa genügend Kapazität haben, um alle in den USA veröffentlichten Nachrichten zu verarbeiten.

Pub/Sub ist in den USA nicht verfügbar

Pub/Sub schreibt Nachrichten synchron in mehrere Zonen innerhalb einer Region. Daher reicht ein Zonenausfall nicht aus, um die Zustellung von Nachrichten zu verhindern. Die gesamte Region muss nicht verfügbar sein. Wenn Cloud Pub/Sub in einer Region, in der Publisher Nachrichten senden, nicht verfügbar ist, werden Nachrichten in dieser Region möglicherweise erst zugestellt, wenn der Dienst vollständig wiederhergestellt ist:

Die Nachricht wird letztendlich zugestellt (vorausgesetzt, die Aufbewahrungsdauer der Nachricht ist noch nicht abgelaufen), jedoch mit einer Verzögerung, die der Dauer der Störung entspricht. Ähnlich wie bei Abonnenten wird auch bei Publishern in den USA bei einem Dienstausfall nicht auf eine andere Region umgestellt. So wird die Wahrscheinlichkeit von kaskadierenden Fehlern in verschiedenen Regionen aufgrund eines fehlerhaften Publishers oder Abonnenten verringert.

Isolation

Die Standard-Failover-Semantik wirkt sich auf die Datenisolation aus und darauf, wie sich die Nichtverfügbarkeit von Publishern, Abonnenten oder Pub/Sub selbst auf den Nachrichtenfluss auswirken kann. Je nach Anwendungsfall sind möglicherweise unterschiedliche Isolationsebenen erforderlich. Beispielsweise kann es sein, dass Sie die Zustellung aller Nachrichten innerhalb der Region erfordern.

Wenn Sie keine Isolation wünschen, reichen die Standard-Failover-Semantiken aus. Sie müssen ein einzelnes Thema, ein einzelnes Abo erstellen und Publisher und Abonnenten in allen ausgewählten Regionen platzieren. Wenn die Abonnenten nicht verfügbar sind oder Pub/Sub in der Region, zu der sie eine Verbindung herstellen, ausfällt, wird die Zustellung auf Abonnenten in einer anderen Region umgestellt.

Wenn Sie die regionale Isolation verwenden möchten, bei der Daten garantiert nicht die Region verlassen, erstellen Sie ein Thema und ein Abo, um Nachrichten in jeder Region zu verarbeiten. Suchen Sie Publisher und Abonnenten in jeder dieser Regionen und bitten Sie sie, das entsprechende regionale Thema bzw. Abo zu veröffentlichen und zu abonnieren. Außerdem müssen Sie regionale Endpunkte verwenden, damit Daten nur innerhalb der Region übertragen werden. Bei Ausfällen von Publishern, Abonnenten oder Pub/Sub in einer einzelnen Region wird die Nachrichtenübermittlung in dieser Region beendet. Die Nachrichtenübermittlung für Themen und Abos in anderen Regionen ist davon nicht betroffen.

Außerdem ist in Pub/Sub keine zonale Isolation möglich, bei der Daten garantiert innerhalb einer einzelnen Zone bleiben. Wenn einzelne Zonen unabhängig sein müssen, verwenden Sie Pub/Sub Lite.

Kundengesteuertes Failover und Redundanz

Die Standard-Failover-Semantik von Pub/Sub kann nicht vollständig dafür sorgen, dass Nachrichten bei einer Störung immer von Publishern an Abonnenten gesendet werden können. Ausfälle können an verschiedenen Stellen auftreten, z. B. bei deinen Kunden, bei dem Dienst, den deine Publisher oder Abonnenten nutzen, im Netzwerk oder selten auch in Pub/Sub selbst. Wenn Ihre Dienste ausfallsicher sein sollen, müssen Sie eigene Redundanzen implementieren. In der Regel umfassen diese Redundanzen die Verwendung mehrerer Publisher- und Abonnenten-Clients, die jeweils einen anderen Standortendpunkt verwenden.

Sie können Ausfallsicherheit für zwei verschiedene Auswirkungen anstreben: zonal oder regional. Hier sind die Einrichtungsoptionen für die einzelnen Geräte:

Zonale Resilienz

Pub/Sub bietet eine integrierte zonenübergreifende Replikation. Bei Ausfällen, die sich auf eine einzelne Zone auswirken und den Dienst selbst betreffen, müssen Sie keine besonderen Maßnahmen ergreifen. Für eine Ausfallsicherheit für Ihre Kunden oder Ihr Netzwerk sollten Sie Publisher und Abonnenten mit ausreichender Kapazität in mehreren Zonen innerhalb der Region verwenden. Wenn eine Zone ausfällt, können die Clients in der anderen Zone den Traffic aufnehmen und die Nachrichten verarbeiten. Es wird empfohlen, Änderungen an diesen Clients nicht gleichzeitig zu veröffentlichen, damit bei einem Fehler die anderen, unveränderten Zonen weiterhin Nachrichten verarbeiten können.

Regionale Ausfallsicherheit

Um für regionale Ausfälle gerüstet zu sein, sollten Sie zusätzliche Redundanzen bei Ihren Publishern und Abonnenten einrichten. Sie können Publisher und Abonnenten in mehreren Regionen ausführen, um mögliche Ausfälle bei diesen Clients oder im Netzwerk zu vermeiden.

Wenn Sie für potenzielle Pub/Sub-Ausfälle in einer Region gewappnet sein möchten, müssen Sie einen Failover-Mechanismus für einen solchen Ausfall bereithalten. Die möglichen Ansätze sind ein Kompromiss zwischen der End-to-End-Latenz bei der Nachrichtenübermittlung und Ihren Kosten.

Wenn Kosten kein Problem sind, ist es am besten, immer gleichzeitig in verschiedenen Regionen zu veröffentlichen und zu abonnieren, um die Latenz zu minimieren. Wählen Sie zuerst die Anzahl der Regionen aus, in denen Sie Redundanz wünschen. Als Nächstes können Sie für jede dieser Regionen ein Thema und ein Abo einrichten. Dies ist nicht unbedingt erforderlich.

Jeder Publisher erstellt so viele Publisher-Clients wie es Regionen gibt (jeweils einen für jede Region) und verwendet einen anderen Standortendpunkt, damit Nachrichten an unterschiedliche Regionen weitergeleitet werden. Wenn du separate Themen verwendest, muss jeder Publisher-Client im entsprechenden regionalen Thema veröffentlichen. Für jede Nachricht ruft der Publisher „publish“ auf jedem Client auf. Bei redundanten Veröffentlichungen müssen Veröffentlichungen nicht wiederholt werden, wenn eine einzelne fehlschlägt.

Ähnlich erstellt jeder Abonnent so viele Abonnentenclients – einen für jede Region – und verwendet einen Standortendpunkt, um eine Verbindung zu einer anderen Region herzustellen. Wenn du für jede Region unterschiedliche Abos verwendest, muss jeder Abonnentenclient das entsprechende Abo verwenden. Die Regionen für Publisher und Abonnenten müssen nicht unbedingt identisch sein. Abonnenten erhalten Nachrichten über die drei Abos und verarbeiten sie.

Diese Einrichtung hat mehrere wichtige Funktionen und Anforderungen:

1. Ausfälle einzelner Regionen wirken sich nicht auf die Verarbeitung bereits veröffentlichter Nachrichten oder solcher aus, die während des Ausfalls veröffentlicht wurden. Da Nachrichten in mehreren Regionen veröffentlicht wurden, sind sie auch dann in anderen Regionen verfügbar, wenn eine Region ausgefallen ist. Während des Ausfalls schlagen Veröffentlichungsanfragen in der betroffenen Region fehl, in den anderen jedoch nicht.
2. Die Latenz bei der Nachrichtenverarbeitung ist nicht betroffen, solange eine der Regionen, über die Nachrichten fließen, verfügbar ist.
3. Die Nachrichtenverarbeitung muss idempotent sein. Da jede Nachricht mehrmals zugestellt wird, muss die Nachrichtenverarbeitung robust gegen Duplikate sein. Bei einem regionalen Ausfall werden einige dieser Duplikate möglicherweise erst viel später als die erste Zustellung der Nachricht zugestellt. Diese Duplikate stammen wahrscheinlich aus einer anderen Region, in der es keinen Ausfall gab.

Diese Art der Redundanz bietet die höchste Ausfallsicherheit bei jeglichen Ausfällen. Für interne Google-Dienste, die auf Pub/Sub basieren und die höchste Verfügbarkeit erfordern, wird diese Einrichtung bevorzugt. Bei dieser Einrichtung werden die Kosten für die Nachrichtenübermittlung jedoch mit der Anzahl der verwendeten Regionen multipliziert. Außerdem fallen zusätzliche Kosten für die interregionale Netzwerknutzung für Nachrichten an, die zwischen Regionen übertragen werden müssen.

Ein weiterer Ansatz für Redundanz besteht darin, nur dann zu einem Failover zu wechseln, wenn Anfragen fehlschlagen oder Nachrichten nicht wie erwartet von Publishern an Abonnenten gesendet werden. In diesem Szenario haben Sie eine primäre Region, zu der Sie Ihre Publisher und Abonnenten über Standortendpunkte weiterleiten. Wie bereits erwähnt, müssen sie sich nicht in derselben Region befinden. Außerdem haben Sie dann eine Fallback-Region für Publisher und Abonnenten, die verwendet wird, wenn die primäre Region nicht verfügbar ist.

Publisher veröffentlichen nur dann über den Standortendpunkt in der primären Region, wenn ihre Anfragen erfolgreich gesendet wurden. Wenn eine Region als ausgefallen erkannt wird, beginnen Publisher stattdessen mit der Veröffentlichung in der Fallback-Region. Es gibt zwei Möglichkeiten, festzustellen, ob die Region ausgefallen ist und ein Failover stattfindet. Das kann manuell erfolgen und die Konfiguration wird dann dynamisch bei den Publishern aktualisiert. Die Publisher können die Konfiguration auch selbst aktualisieren, wenn die Fehlerrate bei Veröffentlichungsanfragen ausreichend hoch ist.

Abonnenten müssen sich immer über den Standortendpunkt mit der primären Region verbinden. Du kannst festlegen, dass der Abonnent die Fallback-Region mit einem oder mehreren der folgenden Trigger verwenden kann:

1. Abonniere immer die Fallback-Region. In diesem Fall unterhält der Abonnent immer eine Verbindung sowohl zur primären als auch zur Fallback-Region. Dieselben Regionen können sowohl für den primären als auch für den Fallback sowohl für Publisher als auch für Abonnenten verwendet werden. In diesem Fall muss der Abonnent Nachrichten nur über die Sicherungsregion erhalten, wenn der Publisher einen Failover durchführt.
2. Abonnenten manuell erkennen und über eine Konfiguration zur Fallback-Region wechseln Wenn Sie einen Ausfall feststellen, können Sie ein Failover auf die Fallback-Region ausführen und dann nach Beendigung des Ausfalls wieder zur primären Region wechseln.
3. Bei Abonnentenfehlern wird ein Failover ausgeführt. Wenn bei den Anfragen von Abonnenten Fehler zurückgegeben werden, kannst du davon ausgehen, dass ein Failover auf die Fallback-Region erforderlich ist. Hinweis: Die Pub/Sub-Clientbibliotheken wiederholen Streaming-Pull-Anfragen bei vorübergehenden Fehlern intern. Daher können Sie möglicherweise nicht erkennen, dass es über einen längeren Zeitraum unerwartete Fehler gibt. Außerdem wird die Fehlerrate beim Streaming-Pull auch bei normalem Betrieb mit 100 % erwartet.
4. Failover, wenn der Abonnent unerwartet lange keine Nachrichten erhält. Wenn Nachrichten regelmäßig veröffentlicht werden, können Abonnenten immer Nachrichten erhalten. Wenn über einen längeren Zeitraum keine Nachrichten empfangen werden, liegt möglicherweise ein Problem auf der Abonnentenseite in Pub/Sub in der primären Region vor. Das Problem wird behoben, indem auf die Fallback-Region umgestellt wird.

Von den vier Optionen ist die erste ideal. Eine Abonnentenverbindung kostet nichts, wenn keine Nachrichten darüber übertragen werden. Die einzigen Kosten sind die der zusätzlichen Instanz der Abonnentenclientbibliothek, die vernachlässigbar sein können. Außerdem musst du das Kontingent für die Anzahl der offenen StreamingPull-Verbindungen pro Region beachten.

Der Vorteil dieses zweiten Modells besteht darin, dass es keinen Multiplikator bei den Pub/Sub-Kosten gibt, da Nachrichten nur einmal veröffentlicht werden. Der Nachteil ist jedoch, dass bei bestimmten Arten von Ausfällen Nachrichten, die vor Beginn des Ausfalls veröffentlicht wurden, möglicherweise erst nach der Behebung des Ausfalls verfügbar sind. Nachrichten, die in der nicht verfügbaren Region gespeichert sind, können Abonnenten möglicherweise nicht zugestellt werden, unabhängig davon, wo sie eine Verbindung haben. Nachrichten, die während des Ausfalls in der Fallback-Region veröffentlicht wurden, sind möglicherweise verfügbar. Außerdem kann es zu einer Zeit der Nichtverfügbarkeit mit erhöhten Fehlerraten für die Publisher oder Abonnenten kommen. Das hängt von der Methode ab, mit der ein Ausfall erkannt wird, und von der Zeit, die für den Failover zur Fallback-Region benötigt wird.

Unabhängig von der gewählten Option sollten Sie sich darüber im Klaren sein, wie sich diese auf die Funktionen von Pub/Sub auswirken kann. Sowohl die geordnete Zustellung als auch die genau einmalige Zustellung bieten innerhalb einer Region Garantien. Wenn Sie beispielsweise die Failover-Redundanz verwenden, ist die Zustellung von Nachrichten nur für Nachrichten gewährleistet, die in derselben Region veröffentlicht wurden. Der Abonnent kann Nachrichten, die in der Fallback-Region veröffentlicht wurden, vor Nachrichten erhalten, die in der primären Region veröffentlicht wurden, auch wenn die Nachrichten zuerst in der primären Region veröffentlicht wurden.

Publisher optimieren

Unabhängig davon, welche der Failover-Optionen Sie auswählen, müssen Sie einige zusätzliche Anpassungen an den Publisher-Websites vornehmen. Durch die Optimierung des Publisher-Verhaltens wird eine optimale Leistung bei hoher Auslastung sichergestellt. Batching-Nachrichten sind eine Möglichkeit, die Latenz gegen geringere Kosten einzutauschen. Sie sind jedoch nicht so wichtig für die Zuverlässigkeit und werden daher hier nicht behandelt. Konzentrieren Sie sich stattdessen auf einige der anderen Parameter, die sich zur Optimierung der Zuverlässigkeit eignen, z. B. die Einstellungen für Wiederholungen und die Einstellungen für die Ablaufsteuerung.

Die Veröffentlichung kann aus verschiedenen Gründen fehlschlagen, z. B. aufgrund vorübergehender Probleme wie Netzwerkausfall oder aufgrund von Problemen, die eine Nutzeraktion erfordern, z. B. Berechtigungsänderungen. Die Pub/Sub-Clientbibliothek versucht, vorübergehende Fehler mit den in den Wiederholungseinstellungen angegebenen Parametern noch einmal zu verarbeiten. Mit diesen Einstellungen wird das Verhalten des exponentiellen Backoffs bei Wiederholungsversuchen von Publish-RPCs gesteuert, die aus vorübergehenden Gründen fehlschlagen. Die Standardeinstellungen funktionieren in den meisten Fällen gut. Es gibt jedoch Situationen, in denen Sie diese Werte anpassen sollten.

Die beiden Eigenschaften, die Sie am ehesten optimieren möchten, sind die anfängliche RPC-Zeitüberschreitung und die Gesamtzeitüberschreitung. Die anfängliche RPC-Zeitüberschreitung gibt an, wie lange der erste Publish-RPC abgeschlossen werden muss. Wenn eine RPC fehlschlägt oder eine Zeitüberschreitung auftritt, wird eine weitere mit einer längeren Zeitüberschreitung versucht, bis die Gesamtzahl der Anfragen oder die Gesamtzeitüberschreitung überschritten wird.

Die anfängliche Zeitüberschreitung kann angepasst werden, wenn dein Publisher Netzwerkeinschränkungen unterliegt oder weit vom nächsten Google Cloud-Rechenzentrum entfernt ist, in dem Pub/Sub ausgeführt wird. Netzwerkeinschränkungen können Einschränkungen des Durchsatzes des Computers sein, auf dem der Publisher ausgeführt wird, oder das Ergebnis anderer netzintensiver Dienste sein, die auf demselben Computer ausgeführt werden. Wenn die Zeitüberschreitung zu kurz ist, können anfängliche RPCs wiederholt fehlschlagen. Dies führt dazu, dass mehr Versuche (mit längeren Zeitüberschreitungen) erforderlich sind, um die Veröffentlichung erfolgreich durchzuführen. Die wiederholte Notwendigkeit von Wiederholungen erhöht die Veröffentlichungslatenz. In diesem Fall kann eine Erhöhung der anfänglichen Zeitüberschreitung zu einer schnelleren Veröffentlichung führen.

Wenn die Netzwerkverbindung nicht zuverlässig ist, kann es hilfreich sein, sowohl die Gesamtzeitüberschreitung als auch die anfängliche Zeitüberschreitung zu erhöhen. Eine längere Gesamtzeitüberschreitung gibt dem Publish-RPC mehr Zeit, um erfolgreich abgeschlossen zu werden. Wenn Veröffentlichungs-RPCs immer wieder mit dem Fehler „Frist überschritten“ fehlschlagen, sollten Sie diese Werte anpassen.

Wenn bei der Veröffentlichung wiederholt die Frist überschritten wird, kann es auch sein, dass die Ablaufsteuerung des Publishers angepasst werden muss. Mit diesen Einstellungen können Sie dafür sorgen, dass Ihre Publisher bei Spitzen des eingehenden Traffics, die mehr Nachrichten an Pub/Sub generieren, leistungsfähig bleiben. Ein starker Anstieg der ausgehenden Anfragen kann die CPU, den Arbeitsspeicher oder die Netzwerkkapazität des Publishers überlasten. Wenn die Veröffentlichung überlastet ist, können Veröffentlichungsanfragen oder ‑antworten nicht vor Ablauf der Zeitüberschreitung verarbeitet werden. Dies führt zu noch mehr Veröffentlichungsanfragen und letztendlich zum Erreichen der Gesamtzeitüberschreitung. Die Ablaufsteuerung des Publishers schränkt die Anzahl der Nachrichten oder Bytes ein, die ohne Antwort auf die Publish-Anfrage ausstehen können. Durch die Begrenzung der Anzahl der Anfragen bleibt die Ressourcenauslastung auch bei Spitzen auf einem überschaubaren Niveau. Je nach Art der Publisher-Bedienung kannst du festlegen, dass nachfolgende Publish-RPCs auf Kapazität warten sollen, indem du zulässt, dass Publish weitere Anfragen blockiert. Alternativ können Sie die Aufrufer Ihres Dienstes zurückweisen, indem die Ablaufsteuerung bei Erreichen der Kapazität einen Fehler zurückgibt. Du konfigurierst, wie die Publisher-Clientbibliothek auf das Überschreiten des Limits reagiert.

Abonnenten optimieren

Möglicherweise ist auch eine Anpassung der Abonnenten erforderlich, damit sie zuverlässig funktionieren. Ähnlich wie Publisher können Sie die Einstellungen für die Ablaufsteuerung von Abonnenten anpassen, damit sie nicht überlastet werden. Die Abonnentenclientbibliothek verwendet Streaming-Pull, bei dem der Client einen persistenten Stream zum Server öffnet und der Server Nachrichten sendet, sobald sie verfügbar sind. Bei einer starken Zunahme der veröffentlichten Nachrichten erhält der Abonnent möglicherweise mehr Nachrichten, als er verarbeiten kann. Bei aktivierter Ablaufsteuerung ist die Anzahl der unbestätigten Nachrichten, die für den Client aktuell ausstehen, begrenzt. Dadurch wird die Anzahl der gleichzeitig verarbeiteten Nachrichten reduziert und die Verarbeitung wird auf einen längeren Zeitraum verteilt. Durch die Ausweitung der Auslastung können Abonnenten alle Ressourceneinschränkungen einhalten, die sich auf die Nachrichtenverarbeitung auswirken. Dies kann zu einem Dominoeffekt führen, der dazu führt, dass keine Nachrichten mehr verarbeitet werden können.

Die Ablaufsteuerung allein ist ausreichend, wenn Sie nur Spitzen bei der zu verarbeitenden Datenmenge erwarten, die sich letztendlich wieder abschwächen. Wenn der Traffic aufgrund einer höheren Nutzung im Laufe der Zeit generell zunimmt, schützt die Ablaufsteuerung die Abonnenten. Dies kann jedoch zu einem Backlog führen, das sich weiter anstaut und dazu, dass Nachrichten nicht zugestellt werden können, bevor die Aufbewahrungsdauer der Nachrichten abgelaufen ist. In solchen Fällen können Sie auch die automatische Skalierung so einstellen, dass bei einer steigenden Anzahl nicht bestätigter Nachrichten mehr Abonnenten hinzugefügt werden. Wie du das einrichtest, hängt von der Rechenplattform ab, die du für deine Abonnenten verwendest. Mit dem automatischen Skalierer der Compute Engine können Sie beispielsweise anhand von Messwerten wie der Anzahl nicht zugestellter Nachrichten skalieren. Wenn Sie sowohl das Autoscaling als auch die Ablaufsteuerung verwenden, sind Ihre Abonnenten widerstandsfähig gegenüber anderen kurzfristigen Spitzen beim Nachrichtendurchsatz und längerfristigem Wachstum, das mehr Rechenleistung erfordert.

Snapshot verwenden und sichere Bereitstellungen suchen

Der Verlust von Nachrichten ist in der Regel ein katastrophales Ereignis. Pub/Sub bietet eine mindestens einmalige Zustellung für alle veröffentlichten Nachrichten. Die korrekte Verarbeitung dieser Nachrichten hängt jedoch vom Verhalten der Abonnenten ab. Wenn Nachrichten erfolgreich bestätigt wurden, werden sie von Pub/Sub nicht noch einmal gesendet. Ein Fehler im neuen von Ihnen bereitgestellten Abonnentencode, durch den Nachrichten bestätigt werden, ohne dass sie korrekt verarbeitet wurden, kann daher zu einem durch Abonnenten verursachten Nachrichtenverlust führen. Pub/Sub bietet die Funktion Snapshot und Suche, mit der Sie dafür sorgen können, dass jede Nachricht richtig verarbeitet wird, auch bei Abonnentenfehlern.

Das Muster für jede Abobereitstellung muss so aussehen:

Wie lange du warten musst, bevor du feststellst, ob der neue Abonnent funktioniert, hängt von deinem Anwendungsfall ab. Die Schritte können nur beendet werden, wenn ein Abonnent als arbeitsfähig eingestuft wird. In diesem Fall kann der Snapshot gelöscht werden.

Die Verwendung von Snapshots und Suchvorgängen soll nicht die Best Practices ersetzen, die für das erstmalige Ausführen von Software in einer nicht produktiven Umgebung und die schrittweise Bereitstellung in der Produktion gelten. Sie bieten eine zusätzliche Schutzebene, um eine zuverlässige Datenverarbeitung zu ermöglichen. Der Nachteil ist, dass das Suchen nach dem Snapshot dazu führen kann, dass Nachrichten, die Ihr Abonnent bereits verarbeitet hat, doppelt zugestellt werden. Da Pub/Sub standardmäßig die Semantik „mindestens einmal“ verwendet, sind Ihre Abonnenten jedoch bereits für die erneute Zustellung von Nachrichten gerüstet.