Eventual Consistency (deutsch: letztendliche Konsistenz) ist ein Konsistenzmodell für verteilte Systeme: Kopien eines Datums dürfen vorübergehend voneinander abweichen, gleichen sich aber garantiert irgendwann an. Sie ist die typische Antwort der AP-Seite des CAP-Theorems auf die Frage, wie sich hohe Verfügbarkeit mit Replikation vereinbaren lässt.
Definition
Der Begriff wurde durch Werner Vogels, den CTO von Amazon, geprägt. In seinem Blog „All Things Distributed“ definierte er (Dezember 2007, vertieft im Follow-up „Eventually Consistent – Revisited“ Dezember 2008): Wenn keine neuen Updates auf ein Objekt erfolgen, werden irgendwann alle Zugriffe den letzten aktualisierten Wert liefern. Die Dauer der Angleichung (die Konvergenzzeit) bleibt dabei offen.
Vogels unterscheidet ein Spektrum von Konsistenzmodellen: strong (jeder Leser sieht sofort den neuesten Stand), weak (keine Garantie) und eventual als die wichtigste weak-Variante mit der Zusatzgarantie des letztendlichen Angleichens.
Wie es funktioniert
Eventually konsistente Systeme schreiben Updates verzögert auf andere Knoten (asynchrone Replikation). Kommt es zu Konflikten – zwei Knoten haben denselben Datensatz unterschiedlich geändert –, lösen sie diese durch Strategien wie Last-Write-Wins, Versionsvektoren oder CRDTs auf. Die Knoten gleichen sich außerdem regelmäßig gegenseitig ab (Anti-Entropy), damit jede Kopie den Endzustand erreicht.
Ein bekanntes Beispiel aus dem Alltag ist das DNS: Ändert eine Domain ihre IP-Adresse, braucht die Änderung Zeit, bis sie über Caches auf der ganzen Welt angekommen ist – irgendwann zeigen aber alle Resolver den neuen Wert.
BASE statt ACID
Eventual Consistency ist Teil des Gegenentwurfs zu ACID: BASE (geprägt von Dan Pritchett 2008 in der ACM Queue, „BASE: An Acid Alternative“) steht für Basically Available (grundsätzlich verfügbar), Soft state (Zustände dürfen sich ändern) und Eventually consistent. Während ACID strikte Transaktionskonsistenz erzwingt, akzeptiert BASE kurzzeitig abweichende Werte und erkauft sich damit Latenz und Verfügbarkeit bei sehr großer Skalierung.
Praxis
Typische Vertreter sind Cassandra, CouchDB und Amazon DynamoDB – Amazon baute mit Dynamo einen hochverfügbaren, eventually konsistenten Schlüssel-Wert-Speicher, der den Einkaufswagen auch bei Ausfällen beschreibbar hält und Konflikte später auflöst. Auch Sharding und Cluster nutzen das Modell, um Daten verteilt und trotzdem erreichbar zu halten. Konsequenz: Leser können kurzfristig veraltete Werte sehen – für Bestellungen, Kontostände und Buchungen ist starke Konsistenz meist die bessere Wahl, für Feeds, Zähler und Empfehlungen ist Eventual Consistency praktisch.
Verwandte Grundlagen: CAP-Theorem (das Modell dahinter), Datenbank-Replikation (der Mechanismus), NoSQL (das Einsatzgebiet).