Cloud Spanner-Warteschlangen – Übersicht

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

Zwischen Spanner-Warteschlangen und Änderungsstreams wählen

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

Cloud Spanner-Warteschlangen

Optimal für

  • Benachrichtigungen zu Transaktionsereignissen
  • Ausführung von geplanten Aufgaben in der Zukunft
  • Bestätigungslogik pro Nachricht

Wichtige Merkmale

  • Kleine, benutzerdefinierte Nachrichtennutzlasten
  • Pull-Modell für den Nachrichtenkonsum
  • Skalierung mit der Rechenleistung der Spanner-Instanz

Spanner-Änderungsstreams

Optimal für

  • Datenreplikation mit hohem Durchsatz
  • Nachgelagerte 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 Prüfpunkte

Wichtigste Vorteile

Spanner-Warteschlangen bieten mehrere Vorteile:

  • Integriert: Messaging ist in die Datenbank integriert. Dadurch müssen Sie keine Daten in einer separaten Messaging-Infrastruktur bereitstellen, verwalten und exfiltrieren. Das vereinfacht die Anwendungsarchitektur und senkt die Gesamtkosten.
  • Transaktional: Sie können Nachrichten innerhalb einer Spanner-Transaktion zusammen mit anderen Datenbankschreibvorgängen atomar 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.
  • Dauerhaft: Nachrichten, die nicht zugestellt werden können, werden in der Datenbank gespeichert. Cloud Spanner versucht kontinuierlich, die Nachricht mit Backoff zuzustellen, bis sie 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, verknüpfen oder filtern.
  • Skalierbar: Die Nachrichtenverarbeitung wurde mit derselben Skalierbarkeit wie Spanner-Tabellen entwickelt und lässt sich zusammen mit dem Rest Ihrer Datenbank skalieren.
  • Zuverlässig: Spanner-Warteschlangen übernehmen alle Hochverfügbarkeitsprimitive von Spanner. Dadurch sind das Senden und Verarbeiten von Nachrichten fehlertolerant und widerstandsfähig gegenüber zonalen oder regionalen Ausfällen.
  • Planbar: Nachrichten können für die zukünftige Zustellung geplant werden, sodass Sie die Ausführung von Aufgaben auf einen bestimmten zukünftigen Zeitstempel verschieben können.
  • 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: Nachrichtenausleihen können verlängert werden, um extrem lange Verarbeitungszeiten zu unterstützen. Dazu werden Mechanismen für die zukünftige Zustellung und die manuelle Ausleihe kombiniert.

Anwendungsfälle

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

  • Rechenintensive Aufgaben verschieben: Auf einer Website zum Teilen von Fotos muss möglicherweise eine intensive Bildverarbeitung durchgeführt werden, wenn ein neues Foto hochgeladen wird. Die Transaktion, die die neuen Fotometadaten schreibt, kann gleichzeitig eine Warteschlangennachricht schreiben. Ein Warteschlangenempfänger ruft die Nachricht später ab, führt die Verarbeitung aus und aktualisiert die Metadaten transaktional.
  • Große Transaktionsupdates zurückstellen: Wenn Sie in einer Kalender-App eine große Gruppe in einer einzigen Transaktion zu einem Termin einladen, kann dies zu Sperrkonflikten und Tail-Latenzen führen. Stattdessen kann die Transaktion, die den Kalendereintrag erstellt, für jeden Eingeladenen einen Warteschlangeneintrag hinzufügen, sodass ein Empfänger die Einladungen einzeln senden kann.
  • Aufgaben für die Zukunft planen: Ein SaaS-Unternehmen (Software as a Service), das eine 30-tägige kostenlose Testversion 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: Nach der Registrierung eines Nutzers muss eine Anwendung möglicherweise nur dann eine Willkommens-E-Mail senden, wenn die Datenbankregistrierung erfolgreich war. Die Registrierungstransaktion kann einen Eintrag in eine Warteschlange einfügen, sodass ein Worker später eine externe E-Mail-API aufrufen kann.
  • Mehrstufige Pipelines orchestrieren: In einem Auftragsverwaltungssystem umfasst die Ausführung eines Auftrags mehrere Schritte, die unabhängig voneinander fehlschlagen können. Durch die Darstellung jedes Schritts als Warteschlangennachricht kann das System den Status der Pipeline prüfen und am Fehlerpunkt 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.
  • Nachrichten senden: Nachrichten mit Standard-DML (INSERT) oder Mutations-APIs transaktional mit anderen Datenbankvorgängen in die Warteschlange stellen.
  • Nachrichten empfangen: Verwenden Sie die ExecuteStreamingSQL API, um eine Tabellenwertfunktion (TVF) mit dem Namen RECEIVE_QUEUE_NAME() aufzurufen. Diese Funktion streamt Nachrichten als Abfrage mit langer Ausführungszeit an Ihren Client.
  • Nachrichten verarbeiten: Nutzen Sie die von der TVF empfangenen Nachrichten mit Ihrer Anwendungslogik.
  • Nachrichten bestätigen: Entfernen Sie Nachrichten mithilfe von DML (DELETE) oder Mutations-APIs (z. B. ack) aus der Warteschlange. Dies erfolgt in der Regel nach Abschluss der Verarbeitung innerhalb einer Transaktion.
  • Leases verwalten: Verwalten Sie Nachrichten-Leases, um sicherzustellen, dass Spanner-Warteschlangen Nachrichten bei Ablauf des Lease nicht noch einmal zustellen. Die gängigste Methode ist die Verwendung der TVF RENEWLEASE_QUEUE_NAME().

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

  • Mindestens einmalige Übermittlung: Wie die meisten cloudbasierten Warteschlangensysteme verspricht Spanner eine mindestens einmalige Übermittlung. Erneute Zustellungen können durch Verlängerung von Freigaben vermieden werden.
  • Höchstens einmalige Bestätigung: Da die Bestätigung einer Nachricht über eine Transaktion erfolgt, sorgt 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: Es gibt ein Limit von 1.000 aktiven Empfangsabfragen mit denselben Argumenten pro Warteschlange.
  • Kontingentlimit für gleichzeitige Empfangs-TVFs: Es gibt ein Kontingentlimit von 2.000 gleichzeitigen Empfangs-TVFs pro Projekt und Region. Wenn Sie das Kontingentlimit erhöhen möchten, füllen Sie das Formular Kontingenterhöhung für Ihr Cloud Spanner-Projekt anfordern aus.
  • Manuelle Aufteilung: 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 einer Tabelle zu verschachteln, damit Nutzer der Tabelle Aufteilungspunkte hinzufügen können.
  • Compliance bei der Geopartitionierung: Geopartitionierte Warteschlangen sind nach der Ausführung eines DROP PARTITION-Vorgangs nicht mehr datenstandortkonform.
  • Warteschlangenlimits: Instanzen mit einem oder mehreren Knoten sind auf 100 Warteschlangen beschränkt. Das Limit wird für granulare Instanzen proportional herunterskaliert. Instanzen mit 200 Verarbeitungseinheiten sind beispielsweise auf 20 Warteschlangen beschränkt.
  • PostgreSQL-Spaltenbenennung: Spanner stellt sowohl die Spalte deliver_time als auch die Spalte DeliverTime für die Lieferzeit einer Nachricht bereit. Wir empfehlen, die Spalte deliver_time zu verwenden, um die Standard-PostgreSQL-Namenskonventionen einzuhalten, und weil die Spalte DeliverTime in einem zukünftigen Release aus dem Informationsschema ausgeblendet wird.
  • Benanntes Schema: Warteschlangen können nicht in benannten Schemas erstellt werden.

Nächste Schritte