Cloud Spanner-Warteschlangen – Übersicht

Spanner-Warteschlangen ermöglichen transaktionales Messaging und unterstützen Sie so bei der Verwaltung asynchroner Abläufe. Diese Funktion kombiniert diese Möglichkeit mit der Skalierbarkeit und Zuverlässigkeit von Spanner, sodass Sie ereignisgesteuerte Anwendungen erstellen können. Spanner-Warteschlangen verwenden ein Pull-Modell für den Nachrichtenverbrauch und stellen eine SQL-Schnittstelle für Empfänger bereit, um Nachrichten anzufordern und zu empfangen.

Zwischen Spanner-Warteschlangen und ‑Änderungsstreams wählen

Der folgende Vergleich bietet eine Orientierungshilfe bei der Auswahl des richtigen Mechanismus für die Datenübertragung und asynchrone Verarbeitung.

Cloud Spanner-Warteschlangen

Optimal für

  • Benachrichtigungen zu Transaktionsereignissen
  • Zukünftige geplante Ausführung von Aufgaben
  • Logik für die Bestätigung einzelner Nachrichten

Wichtige Merkmale

  • Kleine, benutzerdefinierte Nutzlasten
  • Pull-Modell für die Nachrichtenaufnahme
  • Skaliert mit der Rechenleistung der Spanner-Instanz

Spanner-Änderungsstreams

Optimal für

  • Datenreplikation mit hohem Durchsatz
  • Downstream-Caches oder ‑Indexe synchronisieren
  • Audit-Logging jeder Datenbankänderung

Wichtige Merkmale

  • Erfasst alle Datensatzfragmente (bis zu 10 MB).
  • Pull-basiertes Streaming mit Partitionstokens
  • Umfasst Heartbeats und Checkpointing

Wichtigste Vorteile

Spanner-Warteschlangen bieten mehrere Vorteile:

  • Integriert:Messaging ist in die Datenbank integriert. Dadurch müssen keine Daten für eine separate Messaging-Infrastruktur bereitgestellt, verwaltet und exportiert werden. Das vereinfacht die Anwendungsarchitektur und senkt die Gesamtkosten.
  • Transaktional:Sie können Nachrichten atomar innerhalb einer Spanner-Transaktion zusammen mit anderen Datenbankschreibvorgängen senden und bestätigen. In die Warteschlange gestellte Nachrichten werden zurückgesetzt und sind nicht für die Zustellung verfügbar, wenn die Transaktion fehlschlägt.
  • Langlebig:Nachrichten, die nicht zugestellt werden können, werden in der Datenbank gespeichert. Spanner versucht die Zustellung kontinuierlich mit Backoff, bis die Nachricht explizit bestätigt oder gelöscht wird.
  • Abfragbar:Nachrichten basieren auf denselben Primitiven wie Spanner-Tabellen und werden als Zeilen gespeichert. Sie können sie wie Standardtabellen abfragen, zusammenführen oder filtern.
  • Skalierbar:Die Nachrichtenverarbeitung ist so skalierbar wie Spanner-Tabellen und wird zusammen mit dem Rest Ihrer Datenbank skaliert.
  • Zuverlässig:Spanner-Warteschlangen erben alle Primitiven für hohe Verfügbarkeit von Spanner. Dadurch sind das Senden und Verarbeiten von Nachrichten fehlertolerant und widerstandsfähig gegen zonale oder regionale Ausfälle.
  • Planbar:Nachrichten können für die zukünftige Zustellung geplant werden. So können Sie die Ausführung von Aufgaben auf einen bestimmten zukünftigen Zeitstempel verschieben.
  • Atomar:Das Senden von Nachrichten (INSERT- oder Mutations-APIs) und die Bestätigung (DELETE- oder Mutations-APIs) werden atomar innerhalb von Transaktionen ausgeführt, um die Konsistenz mit dem Datenbankstatus zu gewährleisten.
  • Erweiterbar:Nachrichtenleases können verlängert werden, um extrem lange Verarbeitungszeiten zu unterstützen. Dazu werden Mechanismen für die zukünftige Zustellung und das manuelle Leasen kombiniert.

Anwendungsfälle

Spanner-Warteschlangen sind nützlich, um zurückgestellte Aufgaben innerhalb einer Transaktion zu orchestrieren. Beispiele:

  • Aufschieben rechenintensiver Aufgaben:Eine Website zum Teilen von Fotos muss möglicherweise eine intensive Bildverarbeitung durchführen, wenn ein neues Foto hochgeladen wird. Bei der Transaktion, mit der die neuen Fotometadaten geschrieben werden, kann gleichzeitig eine Warteschlangennachricht geschrieben werden. Ein Warteschlangenempfänger ruft die Nachricht später ab, führt die Verarbeitung durch und aktualisiert die Metadaten transaktional.
  • Große transaktionale Aktualisierungen aufschieben:Wenn Sie in einer Kalender-App eine große Gruppe in einer einzelnen Transaktion zu einer Besprechung einladen, kann dies zu Sperrkonflikten und Tail-Latenzen führen. Stattdessen kann bei der Transaktion, mit der der Kalendereintrag erstellt wird, für jeden Eingeladenen ein Warteschlangeneintrag hinzugefügt werden, sodass der Empfänger die Einladungen einzeln senden kann.
  • Aufgaben für die Zukunft planen:Ein SaaS-Unternehmen (Software-as-a-Service), das einen 30-tägigen kostenlosen Testzeitraum anbietet, kann die Ressourcen des Nutzers bereitstellen und gleichzeitig eine Nachricht in die Warteschlange stellen, die in 30 Tagen zugestellt werden soll. Ein Worker empfängt dann die Nachricht und führt die Logik für den Ablauf des Testzeitraums aus.
  • Arbeit an externe Systeme delegieren:Nachdem sich ein Nutzer registriert hat, muss eine Anwendung möglicherweise nur dann eine Willkommens-E‑Mail senden, wenn die Datenbankregistrierung erfolgreich ist. Bei der Registrierungstransaktion kann ein Eintrag in eine Warteschlange eingefügt werden, sodass ein Mitarbeiter später eine externe E‑Mail-API aufrufen kann.
  • Orchestrierung mehrstufiger Pipelines:In einem Auftragsverwaltungssystem umfasst die Ausführung eines Auftrags mehrere Schritte, die unabhängig voneinander fehlschlagen können. Da jeder Schritt als Warteschlangennachricht dargestellt wird, kann das System den Status der Pipeline speichern und an der Stelle des Fehlers fortfahren.

