Begriff
CAP Theorem
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Das Grundgesetz der verteilten Systeme. Eric Brewer (Google) sagte 2000: "Du kannst nicht alles haben." Es gibt drei Wünsche:
- Consistency (Konsistenz): Alle Knoten sehen zur gleichen Zeit die gleichen Daten. (Jeder Read bekommt den letzten Write).
- Availability (Verfügbarkeit): Jeder Request bekommt eine Antwort (kein Timeout/Error), egal wer down ist.
- Partition Tolerance (Ausfalltoleranz): Das System läuft weiter, auch wenn das Netzwerkkabel durchschnitten wird (Split Brain). Das Theorem: Wähle zwei. (In einem verteilten System über Netzwerk musst du P wählen. Also wähle C oder A).
- CP (Consistency/Partition): Wenn Netzwerk kaputt -> Fehler werfen, aber Daten sauber halten. (Banken, Redis, MongoDB default).
- AP (Availability/Partition): Wenn Netzwerk kaputt -> Antwort geben ("Hier sind alte Daten"), aber niemals down gehen. (Cassandra, DNS, Amazon Warenkorb).
Merksatz: Ein Theorem, das besagt, dass ein verteiltes Datensystem von den drei Eigenschaften Konsistenz (C), Verfügbarkeit (A) und Partitionstoleranz (P) gleichzeitig nur zwei garantieren kann.
Wenn du eine Datenbank auswählst. Frage dich: "Soll die App im Fehlerfall stehenbleiben (Seite lädt nicht) oder alte Daten zeigen?" Webshop-Katalog? AP (Lieber Produkt zeigen, auch wenn Preis 1 min alt ist). Bestell-Bestand? CP (Lieber Fehler, als Produkt verkaufen, das nicht da ist).
1. PACELC
Das CAP-Theorem ist zu simpel. Es gilt nur bei Partitionen (Netzwerkausfall). Aber was ist im Normalbetrieb (wenn alles geht)? Dann hast du die Wahl zwischen Latency und Consistency. PACELC Theorem:
- If Partition (P): Choose A or C.
- Else (E = Normalbetrieb): Choose Latency or Consistency. DynamoDB ist ein PA/EL System (Priorisiert Availability und Low Latency).
2. Spanner
Google Spanner behauptet, ein CP-System zu sein, das "effektiv" CA ist. Wie? Durch ein privates Glasfasernetzwerk und Atomuhren (TrueTime). Sie minimieren die Wahrscheinlichkeit von P (Partition) so weit, dass sie C und A fast immer haben. Aber theoretisch gilt CAP immer noch.
1. Vector Clocks und Konfliktauflösung in AP
Cassandra oder Riak (AP-Systeme) haben keine Furcht vor dem Eventual Consistency Chaos, sondern managen es hart über Vector Clocks.
Wenn Knoten A offline geht, schreibt Client 1: Name=Alex (Vektor [A:1, B:0]). Gleichzeitig schreibt Client 2 auf Knoten B: Name=Alexander (Vektor [A:0, B:1]).
Kommt das Netzwerk (Partition) wieder hoch, syncen die Datenbanken sich. Statt stumpfem LWW (Last Writer Wins per Uhrzeit), das Uhren-Drifts zum Opfer fällt, sehen die Knoten Vektor-Konflikte. Meist zwingt die Datenbank dann die Applikation (den Microservice), den Konflikt via Custom-Code ("Sibling Resolution") beim nächsten Lese-Request fachlich zu mergen.
2. Spanner und der Traum von CA
Das CAP-Theorem verbietet echte CA-Systeme über Netzwerke. Google publizierte mit der weltweit verteilten Spanner-Datenbank nevertheless ein Statement, quasi "effektiv CA" zu sein. Google löst CAP nicht durch Algorithmen auf, sondern durch knallharte Physik. Sie bauen ihr massives Backbone-Glassfasernetz komplett privat und umgehen das offene Internet. Zusätzlich existiert TrueTime: Jedes Rechenzentrum weltweit hat hausscharfe GPS-Atomuhren an der Hardware. Durch die Garantie, dass die maximale Uhrenabweichung des Planeten global unter 7 ms fällt, erreichen Spanners Konsens-Algorithmen (Paxos) einen P-Ausfall nahe Null, wodurch C und A in 99,999% der Realität unzerstörbar garantiert erscheinen.
3. Proof by Network Partition: Das Split Brain Syndrom
In Distributed Systems ist das Split-Brain-Syndrom der Worst Case der "P"-Axe.
Drei Knoten arbeiten (Master, Rep 1, Rep 2). Der Switch dazwischen brennt ab. (Master) und (Rep 1 + Rep 2) sind getrennt. Da Master keine Heartbeats mehr an Rep 1+2 sendet, initialisieren die beiden eine Leader-Election. Einer der beiden proklamiert sich zum neuen Master.
Wenn das System auf Availability getrimmt ist (AP), schreiben User jetzt links und rechts Daten auf zwei isolierte Master. Das System spaltet sein "Gehirn". Kommt das Kabel wieder, crasht der Merge brutal. CP-Systeme lösen Split-Brain gnadenlos durch harte Quoren (Quorum): (Total Nodes / 2) + 1. Da der einsame Master die Stimmenregel 1 < 2 verfehlt, demissioniert er sofort selbstständig und bleibt unerreichbar (Opfert Availability zugunsten Konsistenz).
Quick-Check
CA?
Gibt es nicht in verteilten Systemen. Ein System, das nicht partitionstolerant ist (kein Netzwerk), ist eine einzelne Datenbank auf einem PC (Oracle). Sobald Netzwerk da ist, ist P unvermeidbar.Beweis?
Gilbert & Lynch haben es 2002 formal bewiesen. Es ist mathematisch unmöglich.Relation zu BASE?
BASE-Datenbanken wählen AP. ACID-Datenbanken wählen CP (oder CA im Single-Node-Fall).