Verteilte Transaktionen, Sagas und das Outbox-Muster

Das Problem: eine Geschäftsaktion, mehrere Datenbanken

Innerhalb einer Datenbank macht eine Transaktion mehrere Änderungen atomar: Die Bestellzeile, ihre Positionen und die Zahlungsreferenz werden alle gespeichert oder keine (Abschnitt 0.5). Sobald die Daten auf Services verteilt sind, die jeweils ihre eigene Datenbank besitzen, wie es Microservices und Datenbank pro Service empfehlen, berührt eine einzelne Geschäftsaktion wie das Aufgeben einer Essensbestellung mehrere Datenbanken verschiedener Services: die des Bestellservice, die des Zahlungsservice und die des Dispositionsservice. Keine einzelne lokale Transaktion kann sie alle abdecken.

Es gibt zwei Familien von Antworten. Die eine besteht darin, viele Ressourcenmanager über ein verteiltes atomares Commit-Protokoll wie einen einzigen handeln zu lassen; der Klassiker dafür ist Two-Phase Commit. Die andere akzeptiert, dass die Aktion eine Folge lokaler Transaktionen ist, und plant für die Momente dazwischen: die Saga. Eine dritte Antwort, oft die beste, besteht darin zu erkennen, dass Transaktionsgrenze und Servicegrenze nicht übereinstimmen, und eine von beiden zu verschieben. Dieser Abschnitt behandelt alle drei und endet mit einer Entscheidungshilfe.

Two-Phase Commit und XA

Two-Phase Commit (2PC) ist ein Protokoll aus den späten 1970er-Jahren, das Alles-oder-nichts-Atomarität über mehrere Teilnehmer hinweg herstellt, etwa zwei Datenbanken oder eine Datenbank und einen Message Broker. Ein Koordinator (der Transaktionsmanager) führt es aus. In Phase 1, Prepare, fragt der Koordinator jeden Teilnehmer, ob er committen kann. Ein Teilnehmer, der mit Ja antwortet, muss die Änderungen zuvor dauerhaft speichern und die betreffenden Sperren halten, denn mit seinem Ja gibt er das Recht auf, eigenständig abzubrechen. Lauten alle Stimmen Ja, schreibt der Koordinator seine Entscheidung, COMMIT, in sein eigenes Log; lautet eine Stimme Nein oder antwortet ein Teilnehmer nicht, lautet die Entscheidung ABORT. In Phase 2, Commit, teilt er jedem Teilnehmer das Ergebnis mit, und diese wenden es an und geben ihre Sperren frei.

Die Schwäche: 2PC ist ein blockierendes Protokoll. Ein Teilnehmer, der mit Ja gestimmt hat, ist im Ungewissen: Er kennt das Ergebnis nicht und kann es nicht gefahrlos erraten, weil ein anderer Teilnehmer womöglich schon committet hat. Stürzt der Koordinator genau dann ab und bleibt ausgefallen, behalten die ungewissen Teilnehmer ihre Sperren, bis er sich erholt, und andere Transaktionen, die diese Zeilen berühren, warten ebenfalls. Der Betrieb kann eine heuristische Entscheidung erzwingen, um die Sperren freizugeben, riskiert damit aber, die Atomarität zu brechen.

Die XA-Spezifikation, 1991 von X/Open veröffentlicht, standardisierte die Schnittstelle zwischen einem Transaktionsmanager und Ressourcenmanagern, sodass beispielsweise ein Java-Anwendungsserver ein Datenbank-Update und das Senden einer Nachricht atomar committen kann. Viele relationale Datenbanken und einige Message Broker unterstützen sie.

Warum man 2PC zwischen Microservices meidet

2PC funktioniert und wird innerhalb der Grenzen eines einzelnen Systems weiterhin eingesetzt. Über unabhängig verantwortete Services hinweg passt es meist schlecht, aus Gründen, die sich gegenseitig verstärken.