Workflow

Ein typischer Workflow für Spanner-Warteschlangen umfasst die folgenden Schritte:

  • Warteschlange erstellen:Definieren Sie eine Warteschlange mit DDL, ähnlich wie eine Tabelle. Sie muss eine Payload-Spalte (payload in PostgreSQL) und einen Primärschlüssel enthalten.
  • Mitteilungen senden:Nachrichten mit Standard-DML (INSERT) oder Mutations-APIs transaktional mit anderen Datenbankvorgängen in die Warteschlange stellen.
  • Nachrichten empfangen:Rufen Sie mit der ExecuteStreamingSQL API eine Tabellenwertfunktion (Table-valued function, TVF) namens RECEIVE_QUEUE_NAME() auf. Diese Funktion streamt Nachrichten als lang andauernde Anfrage an Ihren Client.
  • Nachrichten verarbeiten:Die vom TVF empfangenen Nachrichten mit Ihrer Anwendungslogik verarbeiten.
  • Nachrichten bestätigen:Entfernen Sie Nachrichten aus der Warteschlange mit DML (DELETE) oder Mutations-APIs (z. B. ack). Dies erfolgt in der Regel nach Abschluss der Verarbeitung innerhalb einer Transaktion.
  • Leases verwalten:Verwalten Sie Nachrichten-Leases, damit Nachrichten in Spanner-Warteschlangen nicht noch einmal zugestellt werden, wenn das Lease-Zeitlimit abläuft. Am häufigsten wird die RENEWLEASE_QUEUE_NAME()-TVF verwendet.

Beachten Sie außerdem die folgenden grundlegenden Verhaltensweisen von Spanner-Warteschlangen:

  • Mindestens einmalige Zustellung:Wie bei den meisten cloudbasierten Warteschlangensystemen wird auch bei Spanner eine mindestens einmalige Zustellung garantiert. Durch die Verlängerung von Freigaben können erneute Bereitstellungen vermieden werden.
  • Bestätigung höchstens einmal:Da die Bestätigung einer Nachricht über eine Transaktion erfolgt, sorgen die ACID-Semantik von Spanner dafür, dass eine Nachricht nur einmal bestätigt wird. Folgen Sie den Methoden auf der Seite Genau einmalige Verarbeitung und höchstens einmalige Bestätigung, um die höchstens einmalige Bestätigung richtig zu implementieren.

Beschränkungen

Für Spanner-Warteschlangen gelten die folgenden Einschränkungen:

  • Maximale Anzahl von Empfängern:Pro Warteschlange sind maximal 1.000 aktive Empfangsabfragen mit denselben Argumenten zulässig.
  • Kontingentlimit für gleichzeitigen Empfang von TVFs:Es gilt ein Kontingentlimit von 2.000 gleichzeitigen Empfängen von TVFs pro Projekt und Region. Wenn Sie das Kontingentlimit erhöhen möchten, füllen Sie das Formular zum Anfordern einer Kontingenterhöhung für Ihr Cloud Spanner-Projekt aus.
  • Manuelles Aufteilen:Die AddSplits API wird für Warteschlangen nicht unterstützt. Die Arbeitslastverteilung basiert vollständig auf der lastbasierten Aufteilung. Es wird empfohlen, die Warteschlange in eine Tabelle einzufügen, damit Nutzer der Tabelle Aufteilungspunkte hinzufügen können.
  • Compliance mit Geopartitionierung:Geopartitionierte Warteschlangen entsprechen nach der Ausführung eines DROP PARTITION-Vorgangs nicht den Anforderungen an den Speicherort von Daten.
  • Beschränkungen für die Anzahl der Warteschlangen:Instanzen mit einem oder mehreren Knoten sind auf 100 Warteschlangen begrenzt. Das Limit wird für granulare Instanzen proportional herunterskaliert (z. B. sind Instanzen mit 200 Verarbeitungseinheiten auf 20 Warteschlangen beschränkt).
  • Löschen und erneutes Erstellen einer Warteschlange:Das Löschen und erneute Erstellen einer Warteschlange mit demselben Namen wird nicht vollständig unterstützt. Es kann einige Zeit dauern, bis die RECEIVE-TVF für die Warteschlange „zurückgesetzt“ wird, bevor Nachrichten wieder unter demselben Namen empfangen werden können.
  • PostgreSQL-Spaltenbenennung:Spanner stellt sowohl die Spalten deliver_time als auch DeliverTime für die Zustellzeit einer Nachricht zur Verfügung. Wir empfehlen, die Spalte deliver_time zu verwenden, um den standardmäßigen PostgreSQL-Namenskonventionen zu entsprechen, und weil die Spalte DeliverTime in einer zukünftigen Version im Informationsschema ausgeblendet wird.
  • Benanntes Schema:Warteschlangen können nicht in benannten Schemas erstellt werden.

Nächste Schritte