Eventual Consistency
Kopien gleichen sich später an
Die Idee und ihr Nutzen
Ein Kunde zieht um und ändert im Kundenportal seiner Versicherung seine Adresse von Birkenweg 4 auf Eichenweg 12. Das Kundenportal speichert die neue Adresse sofort in der Kundendatenbank, doch die Sachbearbeiter sehen bei ihrer Suche noch einige Sekunden die alte Adresse. Ihre Suche fragt nämlich den Suchindex ab, eine aufbereitete Kopie der Kundendaten, in der sich Kunden schneller finden lassen als in der Kundendatenbank. Solche Kopien dürfen vorübergehend einen anderen Stand haben als die Kundendatenbank: Der Suchindex liefert noch Birkenweg 4, die Kundendatenbank hat schon Eichenweg 12. Die Kopien übernehmen die Änderung später und stimmen dann mit der Kundendatenbank überein, sofern die Übertragung funktioniert und keine neuen Änderungen hinzukommen. Das Kundenportal muss so beim Speichern nicht auf die Kopien warten, und auch während einer Störung des Suchindex kann der Kunde seine Adresse ändern. Dieses Verhalten heißt Eventual Consistency, auf Deutsch etwa „letztendliche Übereinstimmung“. Der Name meint: Am Ende stimmen alle Kopien mit der Kundendatenbank überein, nur nicht sofort.
Wie funktioniert es?
Um 9:00:00 Uhr ändert der Kunde seine Adresse auf Eichenweg 12. Die Kundendatenbank speichert und bestätigt die Änderung, und das Kundenportal zeigt dem Kunden die neue Adresse direkt aus der Antwort der Kundendatenbank. Von der Kundendatenbank geht die Änderung an die Kopien der Kundendaten in anderen Systemen. Der Schadendienst hält eine eigene Kopie der Kundendaten und übernimmt die Änderung nach weniger als einer Sekunde. Um 9:00:01 Uhr sucht eine Sachbearbeiterin den Kunden über den Suchindex. Der Suchindex hat die Änderung noch nicht und liefert Birkenweg 4. Um 9:00:02 Uhr übernimmt der Suchindex die Änderung aus der Kundendatenbank. Als die Sachbearbeiterin um 9:00:05 Uhr noch einmal sucht, liefert der Suchindex Eichenweg 12 und stimmt mit der Kundendatenbank überein. Hätte die Sachbearbeiterin nach der ersten Suche einen Brief an die angezeigte Adresse geschickt, wäre der Brief an die alte Adresse Birkenweg 4 gegangen. Das Auswertungssystem hält eine weitere Kopie und übernimmt die neue Adresse zuletzt, beim nächtlichen Abgleich.
Die Adresse eines Kunden wird nur in der Kundendatenbank geändert. Gelesen wird die Adresse aber auch im Suchindex, im Schadendienst und im Auswertungssystem. Alle drei halten Kopien desselben Datensatzes, also derselben Adresse. Diese drei Systeme laufen auf eigenen Rechnern, sind über das Netz verbunden und haben getrennte Wartungszeiten. Jedes von ihnen kann deshalb zeitweise nicht erreichbar sein, ohne dass die anderen ausfallen.
Bei Eventual Consistency gilt eine schwächere Zusage als „alle Kopien sind immer gleich“: Eine Änderung gilt als gespeichert, sobald ein System sie bestätigt hat, hier die Kundendatenbank. Die übrigen Kopien erhalten die Änderung danach, ohne dass das Kundenportal darauf wartet, nach Millisekunden, nach Sekunden oder bei Störungen auch deutlich später. Zugesagt ist nur, dass alle Kopien übereinstimmen werden, wenn keine neuen Änderungen hinzukommen und die Übertragung funktioniert. Wann das der Fall ist, sagt der Ansatz nicht zu, und eine feste Höchstdauer gibt es nicht.
Zwei weitere Zusagen ersparen Nutzern verwirrende Anzeigen, müssen aber eigens gebaut werden. Read Your Writes, auf Deutsch „eigene Änderungen lesen“, bedeutet: Wer etwas geändert hat, sieht bei seinen folgenden Abfragen seine eigene Änderung. Der Kunde sieht dann zum Beispiel auch auf seinem Smartphone sofort Eichenweg 12. Monotonic Reads, wörtlich „monotones Lesen“, bedeutet: Wer einmal einen neueren Stand gesehen hat, bekommt danach keinen älteren mehr angezeigt. Hat die Sachbearbeiterin einmal Eichenweg 12 gesehen, zeigt ihr dann keine spätere Suche wieder Birkenweg 4. Eventual Consistency allein sagt beides nicht zu. Dass das Kundenportal dem Kunden nach dem Speichern die neue Adresse aus der Antwort der Kundendatenbank zeigt, ist noch kein Read Your Writes. Eine spätere Abfrage vom Smartphone des Kunden kann noch die alte Adresse liefern.
Bleibt eine Übertragung wegen einer Störung aus, zeigt die betroffene Kopie den alten Stand, bis die Störung behoben ist. In der Versicherung nimmt nur die Kundendatenbank Änderungen an. Nehmen dagegen mehrere Kopien Änderungen an, etwa je eine Datenbank an zwei Standorten, können zwei Sachbearbeiter dieselbe Adresse gleichzeitig an beiden Standorten ändern. Dann braucht das System eine Konfliktregel, die festlegt, welcher Stand gilt. Möglich sind zum Beispiel diese Regeln:
- Ein Stand wird nach einer festen Rangfolge bevorzugt, etwa der Stand des Hauptstandorts.
- Beide Stände werden aufbewahrt, und ein Mensch entscheidet.
- Die Daten haben eine Form, die sich automatisch zusammenführen lässt. Ein Beispiel ist ein Zähler, bei dem beide Erhöhungen addiert werden.
Eventual Consistency: die neue Adresse erreicht die Kopien nacheinander
Wann ist es sinnvoll und wann nicht?
Eventual Consistency passt
- Kurz veraltete Daten richten keinen Schaden an. Beispiele sind Übersichten, Suchergebnisse, Statistiken und Empfehlungen. Für eine Suche nach Kunden genügt es meist, wenn die neue Adresse nach wenigen Sekunden erscheint. Ohne Eventual Consistency müsste jede Adressänderung warten, bis auch der Suchindex sie übernommen hat, obwohl wenige Sekunden Verzögerung bei der Suche nichts ausmachen.
- Eine Änderung soll nicht scheitern, nur weil eine einzelne Kopie gerade nicht erreichbar ist. Müsste das Kundenportal warten, bis alle Kopien die Änderung bestätigt haben, könnte der Kunde seine Adresse während Wartungsarbeiten am Suchindex nicht ändern. Dabei benutzt der Kunde den Suchindex nie.
- Das Speichern soll nicht von der langsamsten Kopie abhängen. Das Speichern im Kundenportal dauert nur so lange wie die Bestätigung der Kundendatenbank. Müsste das Kundenportal auf alle Kopien warten, dauerte jede Änderung so lange, wie die langsamste Kopie für die Übernahme braucht.
- Die Kopien sollen unterschiedlich schnell nachziehen dürfen. Ohne Eventual Consistency müsste auch das Auswertungssystem jede Adressänderung sofort übernehmen, bevor das Kundenportal sie bestätigen kann. Der Schadendienst hat die neue Adresse nach weniger als einer Sekunde, ohne auf Suchindex oder Auswertungssystem zu warten. Das Auswertungssystem übernimmt Änderungen im nächtlichen Abgleich und muss tagsüber nicht jede einzelne Änderung sofort verarbeiten.
- Ein System ist über mehrere Standorte oder Dienste verteilt und soll bei Störungen einzelner Teile weiterarbeiten. Ohne Eventual Consistency kann bei einer Störung des Suchindex niemand eine Adresse ändern, weil jede Änderung auf die Bestätigung des Suchindex warten müsste. Fällt der Suchindex aus, nimmt die Kundendatenbank weiter Adressänderungen an, und der Schadendienst übernimmt sie weiter.
Eventual Consistency passt nicht
- Eine Entscheidung muss zwingend auf dem aktuellen Stand beruhen. Ein Beispiel ist ein Brief mit einer Frist, etwa eine Mahnung, der an die aktuelle Adresse gehen muss. Liefert der Suchindex noch Birkenweg 4, geht der Brief an die alte Wohnung. Für solche Entscheidungen liest das Programm die Adresse direkt aus der Kundendatenbank, in der die Änderung gespeichert wird, statt aus einer Kopie.
- Alle Leser müssen immer den neuesten Stand sehen. Mit Eventual Consistency liefert der Suchindex nach einer Änderung aber einige Sekunden lang den alten Stand. Dann darf das Kundenportal die Änderung erst bestätigen, wenn alle Kopien sie übernommen haben. Dafür gibt es den Two Phase Commit, bei dem ein Steuerprogramm zuerst alle Beteiligten fragt, ob sie die Änderung übernehmen können. Erst wenn alle zugestimmt haben, lässt das Steuerprogramm die Änderung endgültig speichern.
- Mehrere Nutzer oder Systeme ändern häufig denselben Datensatz gleichzeitig, und es gibt keine fachlich vertretbare Konfliktregel. Nehmen mehrere Kopien Änderungen an, verwirft eine Regel wie „die Änderung mit dem späteren Zeitstempel gewinnt“ dann eine der beiden Änderungen. Stattdessen nimmt nur eine einzige Datenbank Änderungen an diesem Datensatz an, so wie in der Versicherung nur die Kundendatenbank Adressen ändert. Diese Datenbank speichert gleichzeitige Änderungen nacheinander, und Konflikte zwischen Kopien entstehen nicht.
Nachteile und typische Fehler
Die Programme, die Kopien lesen, müssen mit widersprüchlichen Zwischenständen umgehen können, etwa damit, dass der Schadendienst schon Eichenweg 12 kennt, während der Suchindex noch Birkenweg 4 liefert. Dafür braucht es zusätzlichen Code, und Tests müssen solche Zwischenstände eigens herbeiführen. Wie lange eine Kopie wie der Suchindex höchstens einen älteren Stand zeigen darf als die Kundendatenbank, muss die Fachabteilung festlegen, und im Betrieb muss jemand überwachen, ob diese Grenze eingehalten wird. Read Your Writes und Monotonic Reads bedeuten zusätzlichen Aufwand, weil die Anwendung sich merken muss, welchen Stand ein Nutzer schon gesehen hat. Für gleichzeitige Änderungen braucht jede Datenart eine Konfliktregel, die fachlich abgestimmt ist.
Typische Fehler und woran man sie erkennt:
- Stillschweigend verworfene Änderung: Die Versicherung lässt Adressänderungen in je einer Datenbank an zwei Standorten zu und nutzt die verbreitete Konfliktregel „die Änderung mit dem späteren Zeitstempel gewinnt“. Zwei Sachbearbeiter ändern dieselbe Adresse fast gleichzeitig, jeder an seinem Standort. Beim Abgleich behält die Konfliktregel nur die Änderung mit dem späteren Zeitstempel und verwirft die andere, ohne dass es jemand merkt. Geht die Uhr am ersten Standort zwei Sekunden vor, gewinnt sogar die Änderung, die in Wirklichkeit früher gespeichert wurde. Erkennbar ist das an Sachbearbeitern, deren gespeicherte Änderung später fehlt, ohne dass jemand sie zurückgenommen hat.
- Scheinbar verschwundene Änderung: Der Kunde speichert die neue Adresse im Kundenportal. Kurz danach öffnet er das Kundenportal auf seinem Smartphone. Das Kundenportal liest die Adresse für diese Anzeige aus einer Kopie, die die Änderung noch nicht übernommen hat, und zeigt Birkenweg 4. Für den Kunden sieht es so aus, als sei seine Änderung verschwunden. Erkennbar ist das an Kunden, die dieselbe Adresse mehrmals hintereinander ändern.
- Unbemerkt ausbleibender Abgleich: Die Übertragung von der Kundendatenbank zum Suchindex bricht wegen einer Störung ab. Der Suchindex liefert weiter die Adressen vom Stand vor der Störung. Weil niemand den Abstand zwischen Kundendatenbank und Suchindex überwacht, bemerkt das niemand, bis Sachbearbeiter falsche Adressen melden. Erkennbar ist das an einem wachsenden zeitlichen Abstand zwischen der letzten Änderung in der Kundendatenbank und der letzten Änderung, die der Suchindex übernommen hat.
- Entscheidung auf altem Stand: Um 9:00:01 Uhr liefert der Suchindex der Sachbearbeiterin noch Birkenweg 4. Die Sachbearbeiterin verschickt einen Brief an diese Adresse, und der Brief geht an die alte Wohnung des Kunden. Erkennbar ist das an Briefen, die kurz nach einer Adressänderung als unzustellbar zurückkommen.
Weiterführend
Verwandte Ansätze
- CAP Theorem und PACELC Theorem: erklären, warum verteilte Systeme zwischen sofortiger Übereinstimmung einerseits und Verfügbarkeit oder kurzer Antwortzeit andererseits abwägen müssen.
- Replication: beschreibt, wie Daten auf mehrere Rechner kopiert werden. Zeitversetzt nachgeführte Kopien arbeiten nach dem Prinzip der letztendlichen Übereinstimmung.
- CQRS: trennt das Schreiben von aufbereiteten Lesetabellen, die dem Schreiben zeitversetzt folgen.
- Quorum: legt fest, wie viele Kopien bei jedem Lesen und Schreiben antworten müssen. So lässt sich einstellen, wie wahrscheinlich ein Leser einen veralteten Stand erhält.
Werkzeuge und Umsetzungen
- Apache Cassandra: verteilte Datenbank, bei der für jede Lese- und Schreibanfrage eingestellt werden kann, wie viele Kopien antworten müssen. Daraus allein folgt noch keine Zusage, dass jeder Leser den neuesten Stand sieht.
- Apache CouchDB: gleicht Kopien im Hintergrund ab und bewahrt widersprüchliche Änderungen als Konflikte auf, die die Anwendung auflösen muss.
- Riak KV: verteilter Speicher für Schlüssel und Werte mit Datenarten, die sich automatisch zusammenführen. Nach dem Ende der Herstellerfirma Basho pflegt die Gemeinschaft OpenRiak die Software zusammen mit der Erlang Ecosystem Foundation weiter.
- Automerge: Bibliothek für Datenstrukturen, die gleichzeitige Änderungen verschiedener Nutzer ohne Konflikt zusammenführen.
Quellen
- Werner Vogels: Eventually Consistent, Revisited: Grundlagentext des technischen Leiters von Amazon, der Eventual Consistency, die Zeitspanne bis zur Übereinstimmung der Kopien sowie die Zusagen Read Your Writes und Monotonic Reads beschreibt.
- Microsoft: Consistency levels in Azure Cosmos DB: zeigt an einer verteilten Datenbank, was die schwächste Stufe der Übereinstimmung nicht zusagt und wie die Stufe „Session“ das Lesen eigener Änderungen innerhalb einer Sitzung sicherstellt.