Die Nachrichtenreihenfolge ist ein Feature in Pub/Sub, mit dem Sie Nachrichten in Ihren Abonnentenclients in der Reihenfolge empfangen können, in der sie von den Publisher-Clients veröffentlicht wurden.
Angenommen, ein Publisher-Client in einer Region veröffentlicht die Nachrichten 1, 2 und 3 in dieser Reihenfolge. Mit der Nachrichtenreihenfolge empfängt der Abonnentenclient die veröffentlichten Nachrichten in derselben Reihenfolge. Damit die Nachrichten in der richtigen Reihenfolge zugestellt werden, muss der Publisher Client sie in derselben Region veröffentlichen. Abonnenten können jedoch eine Verbindung zu jeder Region herstellen und die Reihenfolge wird trotzdem beibehalten.
Die Nachrichtenreihenfolge ist ein nützliches Feature für Szenarien wie die Erfassung von Datenbankänderungen, die Verfolgung von Nutzersitzungen und Streaminganwendungen, bei denen die Chronologie von Ereignissen wichtig ist.
Auf dieser Seite wird das Konzept der Nachrichtenreihenfolge erläutert und beschrieben, wie Sie Ihre Abonnentenclients so einrichten, dass sie Nachrichten in der richtigen Reihenfolge empfangen. Informationen zum Konfigurieren Ihrer Publisher Clients für die Nachrichtenreihenfolge finden Sie unter Sortierungsschlüssel verwenden, um eine Nachricht zu veröffentlichen.
Übersicht über die Nachrichtenreihenfolge
Die Reihenfolge in Pub/Sub wird durch Folgendes bestimmt:
Sortierungsschlüssel. Ein Sortierungsschlüssel ist ein String, der zusammengehörige Nachrichten identifiziert, die sortiert werden sollen. Beispiele für Sortierungsschlüssel sind Kunden-IDs oder der Primärschlüssel einer Zeile in einer Datenbank. Ein Sortierungsschlüssel kann bis zu 1 KB lang sein.
Um die Nachrichtenreihenfolge zu erreichen, legen Sie für alle zusammengehörigen Nachrichten, die in der richtigen Reihenfolge empfangen werden sollen, denselben Sortierungsschlüssel fest. Außerdem müssen Sie alle Nachrichten mit demselben Sortierungsschlüssel in derselben Region veröffentlichen. Weitere Informationen finden Sie unter Sortierungsschlüssel verwenden, um eine Nachricht zu veröffentlichen.
Nachrichten mit einem leeren Sortierungsschlüssel werden nicht sortiert.
Nachrichtenreihenfolge aktivieren. Damit Nachrichten in der richtigen Reihenfolge empfangen werden, müssen Sie die Nachrichtenreihenfolge im Abo aktivieren. Weitere Informationen finden Sie unter Nachrichtenreihenfolge aktivieren.
Wenn die Nachrichtenreihenfolge nicht aktiviert ist, empfängt ein Abo Nachrichten ohne erwartete Reihenfolge. Angenommen, die Abos A und B sind beide mit demselben Thema T verknüpft und die Reihenfolge ist in Abo A aktiviert, aber nicht in Abo B. Obwohl beide Abos dieselben Nachrichten von Thema T empfangen, wird die Reihenfolge nur für Abo A beibehalten.
Der Veröffentlichungsdurchsatz für jeden Sortierungsschlüssel ist auf 1 MB/s begrenzt. Der Durchsatz für alle Sortierungsschlüssel eines Themas ist auf das in einer Veröffentlichungsregionverfügbare Kontingent begrenzt. Dieses Limit kann auf mehrere GB/s erhöht werden.
Wenn Ihre Lösung erfordert, dass Publisher-Clients sowohl sortierte als auch unsortierte Nachrichten senden, erstellen Sie separate Themen, eines für sortierte und eines für unsortierte Nachrichten.
Überlegungen bei der Verwendung von sortierten Nachrichten
Die folgende Liste enthält wichtige Informationen zum Verhalten von sortierten Nachrichten in Pub/Sub:
Kardinalität. Ein Sortierungsschlüssel entspricht nicht einer Partition in einem partitionsbasierten Messaging-System, da Sortierungsschlüssel eine viel höhere Kardinalität als Partitionen haben.
Reihenfolge innerhalb eines Schlüssels: Nachrichten, die mit demselben Sortierungsschlüssel veröffentlicht werden, sollten in der richtigen Reihenfolge empfangen werden. Angenommen, Sie veröffentlichen für den Sortierungsschlüssel A die Nachrichten 1, 2 und 3. Wenn die Reihenfolge aktiviert ist, wird Nachricht 1 vor Nachricht 2 und Nachricht 2 vor Nachricht 3 zugestellt.
Reihenfolge über mehrere Schlüssel hinweg: Nachrichten, die mit unterschiedlichen Sortierungsschlüsseln veröffentlicht werden, werden nicht in der richtigen Reihenfolge empfangen. Angenommen, Sie haben die Sortierungsschlüssel A und B. Für den Sortierungsschlüssel A werden die Nachrichten 1 und 2 in der richtigen Reihenfolge veröffentlicht. Für den Sortierungsschlüssel B werden die Nachrichten 3 und 4 in der richtigen Reihenfolge veröffentlicht. Nachricht 1 kann jedoch vor oder nach Nachricht 4 eintreffen.
Nachricht noch einmal senden: Pub/Sub sendet jede Nachricht mindestens einmal, sodass der Pub/Sub-Dienst Nachrichten möglicherweise wiederholt sendet. Wenn eine Nachricht noch einmal gesendet wird, werden auch alle nachfolgenden Nachrichten für diesen Schlüssel noch einmal gesendet, auch die bestätigten. Angenommen, ein Abonnentenclient empfängt die Nachrichten 1, 2 und 3 für einen bestimmten Sortierungsschlüssel. Wenn Nachricht 2 noch einmal gesendet wird (weil die Bestätigungsfrist abgelaufen ist oder die Best-Effort-Bestätigung in Pub/Sub nicht beibehalten wurde), wird auch Nachricht 3 noch einmal gesendet. Wenn sowohl die Nachrichtenreihenfolge als auch ein Thema für unzustellbare Nachrichten für ein Abo aktiviert sind, ist dies möglicherweise nicht der Fall, da Pub/Sub Nachrichten an Themen für unzustellbare Nachrichten auf Best-Effort-Basis weiterleitet.
Verzögerungen bei der Bestätigung und Themen für unzustellbare Nachrichten: Nicht bestätigte Nachrichten für einen bestimmten Sortierungsschlüssel können die Zustellung von Nachrichten für andere Sortierungsschlüssel verzögern, insbesondere bei Serverneustarts oder Änderungen im Traffic. Um die Reihenfolge bei solchen Ereignissen beizubehalten, müssen alle Nachrichten rechtzeitig bestätigt werden. Wenn eine rechtzeitige Bestätigung nicht möglich ist, sollten Sie ein Thema für unzustellbare Nachrichten verwenden, um zu verhindern, dass Nachrichten unbegrenzt lange aufbewahrt werden. Beachten Sie, dass die Reihenfolge möglicherweise nicht beibehalten wird, wenn Nachrichten in ein Thema für unzustellbare Nachrichten geschrieben werden.
Nachrichtenaffinität (StreamingPull-Clients): Nachrichten für denselben Schlüssel werden in der Regel an denselben StreamingPull-Abonnentenclient gesendet. Affinität wird erwartet, wenn Nachrichten für einen Sortierungsschlüssel für einen bestimmten Abonnentenclient ausstehen. Wenn keine ausstehenden Nachrichten vorhanden sind, kann sich die Affinität aus Gründen des Load-Balancings oder bei Clientverbindungsabbrüchen ändern.
Um eine reibungslose Verarbeitung auch bei potenziellen Änderungen der Affinität zu gewährleisten, ist es wichtig, Ihre StreamingPull-Anwendung so zu gestalten, dass sie Nachrichten in jedem Client für einen bestimmten Sortierungsschlüssel verarbeiten kann.
Integration mit Dataflow: Aktivieren Sie die Nachrichtenreihenfolge nicht für Abos, wenn Sie Dataflow mit Pub/Sub konfigurieren. Dataflow hat einen eigenen Mechanismus für die vollständige Nachrichtenreihenfolge, der die chronologische Reihenfolge aller Nachrichten im Rahmen von Windowing-Vorgängen gewährleistet. Diese Methode der Reihenfolge unterscheidet sich vom auf Sortierungsschlüsseln basierenden Ansatz von Pub/Sub. Die Verwendung von Sortierungsschlüsseln mit Dataflow kann die Leistung der Pipeline beeinträchtigen.
Automatische Skalierung: Die sortierte Zustellung von Pub/Sub lässt sich auf Milliarden von Sortierungsschlüsseln skalieren. Eine größere Anzahl von Sortierungsschlüsseln ermöglicht eine parallele Zustellung an mehr Abonnenten, da die Reihenfolge für alle Nachrichten mit demselben Sortierungsschlüssel gilt.
Kompromisse bei der Leistung: Die sortierte Zustellung bringt einige Kompromisse mit sich. Im Vergleich zur unsortierten Zustellung verringert die sortierte Zustellung die Veröffentlichungsverfügbarkeit und erhöht die End-to-End-Latenz bei der Nachrichtenzustellung. Im Fall der sortierten Zustellung erfordert das Failover eine Koordination, um sicherzustellen, dass die Nachrichten in der richtigen Reihenfolge geschrieben und gelesen werden.
Hot Key: Wenn Sie die Nachrichtenreihenfolge verwenden, werden alle Nachrichten mit demselben Sortierungsschlüssel in der Reihenfolge an Ihren Abonnentenclient gesendet, in der sie vom Dienst empfangen werden. Der Nutzer-Callback wird erst ausgeführt, wenn der Callback für die vorherige Nachricht abgeschlossen ist. Der maximale Durchsatz für Nachrichten mit demselben Sortierungsschlüssel bei der Zustellung an Abonnenten wird nicht durch Pub/Sub begrenzt , sondern durch die Verarbeitungsgeschwindigkeit Ihres Abonnentenclients. Ein Hot Key tritt auf, wenn sich ein Rückstand für einen einzelnen Sortierungsschlüssel ansammelt, weil die Anzahl der pro Sekunde erstellten Nachrichten die Anzahl der Nachrichten übersteigt, die der Abonnent pro Sekunde verarbeiten kann. Um Hot Keys zu vermeiden, verwenden Sie die detailliertesten Schlüssel, die möglich sind, und minimieren Sie die Verarbeitungszeit pro Nachricht. Sie können auch den Messwert
subscription/oldest_unacked_message_ageauf einen steigenden Wert prüfen, der auf einen Hot Key hindeuten kann.
Weitere Informationen zur Verwendung der Nachrichtenreihenfolge finden Sie in den folgenden Best-Practice-Themen:
Verhalten von Abonnentenclients bei der Nachrichtenreihenfolge
Abonnentenclients empfangen Nachrichten in der Reihenfolge, in der sie in einer bestimmten Region veröffentlicht wurden. Pub/Sub unterstützt verschiedene Möglichkeiten, Nachrichten zu empfangen, z. B. Abonnentenclients, die mit Pull- und Push-Abos verbunden sind. Die Clientbibliotheken verwenden StreamingPull (mit Ausnahme von PHP).
Weitere Informationen zu diesen Aboarten finden Sie unter Aboart auswählen.
In den folgenden Abschnitten wird erläutert, was der Empfang von Nachrichten in der richtigen Reihenfolge für die einzelnen Arten von Abonnentenclients bedeutet.
StreamingPull-Abonnentenclients
Wenn Sie die Clientbibliotheken mit StreamingPull verwenden, müssen Sie einen Nutzer-Callback angeben, der ausgeführt wird, wenn eine Nachricht von einem Abonnentenclient empfangen wird. Bei Clientbibliotheken wird der Callback für einen bestimmten Sortierungsschlüssel für Nachrichten in der richtigen Reihenfolge vollständig ausgeführt. Wenn die Nachrichten innerhalb dieses Callbacks bestätigt werden, erfolgen alle Berechnungen für eine Nachricht in der richtigen Reihenfolge. Wenn der Nutzer-Callback jedoch andere asynchrone Aufgaben für Nachrichten plant, muss der Abonnentenclient sicherstellen, dass die asynchrone Arbeit in der richtigen Reihenfolge erfolgt. Eine Möglichkeit besteht darin, Nachrichten einer lokalen Arbeitswarteschlange hinzuzufügen, die in der richtigen Reihenfolge verarbeitet wird.
Pull-Abonnentenclients
Für Abonnentenclients, die mit Pull-Abos verbunden sind, unterstützt die Pub/Sub-Nachrichtenreihenfolge Folgendes:
Alle Nachrichten für einen Sortierungsschlüssel in der PullResponse sind in der richtigen Reihenfolge in der Liste.
Für einen Sortierungsschlüssel kann jeweils nur ein Batch von Nachrichten ausstehen.
Die Anforderung, dass jeweils nur ein Batch von Nachrichten ausstehen kann, ist erforderlich, um die sortierte Zustellung beizubehalten, da der Pub/Sub-Dienst den Erfolg oder die Latenz der Antwort, die er für die Pull-Anfrage eines Abonnenten sendet, nicht garantieren kann.
Push-Abonnentenclients
Die Einschränkungen für Push sind noch strenger als für Pull. Für ein Push-Abo unterstützt Pub/Sub jeweils nur eine ausstehende Nachricht für jeden Sortierungsschlüssel. Jede Nachricht wird als separate Anfrage an einen Push-Endpunkt gesendet. Das parallele Senden der Anfragen würde also dasselbe Problem verursachen wie die gleichzeitige Zustellung mehrerer Batches von Nachrichten für denselben Sortierungsschlüssel an Pull-Abonnenten. Push-Abos sind möglicherweise keine gute Wahl für Themen, bei denen Nachrichten häufig mit demselben Sortierungsschlüssel veröffentlicht werden oder bei denen die Latenz extrem wichtig ist.
Export-Abonnentenclients
Export-Abos unterstützen sortierte Nachrichten. Bei BigQuery-Abos werden Nachrichten mit demselben Sortierungsschlüssel in der richtigen Reihenfolge in ihre BigQuery-Tabelle geschrieben. Bei Cloud Storage-Abos werden Nachrichten mit demselben Sortierungsschlüssel möglicherweise nicht alle in dieselbe Datei geschrieben. Wenn sie sich in derselben Datei befinden, sind die Nachrichten für einen Sortierungsschlüssel in der richtigen Reihenfolge. Wenn sie auf mehrere Dateien verteilt sind, können spätere Nachrichten für einen Sortierungsschlüssel in einer Datei mit einem Namen erscheinen, der einen früheren Zeitstempel hat als der Zeitstempel im Namen der Datei mit den früheren Nachrichten.
Nachrichtenreihenfolge aktivieren
Damit die Nachrichten der Reihe nach empfangen werden, legen Sie das Attribut für die Nachrichtenreihenfolge für das Abo fest, über das Sie Nachrichten erhalten. Das Empfangen von Nachrichten der Reihe nach kann die Latenz erhöhen. Sie können das Attribut für die Nachrichtenreihenfolge nach dem Erstellen eines Abos nicht mehr ändern.
Sie können das Attribut für die Nachrichtenreihenfolge festlegen, wenn Sie ein Abo in der Google Cloud Console, mit der Google Cloud CLI oder der Pub/Sub API erstellen.
Console
So erstellen Sie ein Abo mit dem Attribut für die Nachrichtenreihenfolge:
- Rufen Sie in der Google Cloud Console die Abos Seite auf.
Klicken Sie auf Abo erstellen.
Geben Sie eine Abo-ID ein.
Wählen Sie ein Thema aus, von dem Sie Nachrichten empfangen möchten.
Wählen Sie im Abschnitt Nachrichtenreihenfolge die Option Nachrichten mit einem Reihenfolgeschlüssel sortieren aus.
Klicken Sie auf Erstellen.
gcloud
Verwenden Sie zum Erstellen eines Abos mit dem Attribut für die Nachrichtenreihenfolge den
gcloud pubsub subscriptions
create Befehl und das
--enable-message-ordering Flag:
gcloud pubsub subscriptions create SUBSCRIPTION_ID \ --enable-message-ordering
Ersetzen Sie SUBSCRIPTION_ID durch die ID des Abos.
Wenn die Anfrage erfolgreich ist, wird in der Befehlszeile eine Bestätigung angezeigt:
Created subscription [SUBSCRIPTION_ID].
REST
Senden Sie zum Erstellen eines Abos mit dem Attribut für die Nachrichtenreihenfolge eine PUT-Anfrage wie diese:
PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID Authorization: Bearer $(gcloud auth application-default print-access-token)
Ersetzen Sie Folgendes:
- PROJECT_ID: Projekt-ID des Projekts mit dem Thema
- SUBSCRIPTION_ID: die ID des Abos
Geben Sie im Anfragetext Folgendes an:
{ "topic": TOPIC_ID, "enableMessageOrdering": true, }
Ersetzen Sie TOPIC_ID durch die ID des Themas, das an das Abo angehängt werden soll.
Wenn die Anfrage erfolgreich ist, ist die Antwort das Lite-Abo im JSON-Format:
{
"name": projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID,
"topic": projects/PROJECT_ID/topics/TOPIC_ID,
"enableMessageOrdering": true,
}
C++
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C++ in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Pub/Sub C++ API-Referenzdokumentation.
C#
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für C# in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub C# API.
Go
Im folgenden Beispiel wird die Hauptversion der Go Pub/Sub-Clientbibliothek (Version 2) verwendet. Wenn Sie noch die Version 1 verwenden, lesen Sie den Migrationsleitfaden zu Version 2. Eine Liste der Codebeispiele für Version 1 finden Sie unter Veraltete Codebeispiele.
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Go in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Go API.
Java
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Java in der Kurzanleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Java API.
Node.js
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Node.js in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Node.js API.
Node.js
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Node.js in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Node.js API.
Python
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Python in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Python API.
Ruby
Im folgenden Beispiel wird die Ruby Pub/Sub-Clientbibliothek Version 3 verwendet. Wenn Sie noch die Version 2 verwenden, lesen Sie den Migrationsleitfaden zu Version 3. Eine Liste der Codebeispiele für Ruby Version 2 finden Sie unter Veraltete Codebeispiele.
Bevor Sie dieses Beispiel testen, folgen Sie der Einrichtungsanleitung für Ruby in der Schnellstart-Anleitung: Clientbibliotheken verwenden. Weitere Informationen finden Sie in der Referenzdokumentation zur Pub/Sub Ruby API.
Nächste Schritte
Lesen Sie den Blogpost zur sortierten Zustellung.
Informationen zum Veröffentlichen von Nachrichten bei nicht wiederholbaren Fehlern, siehe Anfragen mit Sortierungsschlüsseln wiederholen.
Informationen zum Veröffentlichen von Nachrichten mit Sortierungsschlüsseln.