CAP Theorem
Details
- Vollständiger Name
-
CAP-Theorem (Consistency, Availability, Partition tolerance)
- Auch bekannt als
-
Brewers Theorem
Kernkonzepte:
- Die drei Eigenschaften
-
Consistency (jeder Read sieht den letzten Write), Availability (jede Anfrage erhält eine Nicht-Fehler-Antwort), Partition tolerance (das System arbeitet trotz verlorener/verzögerter Nachrichten zwischen Knoten weiter)
- Der Trade-off
-
Bei einer Netzwerkpartition muss ein verteiltes System zwischen Consistency und Availability wählen — während der Partition geht nicht beides
- Partitionen sind nicht optional
-
Reale Netze partitionieren, also ist P gesetzt; die eigentliche Designwahl ist CP- vs. AP-Verhalten während der Partition
- Häufiges Missverständnis
-
„2 von 3 wählen" ist eine Vereinfachung; ohne Partition kann ein System gleichzeitig konsistent und verfügbar sein
- PACELC-Erweiterung
-
Else (keine Partition) Latency gegen Consistency abwägen — bildet das alltägliche Tuning ab, das CAP allein auslässt (Abadi, 2012)
- Key Proponents
-
Eric Brewer (Vermutung 2000, PODC-Keynote); formal bewiesen von Seth Gilbert & Nancy Lynch (2002); PACELC von Daniel Abadi (2012)
Verwendung:
-
Auswahl/Bewertung eines verteilten Datenspeichers (CP- vs. AP-Verhalten)
-
Konkreter Consistency-/Availability-Trade-off für ein Feature
-
Verhalten bei Netzwerkpartitionen und Failover durchdenken
-
Erklären, warum starke Konsistenz Verfügbarkeit oder Latenz kostet
Nicht verwenden:
-
Für Ein-Knoten-Systeme ohne Replikation (keine Partitionen zu tolerieren)
-
Als plumpe „2 von 3"-Parole — besser die Partitions-Sicht oder PACELC
Verwandte Anker:
-
Event-Driven Architecture — Eventual Consistency als AP-Designwahl
-
Fallacies of Distributed Computing — die Netzannahmen, die CAP explizit macht
Kritik:
-
Eric Brewer selbst, "CAP Twelve Years Later: How the 'Rules' Have Changed" (IEEE Computer, 2012) — die "2 von 3"-Formulierung ist irreführend; der Trade-off ist enger und nuancierter, als die Parole suggeriert
-
Martin Kleppmann, "Please stop calling databases CP or AP" (2015) — die formalen CAP-Definitionen sind zu eng, um reale Systeme zu klassifizieren; viele Datenbanken sind nach den eigenen Begriffen des Theorems weder CP noch AP
-
Im Diskurs benannte Alternative: mit präzisen Konsistenzmodellen argumentieren (Linearisierbarkeit, kausale Konsistenz usw.) und mit der PACELC-Sicht statt der CP/AP-Dichotomie