Das CAP-Theorem und Konsistenzmodelle

Das CAP-Theorem besagt, dass ein verteiltes Datensystem, das mit einer Netzwerkpartition konfrontiert ist, entweder Konsistenz oder Verfügbarkeit opfern muss, und Konsistenzmodelle legen genau fest, welche Garantien ein System hinsichtlich der Sichtbarkeit und Reihenfolge von Aktualisierungen bietet.

Definition

Das CAP-Theorem besagt, dass ein vernetztes System mit gemeinsam genutzten Daten höchstens zwei der Eigenschaften Konsistenz, Verfügbarkeit und Partitionstoleranz gleichzeitig garantieren kann; ein Konsistenzmodell ist ein Vertrag, der festlegt, was eine Anwendung über die Reihenfolge und Sichtbarkeit von Lese- und Schreibvorgängen über Replikate hinweg beobachten kann.

Scope

Dieses Thema behandelt das CAP-Theorem und seine Formalisierung, die praktische Lesart, dass der eigentliche Kompromiss nur bei Netzwerkpartitionen entsteht, und die daraus resultierende PACELC-Verfeinerung. Es deckt das Spektrum der Konsistenzmodelle ab – von starker (linearisierbarer) Konsistenz über kausale Konsistenz bis hin zu eventueller Konsistenz – und den BASE-Stil, der im Gegensatz zu ACID steht. Es behandelt, wie diese Modelle das Design von replizierten Datenspeichern leiten. Ausgeschlossen sind die Konsens- und Commit-Protokolle, die zur Implementierung starker Konsistenz verwendet werden und unter verteilten Datenbanken behandelt werden.

Core questions

• Was bedeuten Konsistenz, Verfügbarkeit und Partitionstoleranz im CAP-Theorem genau?
• Warum wird die eigentliche Wahl zwischen Konsistenz und Verfügbarkeit nur während einer Partition erzwungen?
• Wie unterscheiden sich starke, kausale und eventuelle Konsistenz in ihren Garantien?
• Was verspricht eventuelle Konsistenz, und was nicht?
• Wie kontrastiert die BASE-Philosophie mit ACID?

Key concepts

• Konsistenz, Verfügbarkeit, Partitionstoleranz
• Netzwerkpartition
• Linearisierbarkeit / starke Konsistenz
• kausale Konsistenz
• eventuelle Konsistenz
• PACELC
• BASE versus ACID
• Konfliktlösung

Key theories

Das CAP-Theorem

Von Gilbert und Lynch formalisiert, zeigt CAP, dass bei einer Netzwerkpartition ein replizierter Speicher zwischen der Rückgabe möglicherweise veralteter Daten (Verfügbarkeit) und der Verweigerung des Dienstes zur Wahrung eines einzigen konsistenten Wertes (Konsistenz) wählen muss; Partitionstoleranz ist in realen Netzwerken nicht optional.

Konsistenzspektrum

Konsistenzmodelle reichen von starker (linearisierbarer) Konsistenz, bei der Lesezugriffe immer den neuesten Schreibvorgang sehen, über kausale Konsistenz, die die Ursache-Wirkungs-Reihenfolge bewahrt, bis hin zu eventueller Konsistenz, bei der Replikate ohne neue Schreibvorgänge im Laufe der Zeit konvergieren.

BASE versus ACID

Hochverfügbare Systeme übernehmen oft einen BASE-Stil – im Grunde verfügbar, weicher Zustand, eventuell konsistent – und lockern bewusst die starken ACID-Garantien, um unter Partitionen und in großem Maßstab reaktionsfähig zu bleiben.

Clinical relevance

CAP und Konsistenzmodelle umrahmen die zentrale Designentscheidung in verteilten Datensystemen: ob ein Speicher bei Netzwerkausfällen die ständige Beantwortung (Verfügbarkeit) oder die stets korrekte Beantwortung (Konsistenz) priorisiert, eine Entscheidung, die das Verhalten und die Garantien jeder global verteilten Anwendung prägt.

History

Eric Brewer vermutete den CAP-Kompromiss um das Jahr 2000; Gilbert und Lynch bewiesen ihn 2002 formal. Amazons Dynamo (2007) und Vogels Essay von 2009 popularisierten die eventuelle Konsistenz in der Praxis. Brewers Retrospektive von 2012 stellte klar, dass CAP perfekte Konsistenz und Verfügbarkeit nur während Partitionen verbietet, und die PACELC-Formulierung fügte später den Latenz-Konsistenz-Kompromiss im partitionierungsfreien Fall hinzu.

Debates

Wie fundamental ist der Kompromiss zwischen Konsistenz und Verfügbarkeit?

Frühe Lesarten betrachteten CAP als eine erzwungene, dauerhafte Wahl zwischen Konsistenz und Verfügbarkeit; spätere Analysen, einschließlich Brewers Retrospektive, argumentieren, dass der Kompromiss nur während Partitionen zum Tragen kommt und dass Systeme ansonsten weitgehend konsistent und verfügbar sein können, was die Strenge, mit der CAP das Design einschränkt, neu bewertet.

Key figures

• Eric Brewer
• Seth Gilbert
• Nancy Lynch
• Werner Vogels

Seminal works

• gilbert2002
• brewer2012
• vogels2009

Frequently asked questions

Bedeutet CAP, dass ich immer nur zwei der drei Eigenschaften haben kann?

Die populäre Formulierung „wähle zwei“ ist irreführend. Partitionstoleranz ist in einem verteilten System nicht wirklich optional, daher ist die eigentliche Wahl zwischen Konsistenz und Verfügbarkeit, und diese Wahl muss nur getroffen werden, wenn tatsächlich eine Partition auftritt. Wenn das Netzwerk intakt ist, kann ein System sowohl Konsistenz als auch Verfügbarkeit bieten.

Was garantiert eventuelle Konsistenz tatsächlich?

Sie garantiert, dass, wenn keine neuen Aktualisierungen an einem Datenelement vorgenommen werden, alle Replikate schließlich zum gleichen Wert konvergieren. Sie garantiert weder wann, noch dass ein Lesezugriff den neuesten Schreibvorgang widerspiegelt, daher müssen Anwendungen, die eventuelle Konsistenz verwenden, vorübergehend veraltete oder widersprüchliche Lesezugriffe tolerieren und oft die Konfliktlösung selbst handhaben.