Die Verfügbarkeit multipliziert sich nach unten. Jeder Teilnehmer und der Koordinator müssen laufen, damit eine Transaktion committen kann; die Verfügbarkeit der Transaktion ist also das Produkt ihrer Verfügbarkeiten, dieselbe Rechnung wie bei einer synchronen Aufrufkette (siehe Warum verteilen). Sperren werden über das Netzwerk gehalten, für mindestens zwei Roundtrips und viel länger, wenn irgendetwas langsam ist; das senkt den Durchsatz und erhöht die Konkurrenz um Ressourcen. Die Kopplung kehrt zurück: Alle Teilnehmer müssen dasselbe Protokoll sprechen, einen Transaktionsmanager teilen und sich auf Timeouts einigen, was die unabhängige Deploybarkeit untergräbt, die die Aufteilung der Services gerechtfertigt hat. Viele Teilnehmer können gar nicht mitmachen: Die meisten HTTP-APIs, Dienste Dritter wie Zahlungsanbieter, viele NoSQL-Datenbanken und mehrere verbreitete Broker unterstützen XA nicht. Und die API des Zahlungsanbieters wird niemals eine Sperre für Ihren Koordinator halten.

Innerhalb verteilter Datenbanken sieht das Bild anders aus. Systeme wie Google Spanner führen Two-Phase Commit intern zwischen Replikatgruppen aus, die ihrerseits per Konsens konsistent gehalten werden; ein abgestürzter Koordinator wird daher ersetzt, statt dass man auf ihn wartet. Das macht partitionsübergreifende Transaktionen innerhalb einer Datenbank praktikabel; Transaktionen über getrennt verantwortete Services mit ihren unterschiedlichen Technologien macht es nicht praktikabel.

Sagas: eine Folge lokaler Transaktionen

Hector Garcia-Molina und Kenneth Salem führten die Saga 1987 in einem SIGMOD-Paper über langlebige Transaktionen ein, also solche, die Datenbanksperren stundenlang halten würden. Ihre Idee war, eine solche Transaktion in eine Folge gewöhnlicher Transaktionen T₁, T₂ … T_n zu zerlegen, von denen jede für sich committet, und jeder eine kompensierende Transaktion C_i zur Seite zu stellen, die sie semantisch rückgängig macht. Das System garantiert dann, dass entweder die ganze Folge abgeschlossen wird oder auf die abgeschlossenen Schritte ihre Kompensationen in umgekehrter Reihenfolge folgen: T₁ … T_j, C_j … C₁.

Microservice-Architekturen übernahmen die Idee, weil sie genau zu ihren Randbedingungen passt: Jeder Schritt ist eine lokale ACID-Transaktion in der eigenen Datenbank eines Service, und die Schritte sind durch Nachrichten verbunden. Eine Saga liefert Atomarität im letztendlichen, fachlichen Sinn (alle Schritte finden statt, oder ihre Wirkungen werden rückgängig gemacht), aber keine Isolation: Zwischen den Schritten können andere Transaktionen den Zwischenzustand sehen.

Es hilft, die Schritte einzuordnen, wie Chris Richardson es in Microservices Patterns (2018) tut. Kompensierbare Transaktionen lassen sich durch eine Kompensation rückgängig machen. Die Pivot-Transaktion ist der Go/No-go-Punkt: Sobald sie committet, läuft die Saga bis zum Ende. Wiederholbare Transaktionen folgen nach dem Pivot und müssen so entworfen sein, dass sie bei Wiederholung irgendwann gelingen. Schritte, die wahrscheinlich fehlschlagen, vor den Pivot zu legen und Schritte, die sich nicht rückgängig machen lassen, dahinter, ist eine zentrale Entwurfsentscheidung.

Choreografie oder Orchestrierung

Die Schritte einer Saga müssen irgendwie koordiniert werden, und die beiden Möglichkeiten entsprechen der Choreografie und Orchestrierung aus ereignisgesteuerte Architektur.

In einer choreografiebasierten Saga gibt es keinen Koordinator. Jeder Service lauscht auf Ereignisse und reagiert, indem er seine lokale Transaktion ausführt und ein neues Ereignis veröffentlicht: Der Bestellservice veröffentlicht OrderCreated, der Zahlungsservice reagiert und veröffentlicht PaymentAuthorised, der Dispositionsservice reagiert darauf und so weiter; Fehlerereignisse lösen Kompensationen in den Services aus, die auf sie lauschen. Für zwei oder drei Schritte ist das einfach und hält die Services lose gekoppelt. Mit wachsender Zahl der Schritte existiert der Ablauf nur noch implizit, verstreut über die Services, und ist daher schwer zu überblicken, zu testen und zu ändern; außerdem schleichen sich zyklische Ereignisabhängigkeiten zwischen Services ein.

