Dieser Leitfaden bietet einen Überblick und einen Überblick über die Pub/Sub-Zuverlässigkeitsfeatures. In diesem Dokument werden folgende Themen behandelt:
- Vorteile von Pub/Sub
- Failover
- Publisher optimieren
- Abonnenten optimieren
- Sichere Bereitstellungen mit Snapshot und Suche
Vorteile von Pub/Sub
Als Messaging-Paradigma ist Publish/Subscribe so konzipiert, dass die Ersteller von Nachrichten von den Nutzern dieser Nachrichten entkoppelt werden. Anstatt direkte Anfragen mit den Daten an die Nutzer zu senden, veröffentlichen sie diese Daten in einem Pub/Sub-Dienst wie Pub/Sub. Der Dienst übermittelt diese Nachrichten asynchron an interessierte Nutzer, die ein Abo abgeschlossen haben.
Das Ergebnis ist, dass der Dienst alle Komplexitäten bei der Suche nach Nutzern absorbiert, die an den Daten interessiert sind. Der Dienst verwaltet auch die Rate, mit der die Nutzer die Daten basierend auf ihrer Kapazität erhalten. Durch die Entkopplung können Datenersteller Nachrichten in großem Umfang und mit niedriger Latenz schreiben, unabhängig vom Verhalten der Nutzer.
Pub/Sub bietet eine hoch skalierbare, zuverlässige Nachrichtenzustellung. Der Dienst erledigt einen Großteil dieser Aufgaben automatisch. Sie haben aber 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 diese Aspekte ausführlich beschrieben.
Failover
Pub/Sub ist ein globaler Dienst: Themen und Abos sind nicht an bestimmte Regionen gebunden und Nachrichten fließen innerhalb des Pub/Sub-Dienstes bei Bedarf zwischen Regionen. Wenn Sie den globalen Endpunkt pubsub.googleapis.com verwenden, stellen Publisher und Abonnenten eine Verbindung zu der Region her, die dem Netzwerk am nächsten liegt, 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 Cloudausführen, sollten Sie Standortendpunkte verwenden, damit Nachrichten konsistent zwischen den erwarteten Regionen gesendet werden. Im weiteren Verlauf dieses Abschnitts wird beschrieben, wie Sie Themen und Abos erstellen. Außerdem wird erläutert, wie Publisher und Abonnenten zur Unterstützung verschiedener Arten von Failover und Datenredundanz platziert werden.
Standard-Failover-Semantik
Stellen Sie sich einen Fall vor, bei dem es nur ein Thema und ein einzelnes Abo gibt. Publisher befinden sich in Regionen in den USA und in Australien, Abonnenten in den Regionen Google Cloud Europa und Australien. Wenn alle Abonnenten genügend Kapazität zum Empfangen von Nachrichten haben, 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 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 bevorzugt innerhalb 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ät haben. Daher werden, wie in der vorherigen Abbildung gezeigt, in den USA veröffentlichte Nachrichten an Abonnenten in Europa zugestellt, während in Australien 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ürzten häufig ab und konnten 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 verbunden sind, 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 festgelegt. Sie können auch die Nachrichtenaufbewahrung für ein Thema für bis zu 31 Tage konfigurieren. Wählen Sie keine Aufbewahrungsdauer aus, die kürzer ist als der maximale Ausfall, den Sie erwarten oder bereit sind zu tolerieren.
Pub/Sub ist in Europa nicht verfügbar
Auch wenn Pub/Sub selbst nicht verfügbar ist, kann es von Vorteil sein, wenn Pub/Sub nicht verfügbar ist. Die Nichtverfügbarkeit von Pub/Sub äußert sich als längere Zeiträume unerwarteter Fehler bei Veröffentlichungs- oder Aboanfragen oder die Unfähigkeit, veröffentlichte Nachrichten an Abonnenten zu senden. Wenn beispielsweise Pub/Sub in der Region in Europa ausgefallen ist, sieht das Szenario fast genauso aus wie bei einem Ausfall der Abonnenten:
Beachten Sie, dass die Abonnenten in Europa in diesem Fall kein Failover auf eine andere Region ausführen, selbst wenn sie den globalen Endpunkt verwenden. Pub/Sub führt absichtlich kein automatisches Failover aus. Stellen Sie sich vor, die Abonnenten selbst verursachen ein unerwartetes Problem in Pub/Sub, das zu Nichtverfügbarkeit führt. Ein solches Problem wird als schwerwiegender Ausfall gewertet. Die Auswirkungen des Ausfalls können 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önnten die Abonnenten auch dort nicht verfügbar sein, was zu einem kaskadierenden Ausfall im gesamten Dienst 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:
Schließlich werden alle Nachrichten von Abonnenten verarbeitet und bestätigt. Beim Senden von Nachrichten versucht Pub/Sub, die Netzwerkdistanz zu minimieren. Daher können die 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 zonaler Ausfall nicht aus, um die Zustellung von Nachrichten zu verhindern. Die gesamte Region muss nicht verfügbar sein. Wenn 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 ist:
Die Nachricht wird letztendlich weiterhin zugestellt (vorausgesetzt, die Nachrichtenaufbewahrungsdauer ist noch nicht abgelaufen), mit einer Verzögerung um die Dauer des Ausfalls. Ähnlich wie bei Abonnenten führen auch Publisher in den USA kein Failover auf eine andere Region durch, wenn der Dienst ausfällt. So lässt sich verhindern, dass Fehler aufgrund eines fehlerhaften Publishers oder Abonnenten regionsübergreifend auftreten.
Isolation
Die standardmäßige Failover-Semantik im Detail 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. Ihr Anwendungsfall erfordert möglicherweise verschiedene Isolationsebenen. Beispielsweise können Sie festlegen, dass alle Nachrichten intraregional zugestellt werden sollen.
Wenn Sie keine Isolation möchten, reicht die detaillierte Standard-Failover-Semantik aus. Sie müssen ein einzelnes Thema und ein Abo erstellen und Publisher und Abonnenten in allen ausgewählten Regionen platzieren. Wenn die Abonnenten nicht mehr verfügbar sind oder Pub/Sub sich in der Region befindet, zu der sie eine Verbindung herstellen, erfolgt die Zustellung per Failover an Abonnenten in einer anderen Region.
Erstellen Sie für die regionale Isolation, bei der Daten eine Region garantiert 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 bzw. das entsprechende regionale Thema veröffentlichen bzw. abonnieren. Außerdem müssen Sie regionale Endpunkte verwenden, damit Daten nur innerhalb der Region verschoben werden. Im Falle von Publisher-, Abonnenten- oder Pub/Sub-Ausfällen in einer einzelnen Region wird die Nachrichtenzustellung in dieser Region beendet. Nachrichten zu Themen und Abos für andere Regionen sind davon nicht betroffen.
Schließlich ist die zonale Isolation, bei der Daten garantiert in einer einzelnen Zone verbleiben, in Pub/Sub nicht möglich. Wenn einzelne Zonen unabhängig sein sollen, verwenden Sie Pub/Sub Lite.
Kundengesteuerter Failover und Redundanz
Die Standard-Failover-Semantik von Pub/Sub garantiert möglicherweise nicht vollständig, dass Nachrichten bei einem Ausfall irgendwo dazwischen nicht von Publishern zu Abonnenten gesendet werden können. Ausfälle können an verschiedenen Stellen auftreten, z. B. bei Ihren Kunden, im Dienst, in dem Ihre Publisher oder Abonnenten ausgeführt werden, im Netzwerk und sogar selten in Pub/Sub selbst. Wenn Ihre Dienste gegen solche Ausfälle resistent sein sollen, müssen Sie Ihre eigenen Redundanzen implementieren. In der Regel umfassen diese Redundanzen die Verwendung mehrerer Instanzen von Publisher- und Abonnentenclients, wobei jede einen anderen Standortendpunkt verwendet.
Möglicherweise möchten Sie die Ausfallsicherheit in Bezug auf zwei verschiedene Auswirkungen: zonal oder regional. Im Folgenden finden Sie die jeweiligen Einrichtungsoptionen.
Zonale Ausfallsicherheit
Pub/Sub verfügt über eine integrierte zonenübergreifende Replikation. Sie müssen keine besonderen Schritte unternehmen, um Ausfälle einzelner Zonen zu vermeiden, die sich auf den Dienst selbst auswirken. Um jedoch die Ausfallsicherheit für Ihre Kunden oder Ihr Netzwerk 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, damit bei Auftreten eines Fehlers die anderen, nicht bearbeiteten Zonen weiterhin Nachrichten verarbeiten können.
Regionale Ausfallsicherheit
Richten Sie zusätzliche Redundanzen in Ihren Publishern und Abonnenten ein, um regionalen Ausfällen standzuhalten. Sie können Publisher und Abonnenten in mehreren Regionen betreiben, um mögliche Ausfälle bei diesen Kunden 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, der für einen solchen Ausfall bereit ist. Die möglichen Ansätze stellen einen Kompromiss zwischen der Latenz der End-to-End-Nachrichtenzustellung und Ihren Kosten dar.
Wenn die Latenz minimiert werden soll, falls die Kosten keine Rolle spielen, ist es am besten, Inhalte gleichzeitig in verschiedenen Regionen zu veröffentlichen und zu abonnieren. Wählen Sie zunächst 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, auch wenn dies nicht unbedingt erforderlich ist.
Jeder Publisher erstellt so viele Publisher-Clients wie Regionen (eine für jede Region) vorhanden sind, und verwendet einen anderen Standortendpunkt, um sicherzustellen, dass Nachrichten an verschiedene Regionen weitergeleitet werden. Wenn Sie separate Themen verwenden, muss jeder Publisher-Client eine Veröffentlichung im entsprechenden regionsspezifischen Thema vornehmen. Der Publisher ruft für jede Nachricht „Publish“ auf jedem Client auf. Bei redundanten Veröffentlichungen müssen Veröffentlichungen nicht wiederholt werden, wenn eine einzelne fehlgeschlagen ist.
In ähnlicher 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. Die für Verlage und Abonnenten verwendeten Regionen müssen nicht unbedingt identisch sein. Abonnenten erhalten Nachrichten für die drei Abos und verarbeiten diese.
Diese Einrichtung umfasst mehrere wichtige Funktionen und Anforderungen:
- Ein Ausfall einer einzelnen Region wirkt sich nicht auf die Verarbeitung von bereits veröffentlichten Nachrichten oder Nachrichten aus, die während des Ausfalls veröffentlicht wurden. Da Nachrichten in mehreren Regionen veröffentlicht wurden, sind sie in anderen Regionen weiterhin verfügbar, falls eine Region ausgefallen ist. Während des Ausfalls schlagen Veröffentlichungsaufrufe in der betroffenen Region fehl, in den anderen Regionen jedoch erfolgreich.
- Die Latenz der Nachrichtenverarbeitung wird nicht beeinflusst, solange eine der Regionen verfügbar ist, durch die Nachrichten fließen.
- Die Nachrichtenverarbeitung muss idempotent sein. Da jede Nachricht mehrmals zugestellt wird, muss die Nachrichtenverarbeitung Duplikaten resistent sein. Bei einem regionalen Ausfall 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.
Die Ausführung mit dieser Art von Redundanz bietet die höchste Ausfallsicherheit bei allen Arten von Ausfällen. Diese Konfiguration wird für interne Google-Dienste bevorzugt, die auf Pub/Sub basieren und höchste Verfügbarkeit erfordern. Bei dieser Einrichtung müssen Sie jedoch die Kosten für die Nachrichtenzustellung mit der Anzahl der verwendeten Regionen multiplizieren. 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, ein Failover nur dann durchzuführen, wenn Anfragen fehlschlagen oder Nachrichten nicht wie erwartet von Publishern zu Abonnenten übertragen werden. In diesem Szenario haben Sie eine primäre Region, zu der Sie Ihre Publisher und Abonnenten über Standortendpunkte weiterleiten. Dabei muss es sich wie zuvor nicht um dieselbe Region handeln. 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 dann in der primären Region (über den geografischen Endpunkt), wenn ihre Anfragen erfolgreich gesendet wurden. Immer wenn die Region nicht verfügbar ist, veröffentlichen Verlage und Webpublisher ihre Inhalte stattdessen in der Fallback-Region. Es gibt zwei Möglichkeiten, festzustellen, ob die Region ausgefallen ist und ein Failover erfolgt. Dies kann manuell erfolgen und die Konfiguration wird in den Publishern dynamisch aktualisiert. Verlage und Webpublisher können die Konfiguration auch selbst aktualisieren, wenn die Fehlerrate in Veröffentlichungsanfragen ausreichend hoch ist.
Abonnenten müssen immer über den Standortendpunkt eine Verbindung zur primären Region herstellen. Sie können festlegen, dass 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 sowohl zur primären Region als auch zur Fallback-Region aufrecht. Für die primäre und die Fallback-Lösung können für Publisher und Abonnenten dieselben Regionen verwendet werden. In diesem Fall darf der Abonnent nur dann Nachrichten über die Sicherungsregion empfangen, wenn der Publisher ein Failover durchgeführt hat.
- Erkennen Sie die Abonnenten manuell und stellen Sie sie über eine Konfiguration in die Fallback-Region um. Wenn Sie einen Ausfall feststellen, können Sie ein Failover auf die Fallback-Region durchführen und dann zur primären Region zurückkehren, wenn der Ausfall nachgelassen hat.
- Failover bei Abonnentenfehlern. Wenn die Abonnentenanfragen Fehler zurückgeben, können Sie dies als Hinweis darauf verwenden, dass ein Failover auf die Fallback-Region erforderlich ist. Beachten Sie, dass die Pub/Sub-Clientbibliotheken Streaming-Pull-Anfragen bei vorübergehenden Fehlern intern wiederholen. Daher können Sie möglicherweise nicht erkennen, dass es lange unerwartete Fehler gibt. Darüber hinaus wird erwartet, dass die Streaming-Pull-Fehlerrate auch im normalen Betrieb bei 100 % liegt.
- Führen Sie ein Failover durch, wenn der Abonnent eine unerwartet lange Zeit ohne Nachrichten hat. Wenn die Nachrichten konsequent veröffentlicht werden, können die Abonnenten Nachrichten immer erhalten. Wenn sie über einen längeren Zeitraum hinweg keine Nachrichten empfangen, liegt möglicherweise ein Problem auf der Aboseite in Pub/Sub in der primären Region vor. Dieses Problem lässt sich durch einen Failover auf die Fallback-Region beheben.
Von allen vier Optionen ist die erste ideal. Eine Abonnentenverbindung ist kostenlos, wenn keine Nachrichten über sie gesendet werden. Die einzigen Kosten entstehen durch die zusätzliche Instanz der Abonnenten-Clientbibliothek, die vernachlässigbar sein können. Außerdem müssen Sie das Kontingent für die Anzahl der offenen Streaming-Pull-Verbindungen pro Region beachten.
Der Vorteil dieses zweiten Modells besteht darin, dass es keinen Multiplikator für die Pub/Sub-Kosten gibt, da Nachrichten nur einmal veröffentlicht werden. Allerdings sind bei bestimmten Ausfällen Nachrichten, die vor Beginn des Ausfalls veröffentlicht wurden, möglicherweise erst verfügbar, nachdem der Ausfall behoben wurde. Nachrichten, die in der nicht verfügbaren Region gespeichert sind, können möglicherweise nicht an Abonnenten gesendet 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 zu einer Phase der Nichtverfügbarkeit kommen, wodurch die Fehlerraten für die Verlage und Webpublisher oder die Abonnenten steigen. Dies hängt von der Methode ab, die zum Erkennen eines Ausfalls verwendet wird, und von der Zeit für das Failover in die Fallback-Region.
Unabhängig davon, welche Option Sie auswählen, sollten Sie wissen, wie diese mit Features von Pub/Sub interagieren kann. Sowohl bestellte Zustellung als auch genau einmalige Zustellung bieten Garantien innerhalb einer Region. Wenn Sie beispielsweise die Failover-Redundanztechnik verwenden, ist die Nachrichtenzustellung nur dann garantiert, wenn Nachrichten in derselben Region veröffentlicht werden. Der Abonnent kann Nachrichten empfangen, die in der Fallback-Region vor Nachrichten 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 von der ausgewählten Failover-Option gibt es einige zusätzliche Abstimmungsschritte, die Sie innerhalb der Publisher selbst ausführen möchten. Die Feinabstimmung des Publisher-Verhaltens gewährleistet eine optimale Leistung bei hoher Auslastung. Die Batchverarbeitung von Nachrichten ist eine Möglichkeit, einen Kompromiss zwischen Latenz und geringeren Kosten einzugehen. Allerdings stellt dies keinen großen Einfluss auf die Zuverlässigkeit und wird daher hier nicht behandelt. Konzentrieren Sie sich stattdessen auf einige der anderen Parameter, die für die Optimierung der Zuverlässigkeit nützlich sind, einschließlich Wiederholungseinstellungen und Einstellungen für die Ablaufsteuerung.
Veröffentlichungen können aus verschiedenen Gründen fehlschlagen, z. B. vorübergehend, wenn das Netzwerk nicht verfügbar ist oder die ein Eingreifen des Nutzers erfordern, z. B. Änderungen von Berechtigungen. Die Pub/Sub-Clientbibliothek wiederholt vorübergehende Fehler mithilfe der Parameter, die in den Wiederholungseinstellungen angegeben sind. Mit diesen Einstellungen wird das Verhalten des exponentiellen Backoffs bei Wiederholungen von Veröffentlichungs-RPCs festgelegt, die aus vorübergehenden Gründen fehlschlagen. Die Standardeinstellungen können in der Regel in den meisten Szenarien gut funktionieren. Es gibt jedoch Situationen, in denen Sie diese Werte möglicherweise anpassen möchten.
Die beiden Eigenschaften, die Sie am ehesten 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 zum Abschluss benötigt wird. Wenn ein RPC fehlschlägt oder eine Zeitüberschreitung auftritt, wird ein weiterer mit einem längeren Zeitlimit versucht, bis die Gesamtzahl der Anfragen oder das Gesamtzeitlimit überschritten wird.
Das anfängliche Zeitlimit kann angepasst werden, wenn der 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 Beschränkungen im Durchsatz der Maschine sein, auf der der Verlag oder Webpublisher ausgeführt wird, oder das Ergebnis anderer, netzwerkintensiver Dienste, die auf demselben Computer ausgeführt werden. Wenn das Zeitlimit zu kurz eingestellt ist, können anfängliche RPCs wiederholt fehlschlagen, wodurch mehr Versuche (mit längeren Zeitlimits) für eine erfolgreiche Veröffentlichung erforderlich sind. Die wiederholte Notwendigkeit von Wiederholungsversuchen 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 gesamten Zeitlimits sowie des anfänglichen Zeitlimits hilfreich sein. Ein erhöhtes Gesamtzeitlimit gibt dem Veröffentlichungs-RPC mehr Zeit für den erfolgreichen Abschluss. Wenn RPCs zur Veröffentlichung regelmäßig aufgrund von Fehlern aufgrund einer Überschreitung der Frist fehlschlagen, sollten Sie diese Werte optimieren.
Fehler bei der Veröffentlichung von Fristen können auch darauf hindeuten, dass die Ablaufsteuerung für Publisher angepasst werden sollte. Mit diesen Einstellungen können Sie dafür sorgen, dass Ihre Publisher Spitzen bei eingehendem Traffic, die zusätzliche Nachrichten erzeugen, die an Pub/Sub gesendet werden, nicht abwehren können. Ein starker Anstieg der ausgehenden Anfragen könnte die CPU-, Arbeitsspeicher- oder Netzwerkkapazität des Verlags oder Webpublishers überlasten. Wenn die Veröffentlichung überlastet ist, kann sie vor Ablauf der Zeitüberschreitungen keine Veröffentlichungsanfragen oder -antworten verarbeiten. Das führt zu noch mehr Veröffentlichungsanfragen und erreicht schließlich das Gesamtzeitlimit. Die Ablaufsteuerung des Publishers begrenzt die Anzahl der Nachrichten oder Byte, die ohne Antwort von der Veröffentlichungsanfrage ausstehend sein können. Wenn Sie die Anzahl der Anfragen auf diese Weise begrenzen, bleibt die Ressourcennutzung auf einem überschaubaren Niveau, selbst während Spitzen. Je nachdem, wie Ihr Publisher arbeitet, können Sie zulassen, dass nachfolgende Veröffentlichungs-RPCs auf Kapazität warten, indem Sie Veröffentlichungen erlauben, weitere Anfragen zu blockieren. Alternativ können Sie sich an die Aufrufer Ihres Dienstes wenden, indem Sie die Ablaufsteuerung einen Fehler zurückgeben lassen, wenn die Kapazität erreicht ist. Sie konfigurieren, wie die Publisher-Clientbibliothek mit dem Verhalten zum Überschreiten des Limits reagiert.
Abonnenten optimieren
Möglicherweise ist auch die Abonnentenabstimmung erforderlich, damit sie zuverlässig funktionieren. Ähnlich wie Verlage und Webpublisher kannst du die Einstellungen für die Ablaufsteuerung von Abonnenten optimieren, um sie nicht zu überfordern. Die Abonnenten-Clientbibliothek verwendet Streaming-Pull, wobei der Client einen nichtflüchtigen Stream für den 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 jeweils ausstehenden nicht bestätigten Nachrichten für den Client begrenzt. Dadurch wird die Anzahl der gleichzeitig verarbeiteten Nachrichten reduziert und ihre Verarbeitung wird über einen längeren Zeitraum ausgeweitet. Durch das Streuen der Last können Abonnenten Ressourcenbeschränkungen einhalten, 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 Flusssteuerung allein ist ausreichend, wenn Sie nur Spitzen in der zu verarbeitenden Datenmenge erwarten, die letztendlich zurückgehen. Wenn der Traffic aufgrund einer höheren Nutzung im Laufe der Zeit zunimmt, schützt die Ablaufsteuerung die Abonnenten. Dies kann jedoch zu einem Rückstand führen, der sich weiter anbaut und dazu führt, dass Nachrichten vor Ablauf der Nachrichtenaufbewahrungsdauer nicht mehr zugestellt werden können. In solchen Fällen sollten Sie das Autoscaling auch so einrichten, dass als Reaktion auf eine wachsende Anzahl nicht bestätigter Nachrichten mehr Abonnenten gewonnen 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 zum Beispiel basierend auf Messwerten wie der Anzahl der nicht zugestellten Nachrichten skalieren. Wenn Sie sowohl Autoscaling als auch Ablaufsteuerung verwenden, können Sie dafür sorgen, dass Ihre Abonnenten vor anderen kurzfristigen Spitzen im Nachrichtendurchsatz und längerfristigem Wachstum resistent sind, das mehr Rechenleistung erfordert. Folgen Sie den Best Practices für die Verwendung von Pub/Sub-Messwerten als Skalierungssignal.
Snapshot verwenden und nach sicheren Deployments suchen
Ein Nachrichtenverlust 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. Daher kann ein Fehler, der in neuen Abonnentencode auftritt, der Nachrichten bestätigt, ohne sie korrekt verarbeitet zu haben, zum Verlust von Nachrichten durch Abonnenten führen. Pub/Sub bietet die Funktion Snapshot und Suche, mit der Sie dafür sorgen können, dass jede Nachricht auch bei Abonnentenfehlern korrekt verarbeitet wird.
Das Muster für jede Abonnentenbereitstellung muss so aussehen:
Die Wartezeit bis zur Feststellung, 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 funktionsfähig erachtet wird. Dann kann der Snapshot gelöscht werden.
Die Verwendung von Snapshot und Seek ersetzt keine Best Practices für die erste Ausführung von Software in einer Nicht-Produktionsumgebung und die graduelle Bereitstellung in der Produktion. Sie bieten eine zusätzliche Schutzstufe, um die zuverlässige Verarbeitung von Daten zu gewährleisten. Allerdings kann es beim Suchen nach dem Snapshot dazu kommen, dass Nachrichten, die Ihr Abonnent erfolgreich verarbeitet hat, doppelt zugestellt werden. Da Pub/Sub jedoch standardmäßig eine Semantik für mindestens einmalige Zustellung hat, sind Ihre Abonnenten bereits für eine erneute Zustellung von Nachrichten gewappnet.