In dieser Anleitung erhalten Sie ein Verständnis und ein Gesamtbild der Pub/Sub-Zuverlässigkeitsfeatures. In diesem Dokument werden folgende Themen behandelt:
- Warum Pub/Sub?
- Failover
- Publisher optimieren
- Abonnenten werden abgestimmt
- Sichere Bereitstellungen mit Snapshot und Suche verwenden
Warum Pub/Sub?
Publish/Subscribe dient als Messaging-Paradigma, die Nachrichtenersteller von den Empfängern dieser Nachrichten zu entkoppeln. Anstatt mit den Daten direkte Anfragen an die Nutzer zu senden, veröffentlichen sie die Daten stattdessen in einem Pub/Sub-Dienst wie Pub/Sub. Der Dienst stellt diese Nachrichten asynchron an interessierte, abonnierte Nutzer zu.
Das Ergebnis ist, dass der Dienst alle komplexen Schritte zur Suche nach Nutzern aufnimmt, die an den Daten interessiert sind. Der Dienst verwaltet auch die Rate, mit der die Nutzer die Daten empfangen, basierend auf ihrer Kapazität. Durch die Entkopplung können Datenersteller Nachrichten in großem Umfang und mit niedriger Latenz schreiben, unabhängig vom Verhalten der Empfänger.
Pub/Sub bietet eine hoch skalierbare, zuverlässige Übermittlung von Nachrichten. Der Dienst übernimmt einen Großteil dieser Aufgaben automatisch. Sie haben jedoch die Kontrolle über verschiedene Aspekte Ihrer Publisher und Abonnenten, die sich auf Verfügbarkeit und Leistung auswirken können. Im weiteren Verlauf dieses Leitfadens werden einige Details zu diesen Aspekten erläutert.
Failover
Pub/Sub ist ein globaler Dienst: Themen und Abos sind nicht an bestimmte Regionen gebunden und Nachrichten werden bei Bedarf zwischen Regionen innerhalb des Pub/Sub-Dienstes übertragen. Bei Verwendung des globalen Endpunkts pubsub.googleapis.com stellen Publisher und Abonnenten eine Verbindung mit der Region her, die dem Netzwerk am nächsten liegt, in der Pub/Sub ausgeführt wird. Bei Verwendung der Standortendpunkte wie us-central1-pubsub.googleapis.com 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, empfiehlt es sich, Standortendpunkte zu verwenden, um einen konsistenten Nachrichtenfluss zwischen den erwarteten Regionen sicherzustellen. Im Rest dieses Abschnitts geht es um das Erstellen von Themen und Abos. Darüber hinaus wird erläutert, wie Sie Publisher und Abonnenten platzieren, um verschiedene Arten von Failover und Datenredundanz zu unterstützen.
Standard-Failover-Semantik
Angenommen, es gibt nur ein Thema und ein Abo. Publisher befinden sich in den Regionen der USA und Australien, die Abonnenten in den Google Cloud-Regionen Europa und Australien. Wenn alle Abonnenten genügend Kapazität zum Empfangen von Nachrichten haben, sieht der Nachrichtenfluss so aus:
Das P steht für Publisher, das S für Abonnenten. Das blaue Sechseck steht für den Pub/Sub-Dienst. Die Zylinder stellen die Orte dar, an denen Nachrichten gespeichert werden (Nachrichten werden immer in mehreren Zonen in der Region gespeichert, in der sie veröffentlicht werden). Pub/Sub sendet Nachrichten vorzugsweise in derselben Region, in der sie veröffentlicht wurden, wenn Abonnenten verfügbar sind. Andernfalls werden die Nachrichten an die Region am nächsten Netzwerk mit Abonnenten gesendet, die Kapazitäten haben. Daher werden, wie in der vorherigen Abbildung gezeigt, dass in den USA veröffentlichte Nachrichten an Abonnenten in Europa zugestellt und innerhalb Australiens veröffentlichte Nachrichten in Australien bleiben.
In den folgenden Abschnitten wird erläutert, was in verschiedenen Fehlerszenarien passiert.
Abonnenten in Europa sind nicht verfügbar
Angenommen, Abonnenten in Europa wurden eingestellt oder stürzen häufig ab und können keine Verbindung zu Pub/Sub aufrechterhalten. In diesem Fall würde der Dienst damit beginnen, Nachrichten an Abonnenten in Australien zu senden:
Abonnenten in Europa und Australien sind nicht verfügbar
Falls keine Abonnenten verfügbar sind, speichert Pub/Sub die Nachrichten bis zur konfigurierten Nachrichtenaufbewahrungsdauer.
Sobald die Abonnenten wieder eine Verbindung herstellen, werden die Nachrichten zugestellt, es sei denn, der Ausfall dauert länger als die konfigurierte Nachrichtenaufbewahrungsdauer. Standardmäßig ist die Aufbewahrung von Abonachrichten auf 7 Tage eingestellt. Sie können auch die Aufbewahrungsdauer von Nachrichten zu einem Thema auf maximal 31 Tage festlegen. Wählen Sie keine Nachrichtenaufbewahrungsdauer aus, die kürzer ist als der maximale Ausfall, den Sie erwarten oder tolerieren möchten.
Pub/Sub ist in Europa nicht verfügbar
In seltenen Fällen können Sie auch Fälle behandeln, in denen Pub/Sub selbst nicht verfügbar ist. Wenn Pub/Sub nicht verfügbar ist, kommt es zu unerwarteten Fehlern bei Veröffentlichungs- oder Aboanfragen oder wenn es nicht möglich ist, veröffentlichte Nachrichten an Abonnenten zu senden. Wenn beispielsweise Pub/Sub in der Region in Europa ausgefallen ist, sieht das Szenario ähnlich aus wie bei einem Ausfall der Abonnenten:
Beachten Sie, dass in diesem Fall für die Abonnenten in Europa kein Failover zu einer anderen Region durchgeführt wird, auch wenn sie den globalen Endpunkt verwenden. Pub/Sub führt absichtlich kein automatisches Failover durch. Stellen Sie sich vor, es sind die Abonnenten selbst, die ein unerwartetes Problem in Pub/Sub verursachen, das zu einer Nichtverfügbarkeit führt. Ein solches Problem wird als schwerer Ausfall behandelt. Der Umfang der Auswirkungen des Ausfalls kann jedoch auf die Region beschränkt werden, mit der die Abonnenten verbunden sind. Wenn der Dienst ein Failover in eine andere Region zulässt, können die Abonnenten dort ebenfalls zur Nichtverfügbarkeit führen, was zu einem kaskadierenden Ausfall des 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 zugestellt:
Schließlich werden alle Nachrichten von Abonnenten verarbeitet und bestätigt. Beim Senden von Nachrichten versucht Pub/Sub, die Netzwerkentfernung zu minimieren. Daher können Abonnenten in der Region in Australien keine Nachrichten mehr empfangen, 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 mehr verfügbar ist, werden Nachrichten in dieser Region möglicherweise erst zugestellt, wenn der Dienst vollständig wiederhergestellt wurde:
Die Nachricht wird letztendlich zugestellt (vorausgesetzt, die Nachrichtenaufbewahrungsdauer ist noch nicht abgelaufen), verzögert durch die Dauer des Ausfalls. Ähnlich wie bei Abonnenten führen auch die Publisher in den USA kein Failover zu einer anderen Region durch, wenn der Dienst ausfällt. Dadurch wird die Wahrscheinlichkeit von regionsübergreifenden Fehlern verhindert, die auf einen fehlerhaften Publisher oder Abonnenten zurückzuführen sind.
Isolation
Die standardmäßige Failover-Semantik wirkt sich im Detail auf die Datenisolation aus und darauf, wie sich die Nichtverfügbarkeit von Publishern, Abonnenten oder Pub/Sub selbst auf den Nachrichtenfluss auswirken kann. Ihr Anwendungsfall kann unterschiedliche Isolationsebenen erfordern. Beispielsweise können Sie festlegen, dass alle Nachrichten intraregional zugestellt werden sollen.
Wenn Sie keine Isolation wünschen, reicht die detaillierte standardmäßige Failover-Semantik aus. Sie müssen ein einzelnes Thema und ein einzelnes Abo erstellen und Publisher und Abonnenten in allen ausgewählten Regionen platzieren. Wenn die Abonnenten nicht mehr verfügbar sind oder Pub/Sub in der Region, mit der sie eine Verbindung herstellen, ausgefallen ist, erfolgt ein Failover an Abonnenten in einer anderen Region.
Erstellen Sie für die regionale Isolierung, bei der garantiert wird, dass Daten eine Region nicht verlassen, ein Thema und ein Abo, um Nachrichten in jeder Region zu verarbeiten. Suchen Sie nach Publishern und Abonnenten in jeder dieser Regionen und lassen Sie sie das entsprechende regionale Thema und Abo veröffentlichen bzw. abonnieren. Außerdem müssen Sie regionale Endpunkte verwenden, damit Daten nur innerhalb der Region verschoben werden. Im Fall von Publisher-, Abonnenten- oder Pub/Sub-Fehlern in einer einzelnen Region wird die Nachrichtenzustellung in dieser Region beendet. Die Nachrichtenzustellung zu Themen und Abos für andere Regionen ist nicht betroffen.
Außerdem ist eine zonale Isolation, bei der Daten garantiert in einer einzelnen Zone verbleiben, in Pub/Sub nicht möglich. Wenn einzelne Zonen unabhängig sein müssen, verwenden Sie Pub/Sub Lite.
Kundengesteuerte Failover und Redundanz
Die standardmäßige Failover-Semantik von Pub/Sub garantiert nicht vollständig, dass Nachrichten bei einem Ausfall immer von Publishern zu Abonnenten fließen können. Ausfälle können an verschiedenen Stellen auftreten, z. B. in Ihren Clients, im Dienst, den Ihre Publisher oder Abonnenten ausführen, im Netzwerk oder in Pub/Sub selbst. Wenn Sie möchten, dass Ihre Dienste einem solchen Ausfall standhalten können, müssen Sie eigene Redundanzen implementieren. In der Regel umfassen diese Redundanzen die Verwendung mehrerer Instanzen von Publisher- und Abonnentenclients, bei denen jede einen anderen Standortendpunkt verwendet.
Sie können die Ausfallsicherheit in zwei verschiedenen Auswirkungsbereichen erhöhen: zonal oder regional. Im Folgenden finden Sie die jeweiligen Einrichtungsoptionen.
Zonale Ausfallsicherheit
Pub/Sub verfügt über eine integrierte zonenübergreifende Replikation. Bei Ausfällen in einer einzelnen Zone, die sich auf den Dienst selbst auswirken, müssen Sie keine besonderen Maßnahmen ergreifen. Um jedoch für Ihre Clients oder Ihr Netzwerk Ausfallsicherheit zu gewährleisten, ist es am besten, Publisher und Abonnenten mit ausreichender Kapazität in mehreren Zonen innerhalb der Region auszuführen. Wenn eine einzelne Zone ausgefallen ist, können die Clients in der anderen Zone den Traffic aufnehmen und die Nachrichten verarbeiten. Es hat sich bewährt, Änderungen an diesen Clients nicht gleichzeitig zu veröffentlichen. So können bei Auftreten eines Fehlers die Nachrichten in den anderen unberührten Zonen weiterhin verarbeitet werden.
Regionale Ausfallsicherheit
Um regionalen Ausfällen standzuhalten, sollten Sie zusätzliche Redundanzen bei Ihren Publishern und Abonnenten einrichten. Sie können Publisher und Abonnenten in mehreren Regionen betreiben, um mögliche Ausfälle bei diesen Clients oder im Netzwerk zu vermeiden.
Wenn Sie gegen potenzielle Pub/Sub-Ausfälle in einer Region resistent sein möchten, benötigen Sie einen Failover-Mechanismus, mit dem Sie solche Ausfälle bewältigen können. Die möglichen Ansätze stellen einen Kompromiss zwischen der End-to-End-Nachrichtenzustellungslatenz und Ihren Kosten dar.
Um die Latenz zu minimieren, falls die Kosten keine Rolle spielen, empfiehlt es sich, immer gleichzeitig in verschiedenen Regionen zu veröffentlichen und ein Abo abzuschließen. Wählen Sie zuerst die Anzahl der Regionen aus, in denen Sie Redundanz wünschen. Im nächsten Schritt können Sie für jede dieser Regionen ein Thema und ein Abo einrichten, auch wenn dies nicht unbedingt erforderlich ist.
Jeder Publisher erstellt so viele Publisher-Clients, wie es Regionen gibt (eine für jede Region) und verwendet einen anderen geografischen Endpunkt, damit Nachrichten an bestimmte Regionen weitergeleitet werden. Wenn Sie separate Themen verwenden, muss jeder Publisher-Client im entsprechenden regionsspezifischen Thema veröffentlichen. Der Publisher ruft für jede Nachricht „publish“ auf jedem Client auf. Bei den redundanten Veröffentlichungen müssen Sie die Veröffentlichungen nicht wiederholen, wenn eine einzelne fehlschlägt.
Auf ähnliche Weise erstellt jeder Abonnent so viele Abonnentenclients – einen für jede Region – und verwendet einen Standortendpunkt, um eine Verbindung zu einer anderen Region herzustellen. Wenn Sie für jede Region unterschiedliche Abos verwenden, muss jeder Abonnentenclient das entsprechende Abo verwenden. Beachten Sie, dass die für Publisher und Abonnenten verwendeten Regionen nicht unbedingt identisch sein müssen. Abonnenten erhalten Nachrichten über die drei Abos und verarbeiten sie.
Diese Konfiguration hat mehrere wichtige Funktionen und Anforderungen:
- Der Ausfall einer einzelnen Region wirkt sich weder auf die Verarbeitung von bereits veröffentlichten Nachrichten noch auf die während des Ausfalls veröffentlichten Nachrichten aus. Da Nachrichten in mehreren Regionen veröffentlicht wurden, sind sie für den Fall, dass eine Region ausgefallen ist, weiterhin in anderen Regionen verfügbar. Während des Ausfalls schlagen Veröffentlichungsaufrufe in der betroffenen Region fehl, in den anderen hingegen erfolgreich.
- Die Latenz der Nachrichtenverarbeitung wird nicht beeinträchtigt, solange eine der Regionen, durch die Nachrichten fließen, verfügbar ist.
- Die Nachrichtenverarbeitung muss idempotent sein. Da jede Nachricht mehrmals zugestellt werden wird, muss die Nachrichtenverarbeitung dupliziert werden können. Im Falle eines regionalen Ausfalls können einige dieser Duplikate viel später als bei der ersten Zustellung der Nachricht auftreten. Diese Duplikate stammen wahrscheinlich aus einer anderen Region, in der kein Ausfall aufgetreten ist.
Diese Art von Redundanz bietet die höchste Resilienz gegen jegliche Ausfälle. Diese Einrichtung wird für interne Google-Dienste bevorzugt, die auf Pub/Sub basieren und die höchste Verfügbarkeit erfordern. Dabei müssen jedoch die Kosten für die Nachrichtenzustellung mit der Anzahl der verwendeten Regionen multipliziert werden. Außerdem fallen zusätzliche Kosten für die interregionale Netzwerknutzung für Nachrichten an, die zwischen Regionen verschoben werden müssen.
Ein weiterer Ansatz für Redundanz besteht darin, nur dann ein Failover durchzuführen, 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 leiten. Wie zuvor muss dies nicht dieselbe Region sein. Sie haben dann auch eine Fallback-Region für Publisher und Abonnenten, die verwendet wird, wenn die primäre Region nicht verfügbar ist.
Publisher veröffentlichen nur in der primären Region (über den Standortendpunkt), wenn ihre Anfragen erfolgreich gesendet wurden. Sobald festgestellt wird, dass die Region nicht verfügbar ist, beginnen Publisher stattdessen mit der Veröffentlichung in der Fallback-Region. Sie können auf zwei Arten feststellen, ob die Region ausgefallen ist und ein Failover erfolgt. Dies kann durch einen manuellen Prozess erfolgen, bei dem die Konfiguration bei den Publishern dynamisch aktualisiert wird. Die Publisher können die Konfiguration auch selbst aktualisieren, wenn die Fehlerrate in Veröffentlichungsanfragen ausreichend hoch ist.
Abonnenten müssen sich immer über den Standortendpunkt mit der primären Region verbinden. Sie können entscheiden, ob der Abonnent die Fallback-Region mit einem oder mehreren der folgenden Trigger verwenden kann:
- Abonnieren Sie immer die Fallback-Region. In diesem Fall hält der Abonnent jederzeit eine Verbindung zur primären Region und zur Fallback-Region aufrecht. Dieselben Regionen können sowohl für Publisher als auch für Abonnenten für die primäre Version und das Fallback verwendet werden. In diesem Fall darf der Abonnent nur dann Nachrichten über die Sicherungsregion empfangen, wenn der Publisher ein Failover durchgeführt hat.
- Abonnenten können über eine Konfiguration manuell erkannt und auf die Fallback-Region umgestellt werden. Wenn Sie einen Ausfall feststellen, können Sie ein Failover auf die Fallback-Region ausführen und dann zur primären Region zurückkehren, wenn der Ausfall nachgelassen hat.
- Failover bei Abonnentenfehlern Wenn bei den Abonnentenanfragen Fehler zurückgegeben werden, ist dies ein Hinweis darauf, dass ein Failover auf die Fallback-Region erforderlich ist. Beachten Sie, dass die Pub/Sub-Clientbibliotheken Streaming-Pull-Anfragen intern bei vorübergehenden Fehlern wiederholen, sodass Sie möglicherweise nicht erkennen können, dass es lange Zeiträume mit unerwarteten Fehlern gibt. Darüber hinaus wird erwartet, dass die Streaming-Pull-Fehlerrate auch während des normalen Betriebs 100 % beträgt.
- Failover, wenn der Abonnent eine unerwartet lange Zeit ohne Nachrichten empfangen muss Unter der Annahme, dass Nachrichten konsistent veröffentlicht werden, können die Abonnenten immer Nachrichten erhalten. Wenn über einen längeren Zeitraum keine Nachrichten empfangen werden, liegt möglicherweise ein Aboproblem in Pub/Sub in der primären Region vor. Dies wird durch ein Failover auf die Fallback-Region behoben.
Von allen vier Optionen ist die erste ideal. Eine Abonnentenverbindung ist kostenlos, wenn keine Nachrichten gesendet werden. Die einzigen Kosten entstehen, wenn die zusätzliche Instanz der Abonnenten-Clientbibliothek vernachlässigt wird. Achten Sie auch auf das Kontingent für die Anzahl der offenen Streaming-Pull-Verbindungen pro Region.
Der Vorteil dieses zweiten Modells besteht darin, dass es bei den Pub/Sub-Kosten keinen Multiplikator gibt, da Nachrichten nur einmal veröffentlicht werden. Allerdings müssen bei bestimmten Ausfalltypen Nachrichten, die vor Beginn des Ausfalls veröffentlicht wurden, möglicherweise erst nach Behebung des Ausfalls verfügbar sein. Nachrichten, die in einer nicht verfügbaren Region gespeichert sind, können möglicherweise nicht an Abonnenten zugestellt werden, unabhängig davon, wo sie verbunden sind. Nachrichten, die während des Ausfalls in der Fallback-Region veröffentlicht wurden, können verfügbar sein. Darüber hinaus kann es einen Zeitraum der Nichtverfügbarkeit mit höheren Fehlerraten für die Publisher oder Abonnenten geben. Dies hängt von der Methode ab, die zur Erkennung eines Ausfalls verwendet wird, und von der Zeit für das Failover in die Fallback-Region.
Unabhängig davon, für welche Option Sie sich entscheiden, sollten Sie sich bewusst sein, wie dies mit Pub/Sub-Funktionen interagieren kann. Sowohl die bestellte Zustellung als auch die genau einmalige Zustellung bieten ihre Garantien innerhalb einer Region. Wenn Sie beispielsweise das Failover-Redundanzverfahren verwenden, wird die Nachrichtenzustellung nur so garantiert, dass sie in derselben Region veröffentlicht wird. Der Abonnent kann Nachrichten empfangen, die in der Fallback-Region veröffentlicht wurden, bevor Nachrichten in der primären Region veröffentlicht werden, auch wenn die Nachrichten zuerst in der primären Region veröffentlicht wurden.
Publisher optimieren
Unabhängig davon, für welche der Failover-Optionen Sie sich entscheiden, müssen Sie einige zusätzliche Abstimmungsschritte in den Publishern selbst ausführen. Durch die Optimierung des Publisher-Verhaltens wird auch bei hoher Last eine optimale Leistung erzielt. Das Sammeln von Nachrichten ist eine Möglichkeit, die Latenz gegen geringere Kosten abzuwägen. Die Zuverlässigkeit ist hier jedoch nicht so wichtig und wird hier nicht behandelt. Konzentrieren Sie sich stattdessen auf einige andere Parameter, die für die Zuverlässigkeit hilfreich sind, einschließlich Wiederholungseinstellungen und Einstellungen für die Ablaufsteuerung.
Veröffentlichungen können aus verschiedenen Gründen fehlschlagen, z. B. vorübergehende Gründe wie Netzwerkunverfügbarkeit oder Nutzereingriffe wie Berechtigungsänderungen. Die Pub/Sub-Clientbibliothek wiederholt vorübergehende Fehler mit den Parametern, die in den Einstellungen für Wiederholungsversuche angegeben sind. Diese Einstellungen steuern das Verhalten des exponentiellen Backoffs bei Wiederholungen von Veröffentlichungs-RPCs, die vorübergehend fehlschlagen. Die Standardeinstellungen funktionieren in den meisten Szenarien gut. Es gibt jedoch Situationen, in denen Sie diese Werte optimieren können.
Die beiden Attribute, die Sie wahrscheinlich anpassen möchten, sind das anfängliche RPC-Zeitlimit und das Gesamtzeitlimit. Das anfängliche RPC-Zeitlimit gibt an, wie lange der erste Veröffentlichungs-RPC benötigt wird, um abzuschließen. Wenn ein RPC fehlschlägt oder eine Zeitüberschreitung eintritt, wird ein anderer RPC mit einem längeren Zeitlimit versucht, bis die Gesamtzahl der Anfragen oder das Zeitlimit überschritten ist.
Das anfängliche Zeitlimit kann angepasst werden, wenn Ihr Publisher durch das Netzwerk eingeschränkt ist oder weit vom nächstgelegenen Google Cloud-Rechenzentrum entfernt ist, in dem Pub/Sub ausgeführt wird. Netzwerkeinschränkungen können Einschränkungen für den Durchsatz des Computers sein, auf dem der Publisher ausgeführt wird, oder das Ergebnis anderer netzwerkintensiver Dienste, die auf derselben Maschine ausgeführt werden. Wenn das Zeitlimit zu kurz ist, können anfängliche RPCs wiederholt fehlschlagen, was zu weiteren Versuchen (mit längeren Zeitüberschreitungen) für eine erfolgreiche Veröffentlichung notwendig ist. Die wiederholte Notwendigkeit von Wiederholungen erhöht die Veröffentlichungslatenz. In diesem Fall kann eine Erhöhung des anfänglichen Zeitlimits zu schnelleren Veröffentlichungen führen.
Wenn die Netzwerkverbindung unzuverlässig ist, kann eine Erhöhung des Gesamtzeitlimits sowie des anfänglichen Zeitlimits hilfreich sein. Ein erhöhtes Gesamtzeitlimit gibt dem Veröffentlichungs-RPC mehr Zeit für einen erfolgreichen Abschluss. Wenn Veröffentlichungs-RPCs regelmäßig mit Zeitüberschreitungsfehlern fehlschlagen, sollten Sie diese Werte anpassen.
Fehler aufgrund einer überschrittenen Frist bei der Veröffentlichung können auch darauf hindeuten, dass die Publisher-Ablaufsteuerung optimiert werden muss. Mit diesen Einstellungen können Sie dafür sorgen, dass Ihre Publisher auch nach Spitzen beim eingehenden Traffic resistent sind, die mehr Nachrichten zum Senden an Pub/Sub generieren. Eine starke Zunahme ausgehender Anfragen kann die CPU-, Arbeitsspeicher- oder Netzwerkkapazität des Publishers überlasten. Wenn die Veröffentlichung überlastet ist, können Veröffentlichungsanfragen oder ‐antworten vor Ablauf der Zeitüberschreitung nicht verarbeitet werden. Das führt zu noch mehr Veröffentlichungsanfragen und letztendlich zum Erreichen des Gesamtzeitlimits. Mit der Ablaufsteuerung für Publisher wird die Anzahl der Nachrichten oder Byte begrenzt, die ohne Antwort von der Veröffentlichungsanfrage ausstehend sein dürfen. Wenn Sie die Anzahl der Anfragen auf diese Weise begrenzen, bleibt die Ressourcenauslastung auch bei Spitzen auf einem akzeptablen Niveau. Je nach Art Ihres Publishers können Sie zulassen, dass nachfolgende Veröffentlichungs-RPCs auf Kapazität warten. Dazu können Sie zulassen, dass Veröffentlichungen weitere Anfragen blockieren. Alternativ können Sie sich an die Aufrufer Ihres Dienstes zurückweisen, indem Sie die Ablaufsteuerung einen Fehler zurückgeben lassen, wenn die Kapazität erreicht ist. Sie konfigurieren, wie die Publisher-Clientbibliothek mit dem Verhalten bei überschrittenem Limit reagiert.
Abonnenten werden abgestimmt
Möglicherweise müssen auch Abonnenten abgestimmt werden, damit sie zuverlässig funktionieren. Ähnlich wie bei Publishern können Sie die Einstellungen für die Ablaufsteuerung von Abonnenten anpassen, damit sie nicht überfordert werden. Die Abonnenten-Clientbibliothek verwendet Streaming-Pull, bei dem der Client einen nichtflüchtigen Stream zum Server öffnet und der Server Nachrichten sendet, sobald sie verfügbar sind. Bei einem starken Anstieg der veröffentlichten Nachrichten erhält der Abonnent möglicherweise mehr Nachrichten, als er verarbeiten kann. Mit der Ablaufsteuerung ist die Anzahl der nicht bestätigten Nachrichten, die gleichzeitig für den Client ausstehen, begrenzt. Dadurch wird die Anzahl der Nachrichten reduziert, die gleichzeitig verarbeitet werden, und ihre Verarbeitung wird über einen längeren Zeitraum aufgehoben. Durch das Verteilen des Lasten bleiben Abonnenten unter Ressourcenbeschränkungen, die sich auf die Nachrichtenverarbeitung auswirken. Dies kann zu einem Kaskadeneffekt führen, der dazu führt, dass Nachrichten nicht verarbeitet werden können.
Die Ablaufsteuerung allein ist ausreichend, wenn Sie nur mit Spitzen bei der zu verarbeitenden Datenmenge rechnen, die letztendlich zurückgehen. Steigt der Traffic im Allgemeinen aufgrund einer stärkeren Nutzung im Laufe der Zeit, schützt die Ablaufsteuerung die Abonnenten. Dies kann jedoch zu einem Rückstand führen, der sich weiter annimmt, und dazu führen, dass Nachrichten vor Ablauf der Nachrichtenaufbewahrungsdauer nicht zugestellt werden können. In solchen Fällen können Sie das Autoscaling auch so einstellen, dass mehr Abonnenten als Reaktion auf eine wachsende Anzahl nicht bestätigter Nachrichten freigeschaltet werden. Die Einrichtung hängt von der Computing-Plattform ab, die Sie für Ihre Abonnenten verwenden. Mit dem Autoscaling von Compute Engine können Sie beispielsweise auf der Grundlage von Messwerten wie der Anzahl der nicht zugestellten Nachrichten skalieren. Mit Autoscaling und Ablaufsteuerung können Sie dafür sorgen, dass Ihre Abonnenten anderen kurzfristigen Spitzen im Nachrichtendurchsatz sowie langfristigem Wachstum, das mehr Rechenleistung erfordert, resistent sind.
Sichere Deployments mithilfe von Snapshots und Suchen
Der Verlust von Nachrichten ist in der Regel eine katastrophale Situation. 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, sendet Pub/Sub sie nicht noch einmal. Daher kann ein Fehler in einem neuen Abonnentencode, der Nachrichten bestätigt, ohne sie korrekt verarbeitet zu, zu einem durch Abonnenten verursachten Verlust von Nachrichten führen. Pub/Sub bietet die Funktion Snapshot und Suche, mit der Sie dafür sorgen können, dass auch bei Abonnentenfehlern jede Nachricht korrekt verarbeitet wird.
Das Muster für jede Abonnentenbereitstellung muss so aussehen:
Die Wartezeit bis zur Ermittlung, ob der neue Abonnent funktioniert, kann je nach Anwendungsfall variieren. Die einzige Möglichkeit, den Ablauf der Schritte zu beenden, besteht darin, dass ein Abonnent als funktionierend eingestuft wird und der Snapshot dann gelöscht werden kann.
Die Verwendung von Snapshot und Suche ersetzt nicht die Best Practices für die erste Ausführung von Software in einer Nicht-Produktionsumgebung und die schrittweise Bereitstellung in der Produktion. Sie bieten ein zusätzliches Maß an Schutz und sorgen so für eine zuverlässige Datenverarbeitung. Allerdings kann die Suche nach dem Snapshot zu einer doppelten Zustellung von Nachrichten führen, die Ihr Abonnent erfolgreich verarbeitet hat. Da Pub/Sub jedoch standardmäßig eine Semantik für die mindestens einmalige Zustellung aufweist, sind Ihre Abonnenten bereits gegen eine erneute Zustellung von Nachrichten resistent.