In einer orchestrierungsbasierten Saga sendet ein einzelner Orchestrator, meist im Service, dem der Geschäftsprozess gehört, Commands an die Teilnehmer und reagiert auf ihre Antworten. Der Orchestrator ist ein persistenter Zustandsautomat: Er hält in seiner eigenen Datenbank fest, bei welchem Schritt er ist, und kann daher nach einem Absturz weitermachen. Der Ablauf ist explizit und an einer Stelle testbar, und die Teilnehmer müssen nichts voneinander wissen. Das Risiko besteht darin, dass sich im Orchestrator Geschäftslogik ansammelt, die in die Teilnehmer gehört. Workflow-Engines wie Temporal, Camunda und AWS Step Functions bieten dauerhafte Orchestrierung als Plattform, um den Preis einer weiteren Abhängigkeit. Bei mehr als etwa drei Schritten oder bei jedem Ablauf mit Verzweigungen und Timeouts bevorzugen die meisten Fachleute Orchestrierung.

Ausgearbeitetes Beispiel: die Bestell-Saga

Die Bestell-Saga der Essenslieferplattform wird vom Bestellservice orchestriert. Die Reihenfolge der Schritte ist bewusst gewählt: Die Zahlungsautorisierung ist eine günstige Vormerkung, die sich leicht stornieren lässt, die Reservierung eines Kuriers ist der Schritt, der zu Stoßzeiten am ehesten scheitert, und die Bestätigung an das Restaurant ist der Pivot, denn sobald eine Küche mit dem Kochen begonnen hat, lässt sich die Bestellung nicht einfach rückgängig machen.

Kompensation ist kein Rollback

Ein Datenbank-Rollback macht es so, als hätte die Transaktion nie stattgefunden: Niemand sonst hat ihre Änderungen je gesehen. Eine Kompensation ist eine neue, vorwärtsgerichtete Transaktion, die einer früheren, die tatsächlich stattgefunden hat und möglicherweise gesehen wurde, semantisch entgegenwirkt. In der Bestell-Saga zeigt die Bank des Kunden vielleicht schon eine Vormerkung an, und eine E-Mail hat womöglich „Zahlung autorisiert“ gemeldet. Die Kompensation kann die E-Mail nicht zurückholen; sie kann nur die Vormerkung stornieren und eine weitere Nachricht senden. Manche Aktionen lassen sich überhaupt nicht kompensieren, etwa bereits gekochtes Essen oder eine bereits gelesene Benachrichtigung; sie gehören hinter den Pivot oder brauchen eine fachliche Kompensation wie einen Gutschein oder eine Erstattung.

Kompensationen brauchen daher dieselbe Sorgfalt wie Vorwärtsschritte. Sie müssen idempotent sein, weil die auslösende Nachricht zweimal zugestellt werden kann. Sie müssen wiederholbar sein, bis sie gelingen, denn eine dauerhaft scheiternde Kompensation hinterlässt das System in einem Zustand, den niemand entworfen hat; wenn sie wirklich nicht gelingen können, müssen sie einen Alarm auslösen, den ein Mensch auflöst. Sie müssen eventuell mit dem Vorwärtsschritt kommutativ sein: Trifft ein VoidAuthorisation vor dem AuthorisePayment ein, das es rückgängig macht (nach Timeouts und Wiederholungen möglich), sollte sich der Zahlungsservice die Stornierung merken und die verspätete Autorisierung ablehnen, statt zu scheitern. Und sie sollten für das Geschäft sichtbar sein: „abgelehnt, kein Kurier“ ist eine Information, die das Betriebsteam auf einem Dashboard sehen will.

Leben ohne Isolation: Anomalien und Gegenmaßnahmen

Weil jeder Schritt für sich committet, fehlt Sagas das I in ACID, und nebenläufige Sagas können sich gegenseitig stören. Richardson beschreibt drei daraus folgende Anomalien. Ein Lost Update (verlorenes Update) tritt auf, wenn eine Saga eine Änderung einer anderen überschreibt, ohne sie zu lesen, etwa wenn eine Stornierungs-Saga eine Bestellung als storniert markiert und die Bestell-Saga sie danach auf bestätigt setzt. Ein Dirty Read tritt auf, wenn eine Saga Daten liest, die eine andere Saga geändert hat, aber noch kompensieren könnte, etwa eine Kreditlimitprüfung, die eine Vormerkung mitzählt, die gleich storniert wird. Ein Fuzzy oder Non-Repeatable Read tritt auf, wenn zwei Schritte einer Saga dieselben Daten lesen und unterschiedliche Werte erhalten, weil eine andere Saga sie zwischendurch geändert hat.

