Dieser Leitfaden bietet ein Verständnis und einen Überblick über die Zuverlässigkeitsfunktionen von Pub/Sub.
Warum Pub/Sub?
Als Messaging-Paradigma ist „Publish/Subscribe“ darauf ausgelegt, die Ersteller von Nachrichten von den Nutzern dieser Nachrichten zu entkoppeln. Anstatt dass Ersteller direkte Anfragen mit den Daten an die Nutzer senden, veröffentlichen sie diese Daten in einem Pub/Sub-Dienst wie Pub/Sub. Der Dienst stellt diese Nachrichten asynchron an interessierte Nutzer zu, die sie abonniert haben.
Der Dienst übernimmt alle Feinheiten der Suche nach Nutzern, die an den Daten interessiert sind. Der Dienst verwaltet auch die Rate, mit der die Daten an die Nutzer gesendet werden, basierend auf ihrer Kapazität. Durch die Entkopplung können Datenproduzenten Nachrichten in großem Umfang mit niedriger Latenz schreiben, unabhängig vom Verhalten der Nutzer.
Pub/Sub bietet eine hoch skalierbare und zuverlässige Zustellung von Nachrichten. Der Dienst übernimmt zwar einen Großteil dieser Aufgaben automatisch, Sie haben aber die Kontrolle über verschiedene Aspekte Ihrer Publisher und Abonnenten, die sich auf die Verfügbarkeit und Leistung auswirken können. Im weiteren Verlauf dieses Leitfadens finden Sie einige Details zu diesen Aspekten.
Isolation
Standardmäßig ist Pub/Sub ein globaler Dienst: Themen und Abos sind nicht von Natur aus an bestimmte Regionen gebunden und Nachrichten werden bei Bedarf innerhalb des Pub/Sub-Dienstes zwischen Regionen übertragen. Bei Verwendung des globalen Endpunkts, pubsub.googleapis.com, stellen Publisher und Abonnenten eine Verbindung zur netzwerknahesten Region her, in der Pub/Sub ausgeführt wird. Wenn Sie die regionalen Endpunkte wie us-central1-pubsub.googleapis.com oder die Standortendpunkte wie pubsub.us-central1.rep.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 Cloud de Confianceausführen, sollten Sie regionale oder standortbezogene Endpunkte verwenden, um sicherzustellen, dass Nachrichten konsistent zwischen den erwarteten Regionen übertragen werden.
Regionale Isolation
So minimieren Sie die Infrastruktur, von der Veröffentlichungs- und Abonnementsvorgänge außerhalb einer einzelnen Region abhängen, und sorgen dafür, dass alle Daten auf diese Region beschränkt bleiben:
Erstellen Sie ein Thema pro Region.
Der Namespace von Pub/Sub ist global und Sie können Themen und Abos nicht an eine bestimmte Region binden. Metadaten für alle Ressourcen werden jedoch in lokale Datenspeicher innerhalb der Region repliziert. Nachdem Sie eine Ressource erstellt haben, ist ihre Konfiguration daher auch bei Problemen in einer anderen Region verfügbar. Bei einem Ausfall werden Aktualisierungen der Themen- oder Abo-Konfigurationen möglicherweise nicht sofort übernommen.
Vermeiden Sie die Verwendung globaler Endpunkte.
Verwenden Sie stattdessen regionale Endpunkte, sofern verfügbar, und Standortendpunkte, wenn keine regionalen Endpunkte verfügbar sind. Regionale Endpunkte bieten eine bessere regionale Isolation, sind aber noch nicht in allen Regionen verfügbar.
Verwenden Sie eine Richtlinie für die Speicherung von Nachrichten und legen Sie
enforceInTransitaufTruefest.Wenn Sie Enforce in transit (Bei der Übertragung erzwingen) aktivieren, verlassen Daten die Region nie und alle Clients, die sich in einer bestimmten Region mit dem Thema verbinden, legen die Richtlinie für die Nachrichtenspeicherung für diese Region fest.
Wenn Sie Themen auf diese Weise konfigurieren, können Sie sicher sein, dass bei allen Publish- und Subscribe-Vorgängen Daten ausschließlich in der Region geschrieben und gelesen werden. Bei Ausfällen von Publisher, Abonnent oder Pub/Sub in einer einzelnen Region wird die Nachrichtenzustellung in dieser Region beendet. Die Zustellung von Nachrichten zu Themen und Abonnements in anderen Regionen ist davon nicht betroffen.
Wenn Sie möchten, dass die administrativen Vorgänge und der Namespace Ihrer Themen und Abos ebenfalls regional isoliert sind, sollten Sie Managed Service for Apache Kafka verwenden.
Failover
Wenn Sie keine regionale Isolation benötigen, können Sie die Möglichkeit von Pub/Sub nutzen, Nachrichten effizient über mehrere Regionen hinweg zu senden, um Failover-Funktionen für mehrere Regionen zu erreichen. Im Rest dieses Abschnitts wird beschrieben, wie Sie Themen und Abos erstellen und 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. Verlage und Webpublisherinnen und ‑publisher haben ihren Sitz in Regionen der USA und Australiens und Abonnenten in den Cloud de Confiance Regionen Europas und Australiens. Wenn alle Abonnenten genügend Kapazität haben, um Nachrichten zu empfangen, sieht der Nachrichtenfluss so aus:
Die Ps stehen für Publisher, die Ss 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 im Netzwerk gesendet, die Abonnenten mit Kapazitäten hat. Wie im vorherigen Bild zu sehen ist, werden 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 in verschiedenen Fehlerszenarien passiert.
Abonnenten in Europa sind nicht verfügbar
Angenommen, Abonnenten in Europa wurden abgelehnt oder stürzten häufig ab und konnten keine Verbindung zu Pub/Sub aufrechterhalten. Wenn dies der Fall wäre, würde der Dienst Nachrichten an Abonnenten in Australien senden:
Abonnenten in Europa und Australien sind nicht verfügbar
Wenn alle Abonnenten nicht 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 beträgt die Aufbewahrungsdauer für Abonnachrichten 7 Tage. Sie können auch die Nachrichtenaufbewahrung für ein Thema für bis zu 31 Tage konfigurieren. Wählen Sie keine Aufbewahrungsdauer für Nachrichten aus, die kürzer ist als der maximale Ausfall, den Sie erwarten oder tolerieren möchten.
Pub/Sub ist in Europa nicht verfügbar
Obwohl selten, sollten Sie auch Fälle berücksichtigen, in denen Pub/Sub selbst nicht verfügbar ist. Die Nichtverfügbarkeit von Pub/Sub macht sich durch längere Zeiträume mit unerwarteten Fehlern bei Veröffentlichungs- oder Aboanfragen oder durch die Unfähigkeit, veröffentlichte Nachrichten an Abonnenten zu senden, bemerkbar. Wenn Pub/Sub beispielsweise in der Region in Europa nicht verfügbar wäre, sähe das Szenario ähnlich aus wie bei nicht verfügbaren Abonnenten:
In diesem Fall werden Abonnenten in Europa nicht auf eine andere Region umgeleitet, auch wenn sie den globalen Endpunkt verwenden. Bei Pub/Sub erfolgt kein automatisches Failover. Stellen Sie sich vor, dass die Abonnenten selbst ein unerwartetes Problem in Pub/Sub verursachen, das zu einer Nichtverfügbarkeit führt. Ein solches Problem wird als schwerwiegender Ausfall behandelt. 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önnen die Abonnenten auch dort zu einer Nichtverfügbarkeit führen, was zu einem kaskadierenden Fehler 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 den Abonnenten genutzt und bestätigt. Beim Senden von Nachrichten versucht Pub/Sub, die Netzwerkentfernung zu minimieren. Daher können Abonnenten in Australien keine Nachrichten mehr erhalten, wenn 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. Ein zonales Problem reicht daher 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 zugestellt (vorausgesetzt, die Aufbewahrungsdauer für Nachrichten ist noch nicht abgelaufen), jedoch mit einer Verzögerung, die der Dauer des Ausfalls entspricht. Ähnlich wie bei Abonnenten erfolgt bei Publishern in den USA kein Failover zu einer anderen Region, wenn der Dienst ausfällt. So wird die Wahrscheinlichkeit von kaskadierenden Fehlern in verschiedenen Regionen aufgrund eines fehlerhaften Publishers oder Abonnenten verringert.
Vom Kunden gesteuerte Failover und Redundanz
Die standardmäßige Failover-Semantik von Pub/Sub garantiert möglicherweise nicht vollständig, dass Nachrichten immer von Publishern zu Abonnenten übertragen werden können, wenn es irgendwo dazwischen zu einem Ausfall kommt. Ausfälle können an verschiedenen Stellen auftreten, z. B. bei Ihren Clients, im Dienst, auf dem Ihre Publisher oder Abonnenten ausgeführt werden, im Netzwerk oder selten auch in Pub/Sub selbst. Wenn Ihre Dienste gegen solche Ausfälle geschützt sein sollen, müssen Sie eigene Redundanzen implementieren. In der Regel umfassen diese Redundanzen die Verwendung mehrerer Instanzen von Publisher- und Subscriber-Clients, die jeweils einen anderen Standortendpunkt verwenden.
Sie benötigen möglicherweise Resilienz für zwei verschiedene Arten von Auswirkungen: zonal oder regional. Hier finden Sie die Einrichtungsoptionen für die einzelnen Produkte.
Zonale Ausfallsicherheit
Pub/Sub bietet eine integrierte zonenübergreifende Replikation. Sie müssen keine besonderen Maßnahmen ergreifen, um mit Ausfällen in einzelnen Zonen umzugehen, die sich auf den Dienst selbst auswirken. Um jedoch Ausfälle bei Ihren Clients oder Ihrem Netzwerk zu vermeiden, sollten Sie Publisher und Abonnenten mit ausreichender Kapazität in mehreren Zonen innerhalb der Region ausführen. Wenn eine einzelne Zone ausfällt, können die Clients in der anderen Zone den Traffic aufnehmen und die Nachrichten verarbeiten. Es empfiehlt sich, Änderungen an diesen Clients nicht gleichzeitig zu veröffentlichen. So können die anderen, unveränderten Zonen weiterhin Nachrichten verarbeiten, falls ein Fehler auftritt.
Regionale Ausfallsicherheit
Um vor regionalen Ausfällen geschützt zu sein, sollten Sie zusätzliche Redundanzen für Ihre Publisher und Abonnenten einrichten. Sie können Publisher und Abonnenten in mehreren Regionen ausführen, um die Möglichkeit von Ausfällen bei diesen Clients oder im Netzwerk zu berücksichtigen.
Wenn Sie Ausfallsicherheit bei potenziellen Pub/Sub-Fehlern in einer Region benötigen, müssen Sie einen Failover-Mechanismus bereithalten, um mit einem solchen Ausfall umzugehen. Die möglichen Ansätze sind ein Kompromiss zwischen der End-to-End-Latenz der Nachrichtenübermittlung und Ihren Kosten.
Wenn die Latenz minimiert werden soll und die Kosten keine Rolle spielen, ist es am besten, immer gleichzeitig in verschiedenen Regionen zu veröffentlichen und zu abonnieren. Wählen Sie zuerst die Anzahl der Regionen aus, in denen Sie Redundanz wünschen. Als Nächstes können Sie, obwohl dies nicht unbedingt erforderlich ist, ein Thema und ein Abo für jede dieser Regionen einrichten.
Jeder Publisher erstellt so viele Publisher-Clients wie es Regionen gibt (einen für jede Region) und verwendet einen anderen Standortendpunkt, um sicherzustellen, dass Nachrichten an unterschiedliche Regionen gesendet werden. Wenn Sie separate Themen verwenden, muss jeder Publisher-Client im entsprechenden regionalen Thema veröffentlichen. Für jede Nachricht ruft der Publisher „publish“ für jeden Client auf. Da die Veröffentlichungen redundant sind, müssen Sie sie nicht noch einmal versuchen, wenn eine fehlschlägt.
Ebenso erstellt jeder Abonnent so viele Abonnentenclients wie Regionen 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 nutzen. Die Regionen für Publisher und Abonnenten müssen nicht unbedingt identisch sein. Abonnenten empfangen Nachrichten über die drei Abos und verarbeiten sie.
Diese Einrichtung hat mehrere wichtige Funktionen und Anforderungen:
- Ein Ausfall in einer einzelnen Region hat keine Auswirkungen auf die Verarbeitung von Nachrichten, die bereits veröffentlicht wurden oder während des Ausfalls veröffentlicht werden. Da Nachrichten in mehreren Regionen veröffentlicht wurden, sind sie weiterhin in anderen Regionen verfügbar, falls eine Region ausfällt. Während des Ausfalls schlagen Veröffentlichungsaufrufe in der betroffenen Region fehl, in den anderen Regionen jedoch nicht.
- Die Latenz bei der Nachrichtenverarbeitung ist nicht betroffen, solange eine der Regionen, durch die Nachrichten fließen, verfügbar ist.
- Die Nachrichtenverarbeitung muss idempotent sein. Da jede Nachricht mehrmals zugestellt wird, muss die Nachrichtenverarbeitung gegen Duplikate geschützt sein. Bei einem regionalen Ausfall können einige dieser Duplikate viel später als bei der ersten Zustellung der Nachricht eintreffen. Diese Duplikate stammen wahrscheinlich aus einer anderen Region, in der es keinen Ausfall gab.
Diese Art von Redundanz bietet die höchste Ausfallsicherheit. Für interne Google-Dienste, die auf Pub/Sub basieren und höchste Verfügbarkeit erfordern, ist diese Einrichtung die bevorzugte Option. Diese Einrichtung hat jedoch den Nachteil, dass die Kosten für die Zustellung von Nachrichten mit der Anzahl der verwendeten Regionen multipliziert werden. Außerdem fallen zusätzliche Kosten für die regionsübergreifende Netzwerknutzung für Nachrichten an, die zwischen Regionen übertragen werden müssen.
Ein anderer Ansatz für die 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, in die Sie Ihre Publisher und Abonnenten über standortbezogene Endpunkte weiterleiten. Wie zuvor müssen diese nicht in derselben Region sein. 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 in der primären Region (über den Standortendpunkt), wenn ihre Anfragen erfolgreich gesendet werden. Wenn die Region als nicht verfügbar eingestuft wird, veröffentlichen Publisher stattdessen in der Fallback-Region. Es gibt zwei Möglichkeiten, um festzustellen, dass die Region nicht verfügbar ist und ein Failover durchgeführt werden muss. Das kann manuell erfolgen und die Konfiguration wird dynamisch bei den Verlagen und Webpublishern aktualisiert. Publisher können die Konfiguration auch selbst aktualisieren, wenn die Fehlerrate bei Veröffentlichungsanfragen hoch genug 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:
- Abonniere immer die Fallback-Region. In diesem Fall hat der Abonnent jederzeit eine Verbindung sowohl zur primären Region als auch zur Fallback-Region. Sowohl Publisher als auch Abonnenten können für das primäre und das Fallback-Ziel dieselben Regionen verwenden. In diesem Fall darf der Abonnent Nachrichten nur über die Sicherungsregion empfangen, wenn der Publisher ein Failover durchgeführt hat.
- Abonnenten manuell erkennen und über eine Konfiguration zur Fallback-Region wechseln. Wenn Sie einen Ausfall erkennen, können Sie ein Failover zur Fallback-Region durchführen und dann zur primären Region zurückkehren, wenn der Ausfall behoben ist.
- Failover bei Abonnentenfehlern Wenn bei Abonnentenanfragen Fehler zurückgegeben werden, kann dies ein Hinweis darauf sein, dass Sie ein Failover zur Fallback-Region durchführen müssen. Die Pub/Sub-Clientbibliotheken versuchen, Streaming-Pull-Anfragen bei vorübergehenden Fehlern intern noch einmal zu senden. Daher können Sie möglicherweise nicht erkennen, ob es lange Phasen unerwarteter Fehler gibt. Außerdem wird erwartet, dass die Fehlerrate für StreamingPull auch im Normalbetrieb 100 % beträgt.
- Failover, wenn der Abonnent über einen unerwartet langen Zeitraum keine Nachrichten empfängt. Bei einer konsistenten Veröffentlichung von Nachrichten können Abonnenten immer Nachrichten empfangen. Wenn sie über einen längeren Zeitraum keine Nachrichten empfangen, liegt möglicherweise ein Problem auf der Abonnentenseite in Pub/Sub in der primären Region vor. Dieses Problem wird durch ein Failover auf die Fallback-Region behoben.
Von allen vier Optionen ist die erste ideal. Eine Abonnentenverbindung kostet nichts, wenn keine Nachrichten darüber gesendet werden. Die einzigen Kosten entstehen durch die zusätzliche Instanz der Abonnenten-Clientbibliothek, die jedoch vernachlässigbar sein können. Sie müssen auch das Kontingent für die Anzahl der offenen StreamingPull-Verbindungen pro Region im Blick behalten.
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. Der Nachteil ist jedoch, dass Nachrichten, die vor Beginn bestimmter Arten von Ausfällen veröffentlicht wurden, möglicherweise erst nach Behebung des Ausfalls verfügbar sind. Nachrichten, die in der nicht verfügbaren Region gespeichert sind, können möglicherweise nicht an Abonnenten gesendet werden, unabhängig davon, wo sie sich befinden. Nachrichten, die während des Ausfalls in der Fallback-Region veröffentlicht wurden, sind möglicherweise verfügbar. Außerdem kann es zu einer vorübergehenden Nichtverfügbarkeit mit erhöhten Fehlerraten für die Publisher oder die Abonnenten kommen. Das hängt von der Methode ab, mit der ein Ausfall erkannt wird, und von der Zeit, die für das Failover zur Fallback-Region benötigt wird.
Unabhängig davon, welche Option Sie auswählen, sollten Sie sich darüber im Klaren sein, wie sich dies auf die Funktionen von Pub/Sub auswirken kann. Sowohl die geordnete Zustellung als auch die genau einmalige Zustellung bieten ihre Garantien innerhalb einer Region. Wenn Sie beispielsweise die Failover-Redundanz verwenden, wird die Nachrichtenzustellung nur für Nachrichten garantiert, die in derselben Region veröffentlicht wurden. Der Abonnent kann Nachrichten, die in der Fallback-Region veröffentlicht wurden, vor Nachrichten empfangen, die in der primären Region veröffentlicht wurden, auch wenn die Nachrichten zuerst in der primären Region veröffentlicht wurden.
Publisher feinabstimmen
Unabhängig davon, welche Failover-Option Sie auswählen, sind einige zusätzliche Anpassungsschritte erforderlich. Durch die Optimierung des Publisher-Verhaltens wird eine optimale Leistung bei hoher Last sichergestellt. Nachrichten in Batches zusammenfassen ist eine Möglichkeit, die Latenz zu verringern und gleichzeitig Kosten zu sparen. Da dies jedoch nicht so sehr ein Zuverlässigkeitsproblem ist, wird es hier nicht behandelt. Konzentrieren Sie sich stattdessen auf einige der anderen Parameter, die für die Zuverlässigkeit nützlich sind, einschließlich der Einstellungen für Wiederholungsversuche und der Einstellungen für die Ablaufsteuerung.
Die Veröffentlichung kann aus verschiedenen Gründen fehlschlagen, z. B. aufgrund vorübergehender Probleme wie einer nicht verfügbaren Netzwerkverbindung oder aufgrund von Problemen, die eine Nutzeraktion erfordern, z. B. Änderungen an Berechtigungen. Die Pub/Sub-Clientbibliothek wiederholt vorübergehende Fehler mit den in den Wiederholungseinstellungen angegebenen Parametern. Mit diesen Einstellungen wird das Verhalten des exponentiellen Backoff 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 Properties, die Sie am wahrscheinlichsten optimieren möchten, sind das anfängliche RPC-Zeitlimit und das gesamte Zeitlimit. Die anfängliche RPC-Zeitüberschreitung gibt an, wie lange die erste Publish-RPC Zeit hat, um abgeschlossen zu werden. Wenn ein RPC fehlschlägt oder das Zeitlimit überschritten wird, wird ein weiterer RPC mit einem längeren Zeitlimit versucht, bis die Gesamtzahl der Anfragen oder das Gesamttimeout überschritten wird.
Das anfängliche Zeitlimit kann angepasst werden, wenn der Publisher durch das Netzwerk eingeschränkt ist oder sich weit entfernt vom nächsten Cloud de Confiance by S3NS -Rechenzentrum befindet, in dem Pub/Sub ausgeführt wird. Netzwerkbeschränkungen können Einschränkungen des Durchsatzes der Maschine sein, auf der der Publisher ausgeführt wird, oder das Ergebnis anderer Dienste, die auf derselben Maschine ausgeführt werden und netzwerkintensiv sind. Wenn das Zeitlimit zu kurz ist, können anfängliche RPCs wiederholt fehlschlagen, sodass mehr Versuche (mit längeren Zeitlimits) erforderlich sind, um die Veröffentlichung erfolgreich abzuschließen. Die wiederholte Notwendigkeit von Wiederholungsversuchen erhöht die Latenz bei der Veröffentlichung. In diesem Fall kann eine Erhöhung des anfänglichen Zeitlimits zu schnelleren Veröffentlichungen führen.
Wenn die Netzwerkverbindung unzuverlässig ist, kann es helfen, das gesamte Zeitlimit und das anfängliche Zeitlimit zu erhöhen. Durch ein erhöhtes Gesamttimeout hat der Publish-RPC mehr Zeit, um erfolgreich abgeschlossen zu werden. Wenn Publish-RPCs immer wieder mit Zeitüberschreitungsfehlern fehlschlagen, sollten Sie diese Werte anpassen.
Wenn beim Veröffentlichen immer wieder Fehler aufgrund überschrittener Fristen auftreten, müssen Sie möglicherweise die Ablaufsteuerung für Publisher anpassen. Mit diesen Einstellungen können Sie dafür sorgen, dass Ihre Publisher auch bei Spitzen des eingehenden Traffics, die zu mehr Nachrichten führen, die an Pub/Sub gesendet werden müssen, stabil bleiben. Ein starker Anstieg der ausgehenden Anfragen kann die CPU, den Arbeitsspeicher oder die Netzwerkkapazität des Publishers überlasten. Wenn der Publish-Vorgang überlastet ist, können Publish-Anfragen oder -Antworten nicht vor den Zeitüberschreitungen verarbeitet werden. Das führt zu noch mehr Veröffentlichungsanfragen und schließlich zum Erreichen des gesamten Zeitlimits. Die Publisher-Ablaufsteuerung begrenzt die Anzahl der Nachrichten oder Bytes, die ohne Antwort auf die Veröffentlichungsanfrage ausstehen können. Durch die Begrenzung der Anzahl der Anfragen wird die Ressourcennutzung auf einem überschaubaren Niveau gehalten, auch bei Spitzen. Je nachdem, wie Ihr Publisher funktioniert, können Sie zulassen, dass nachfolgende Publish-RPCs auf Kapazität warten, indem Sie zulassen, dass Publish weitere Anfragen blockiert. Alternativ können Sie die Aufrufer Ihres Dienstes zurückweisen, indem Sie durch die Ablaufsteuerung einen Fehler zurückgeben lassen, wenn die Kapazität erreicht ist. Sie konfigurieren, wie die Publisher-Clientbibliothek auf das Überschreiten des Limits reagiert.
Abonnenten feinabstimmen
Möglicherweise müssen sie auch vom Abonnenten angepasst 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 persistenten Stream zum Server öffnet und der Server Nachrichten sendet, sobald sie verfügbar sind. Bei einer starken Zunahme der veröffentlichten Nachrichten kann der Abonnent mehr Nachrichten erhalten, als er verarbeiten kann. Durch die Ablaufsteuerung wird die Anzahl der unbestätigten Nachrichten, die für den Client zu einem bestimmten Zeitpunkt ausstehen, begrenzt. Dadurch wird die Anzahl der gleichzeitig verarbeiteten Nachrichten reduziert und die Verarbeitung über einen längeren Zeitraum verteilt. Durch die Verteilung der Last können Abonnenten die Ressourcenbeschränkungen einhalten, die sich auf die Nachrichtenverarbeitung auswirken. Andernfalls kann es zu einem Kaskadeneffekt kommen, der dazu führt, dass keine Nachrichten mehr verarbeitet werden können.
Die Ablaufsteuerung allein reicht aus, wenn Sie nur mit vorübergehenden Spitzen bei der zu verarbeitenden Datenmenge rechnen. Wenn der Traffic im Laufe der Zeit aufgrund einer höheren Nutzung zunimmt, schützt die Ablaufsteuerung die Abonnenten. Dies kann jedoch zu einem Rückstand führen, der sich immer weiter aufbaut und dazu führt, dass Nachrichten nicht zugestellt werden können, bevor die Aufbewahrungsdauer für Nachrichten abläuft. In solchen Fällen kann es auch sinnvoll sein, das Autoscaling so einzustellen, dass mehr Abonnenten hinzugefügt werden, wenn die Anzahl der nicht bestätigten Nachrichten steigt. Wie Sie das einrichten, hängt von der Compute-Plattform ab, die Sie für Ihre Abonnenten verwenden. Mit dem Autoscaler von Compute Engine können Sie beispielsweise basierend auf Messwerten wie der Anzahl der nicht zugestellten Nachrichten skalieren. Durch die Verwendung von Autoscaling und Flusssteuerung können Sie sicherstellen, dass Ihre Abonnenten auch bei kurzfristigen Spitzen im Nachrichtendurchsatz und bei langfristigem Wachstum, das mehr Rechenleistung erfordert, stabil bleiben. Best Practices für die Verwendung von Pub/Sub-Messwerten als Skalierungssignal
Regionale Versionen von Backlog-Messwerten anstelle von globalen Versionen verwenden
Wenn Sie Ihren Abo-Rückstand überwachen, Benachrichtigungsrichtlinien konfigurieren oder Abonnenten automatisch skalieren, bietet Pub/Sub zwei Versionen jedes Rückstandsmesswerts. Achten Sie darauf, dass Sie die Versionen mit dem Suffix by_region verwenden:
Verwenden Sie nicht die globalen Versionen dieser Messwerte (subscription/num_undelivered_messages und subscription/oldest_unacked_message_age), wenn Ihr Monitoring, Ihre Benachrichtigungen und Ihr Autoscaling gegen Ausfälle in einzelnen Regionen geschützt sein sollen. Für die globalen Versionen dieser Messwerte muss der Rückstand in allen Regionen berechnet werden, in denen Nachrichten vorhanden sind. Das bedeutet, dass eine Nichtverfügbarkeit in einer einzelnen Region zu einer Datenlücke führt. Bei den by_region-Versionen der Messwerte wird der Rückstand dagegen auf regionaler Basis berechnet und gemeldet. Wenn der Backlog für eine einzelne Region nicht berechnet werden kann, werden für die anderen Regionen trotzdem Werte für den Messwert ausgegeben.
Snapshot und Seek für sichere Bereitstellungen verwenden
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 werden, werden sie von Pub/Sub nicht noch einmal zugestellt. Ein Fehler im neuen Abonnentencode, den Sie bereitstellen, der Nachrichten bestätigt, ohne sie richtig verarbeitet zu haben, kann daher zu einem durch Abonnenten verursachten Nachrichtenverlust führen. Pub/Sub bietet das Feature Snapshot und Seek, mit dem Sie dafür sorgen können, dass jede Nachricht korrekt verarbeitet wird, auch wenn Abonnentenfehler auftreten.
Das Muster für jede Abonnentenbereitstellung muss so aussehen:
Die Wartezeit, bevor Sie feststellen, ob der neue Abonnent funktioniert, kann je nach Anwendungsfall variieren. Der einzige Weg, den Ablauf von Schritten zu beenden, ist, wenn ein Abonnent als aktiv eingestuft wird. Dann kann der Snapshot gelöscht werden.
Die Verwendung von Snapshot und Seek soll nicht die Best Practices ersetzen, Software zuerst in einer Nicht-Produktionsumgebung auszuführen und sie dann schrittweise in der Produktion bereitzustellen. Sie bieten eine zusätzliche Schutzebene, um die zuverlässige Verarbeitung von Daten zu gewährleisten. Der Nachteil ist, dass das Suchen nach dem Snapshot dazu führen kann, dass Nachrichten, die Ihr Abonnent erfolgreich verarbeitet hat, doppelt zugestellt werden. Da Pub/Sub jedoch standardmäßig die „Mindestens einmal“-Zustellung unterstützt, sind Ihre Abonnenten bereits vor der erneuten Zustellung von Nachrichten geschützt.