Er katalogisiert außerdem Gegenmaßnahmen, Entwurfstechniken, die die Anomalien verringern, gestützt auf frühere Forschung zu Transaktionen über mehrere Datenbanken. Am weitesten verbreitet sind diese.

Zuverlässig veröffentlichen: die Transactional Outbox

Jeder Saga-Schritt tut zwei Dinge: Er aktualisiert seine eigene Datenbank und sendet eine Nachricht (ein Ereignis oder eine Antwort). Beides getrennt zu tun, erzeugt das Dual-Write-Problem. Committet der Service und stürzt dann vor dem Veröffentlichen ab, erfährt der Rest der Saga nie von dem Schritt. Veröffentlicht er zuerst und scheitert dann der Commit, handeln andere Services auf Grundlage von etwas, das nie geschehen ist. Datenbank und Broker in 2PC einzubinden, ist genau das, was wir vermeiden wollten.

Die Transactional Outbox löst das mit einer lokalen Transaktion. Der Service schreibt die fachliche Änderung und die ausgehende Nachricht, als Zeile in einer outbox-Tabelle, in derselben Datenbanktransaktion; entweder committen beide oder keines. Ein separates Relay liest dann die Outbox und veröffentlicht jede Nachricht beim Broker. Zwei Relay-Entwürfe sind verbreitet. Ein Polling Publisher fragt die Outbox-Tabelle in Abständen nach unveröffentlichten Zeilen ab und markiert sie als gesendet: einfach, erzeugt aber Last und Latenz. Transaction Log Tailing nutzt Change Data Capture (CDC): Ein Tool liest das datenbankeigene Replikationslog (das Write-Ahead-Log von PostgreSQL oder das Binary Log von MySQL) und macht aus neuen Outbox-Zeilen Nachrichten. Debezium, eine Open-Source-CDC-Plattform, die meist mit Kafka Connect betrieben wird, ist das bekannteste Beispiel und enthält einen Outbox Event Router, der jede Zeile anhand einer Spalte wie dem Aggregattyp an ein Topic leitet.

Das Relay kann nach dem Veröffentlichen und vor dem Vermerken abstürzen und veröffentlicht daher manchmal eine Nachricht zweimal. Die Outbox liefert also At-least-once-Zustellung, und Consumer müssen mit Duplikaten zurechtkommen. Die Reihenfolge der Veröffentlichung bleibt pro Aggregat erhalten, wenn das Relay die Zeilen in Commit-Reihenfolge veröffentlicht und die Aggregat-ID als Nachrichtenschlüssel verwendet.

BEGIN;

INSERT INTO orders (id, customer_id, state, total_pence)
VALUES ('1042', 'c-77', 'PENDING', 2350);

INSERT INTO outbox (id, aggregate_type, aggregate_id, type, payload)
VALUES ('e-9f1c', 'order', '1042', 'OrderCreated',
        '{"orderId":"1042","customerId":"c-77","totalPence":2350}');

COMMIT;
-- A relay (poller or CDC such as Debezium) later publishes e-9f1c to the broker.

Zuverlässig empfangen: idempotente Empfänger und die Inbox

Weil die Outbox, Wiederholungen des Brokers und Wiederholungen der Saga allesamt Duplikate erzeugen, muss jeder Teilnehmer ein idempotenter Empfänger sein, so der Name, den Gregor Hohpe und Bobby Woolf dem Muster in Enterprise Integration Patterns (2003) gaben. Manche Operationen sind von Natur aus idempotent („setze Bestellung 1042 auf CONFIRMED“); andere brauchen eine Duplikatprüfung. Die übliche Umsetzung ist eine Inbox: eine Tabelle verarbeiteter Nachrichten-IDs, geschrieben in derselben lokalen Transaktion wie die fachliche Änderung, sodass „die Nachricht verarbeiten“ und „sich merken, dass sie verarbeitet wurde“ gemeinsam committen. Eine erneut zugestellte Nachricht findet ihre ID bereits vor und wird bestätigt, ohne dass etwas geschieht. Der Code auf Consumer-Seite steht in ereignisgesteuerte Architektur.

Zusammen liefern Outbox, At-least-once-Zustellung und idempotente Empfänger das praktische Ergebnis, das meist gemeint ist, wenn von „Exactly-once“ die Rede ist: Jede fachliche Wirkung tritt einmal ein, auch wenn Nachrichten mehr als einmal unterwegs sind.