Warum verteilte Systeme nicht alles haben können

Bei modernen verteilten Systemen geht es immer um Kompromisse. Leistung, Zuverlässigkeit, Skalierbarkeit und Konsistenz gibt es nicht umsonst – irgendwo zahlt man immer einen Preis. Hier kommt das CAP-Theorem ins Spiel: Es ist der Ausgangspunkt zum Verständnis der unvermeidlichen Kompromisse beim verteilten Design.

Warum ist das CAP-Theorem wahr? Was erklärt es eigentlich? Und vor allem: Ist es ausreichend? In diesem Beitrag untersuchen wir das CAP-Theorem, seine Grenzen, die Kritik, der es ausgesetzt war, und wie neuere Ideen wie PACELC die Diskussion voranbringen. Lassen Sie uns eintauchen.

CAP-Theorem

Die erste Version des CAP-Theorems begann als Debatte zwischen ACID und BASE . Doch im Laufe der Zeit entwickelte es sich weiter, erhielt einen formalen Beweis und entwickelte sich zum CAP-Theorem, wie wir es heute kennen.

Das CAP-Theorem besagt, dass ein verteiltes System höchstens zwei von drei Eigenschaften gleichzeitig erfüllen kann :

• Konsistenz
• Verfügbarkeit
• Partitionstoleranz

Diese Einschränkung zwingt Ingenieure dazu, je nach den Systemzielen und den Realitäten ihrer verteilten Umgebungen schwierige Kompromisse einzugehen.

Konsistenz

Konsistenz in CAP ist nicht dasselbe wie Konsistenz in ACID-Transaktionen . Im CAP-Theorem bezieht es sich auf Linearisierbarkeit oder starke Konsistenz . Dies bedeutet, dass alle Knoten in einem verteilten System immer eine einzige, aktuelle Ansicht der Daten präsentieren müssen , unabhängig davon, welcher Knoten die Anfrage verarbeitet. Dies bedeutet, dass jeder Lesevorgang den letzten Schreibvorgang widerspiegelt, unabhängig davon, welchen Knoten Sie abfragen.

💡 Konsistenz in ACID hingegen konzentriert sich darauf, sicherzustellen, dass eine Transaktion die Datenbank von einem gültigen Zustand in einen anderen gültigen Zustand bringt, und zwar gemäß den im Datenbankschema definierten Regeln. Es geht eher darum, Integritätsbeschränkungen (wie Fremdschlüssel, eindeutige Beschränkungen usw.) durchzusetzen und sicherzustellen, dass die Datenbank auch bei Abstürzen nicht in einem ungültigen Zustand verbleibt.

Verfügbarkeit

Verfügbarkeit in CAP bedeutet, dass jeder nicht ausfallende Knoten für jede empfangene Anfrage eine Antwort zurückgeben muss, unabhängig von Netzwerkpartitionen . Mit anderen Worten: Wenn ein fehlerfreier Knoten eine Anfrage erhält, muss er sie verarbeiten und beantworten. CAP garantiert jedoch nicht, dass die Antwort immer „korrekt“ oder aktuell ist – es stellt nur sicher, dass der Knoten nicht unbemerkt ausfällt (beispielsweise könnten Knoten in AP-Systemen während einer Partitionierung mit veralteten Daten antworten, um die Verfügbarkeit sicherzustellen).

💡 Eric Brewer (der ursprüngliche Autor von CAP) beschrieb diese Eigenschaft ursprünglich etwas flexibler als: „Fast alle Abfragen sollten eine Antwort erhalten“. Im formellen Nachweis von CAP wurde die Verfügbarkeit jedoch strenger formuliert und verlangt, dass „jede Abfrage eine Antwort erhält, solange der Knoten, der sie verarbeitet, in Ordnung ist“.

In der Praxis ist die Verfügbarkeit jedoch keine absolute Garantie – sie hängt oft von systemspezifischen Einschränkungen ab, beispielsweise davon, wie lange Sie bereit sind, auf eine Antwort zu warten. Bei realen Systemen spielt die Reaktionszeit (oder Timeouts) eine entscheidende Rolle bei der Gestaltung Ihres SLA (Service-Level-Agreements), auch wenn CAP selbst die Latenz nicht direkt berücksichtigt. Weitere Informationen dazu finden Sie in diesem Blogbeitrag .

Partitionstoleranz

Bei der Partitionstoleranz geht es darum, Netzwerkausfälle zu überstehen. Wenn Knoten aufgrund einer Netzwerkaufteilung (Partition) nicht kommunizieren können, muss das System je nach Designauswahl dennoch seine Konsistenz- oder Verfügbarkeitsgarantien erfüllen. Eine Partitionierung erfolgt, wenn Knoten aufgrund verlorener Pakete, Timeouts oder Netzwerkaufteilungen nicht kommunizieren können.

Verteilte Systeme leben nicht in einer Märchenwelt mit perfekten Netzwerken. Pakete gehen verloren, es kommt zu Timeouts und Latenzspitzen sind unvermeidbar. Aus diesem Grund ist die Partitionstoleranz in jedem verteilten System nicht verhandelbar – Partitionen werden früher oder später auftreten, Sie können sich also nicht dafür entscheiden, sie zu ignorieren, egal wie verlockend es klingen mag.

Bei CAP bedeutet Partitionstoleranz nicht, dass das System weiterläuft, als wäre nichts passiert. Es bedeutet, dass das System entscheiden muss, ob während einer Partitionierung die Verfügbarkeit (AP) oder die Konsistenz (CP) priorisiert werden soll. Wenn Sie die Partitionstoleranz ignorieren würden, würden Sie im Wesentlichen ein nicht verteiltes monolithisches System erstellen.

GAP erklärt

Am einfachsten lässt sich CAP anhand einer Netzwerkpartitionierung verstehen – einer Situation, in der zwei Teile eines verteilten Systems nicht miteinander kommunizieren können. In einem solchen Szenario gibt es für das System drei mögliche Ergebnisse:

1. Wenn ein Teil des Systems Aktualisierungen akzeptiert, während der andere isoliert ist, weisen die beiden Teile inkonsistente Zustände auf. Dies führt zu einem Verlust von C (Konsistenz) .
2. Wenn das System konsistent bleiben möchte , muss es Aktualisierungen in einem oder beiden Teilen der Partition blockieren, um einen einheitlichen Zustand über alle Knoten hinweg sicherzustellen. Dies führt zu einem Verlust von A (Verfügbarkeit) , da einige Anforderungen abgelehnt oder auf unbestimmte Zeit verzögert werden.
3. Wenn das System verfügbar (A) und konsistent (C) bleiben möchte, ohne die Partitionierung (P) zu tolerieren, ist es nicht wirklich verteilt. Dies würde erfordern, dass die Knoten interagieren und ihren Status abgleichen, was während einer Partitionierung unmöglich ist.

Während einer Partition kann das System also nur zwei der drei Eigenschaften (C, A oder P) erfüllen. Sobald die Partition aufgelöst ist (d. h. die Knoten interagieren erneut), kann das System alle drei Eigenschaften wiedererlangen, aber während der Partition selbst sind Kompromisse unvermeidlich.

Implikationen des Theorems

Eine Konsequenz des Theorems für asynchrone Systeme ist, dass nur drei Kombinationen von Konsistenz, Verfügbarkeit und Partitionstoleranz möglich sind:

AP (Verfügbarkeit + Partitionstoleranz)

Systeme dieser Art reagieren auf Anfragen, aber die zurückgegebenen Daten sind möglicherweise nicht immer auf dem neuesten Stand. Die Aktualisierung der Daten erfolgt langsamer, ist aber „immer“ verfügbar. Beispiele für ein solches System sind DNS, DynamoDB und Cassandra.

CP (Konsistenz + Partitionstoleranz)

Systeme dieses Typs geben immer aktuelle Daten zurück, aber einige oder sogar alle Knoten im System reagieren möglicherweise nicht, wenn sie partitioniert sind. Es gibt atomare Updates, kann aber zu Timeouts führen. NoSQL-Datenbanken wie Google BigTable, MongoDB, HBase und Redis sind allesamt Systeme dieses Typs.

CA (Konsistenz + Verfügbarkeit)

Systeme dieser Art liefern immer aktuelle Daten, wenn keine Partitionen vorhanden sind. Aufgrund der letzten Einschränkung werden solche Systeme normalerweise nur innerhalb einer Maschine verwendet. Beispiele sind klassische relationale Datenbanken.

In Wirklichkeit müssen wir uns zwischen CP und AP entscheiden, weil CA im Grunde ein Monolith ohne Partitionen ist. Bei großen Systemen können Designer nicht auf P verzichten und haben daher eine schwierige Wahl zwischen C und A.

In CA bedeutet ein Knotenausfall die vollständige Nichtverfügbarkeit des Dienstes. Dies verhindert jedoch nicht die Skalierbarkeit, da wir unabhängige Monolithen klonen und die Last auf sie verteilen können.

Kritik des CAP-Theorems

Das CAP-Theorem ist ein grundlegendes Konzept in verteilten Systemen, aber es hat auch seine Grenzen. Obwohl es die Idee von Kompromissen klar darstellt, wurde das CAP-Theorem oft dafür kritisiert, dass es komplexe Realitäten zu stark vereinfacht, was zu Missverständnissen und Fehlanwendungen geführt hat.

1. Kompromisse gelten nur bei Partitionen

Einer der häufigsten Kritikpunkte ist, dass die Kompromisse des CAP-Theorems – die Wahl zwischen Konsistenz (C) und Verfügbarkeit (A) – nur dann gelten, wenn tatsächlich eine Netzwerkpartition (P) auftritt. Im Normalbetrieb, wenn das Netzwerk stabil ist und keine Partitionen vorhanden sind, gibt es keinen inhärenten Kompromiss zwischen Konsistenz und Verfügbarkeit.

Darüber hinaus sind diese Kompromisse nicht für das gesamte System universell. Innerhalb desselben verteilten Systems:

• In verschiedenen Teilen des Systems kann es je nach Kontext (wie etwa Benutzerstandort, Datentyp) zu unterschiedlichen Kompromissen kommen.
• Bei bestimmten Vorgängen steht möglicherweise die Konsistenz im Vordergrund, während für andere die Verfügbarkeit im Vordergrund steht.
• Entscheidungen können zur Laufzeit je nach Faktoren wie Auslastung, Latenz oder Benutzeranforderungen variieren.

Diese Nuance geht in hochrangigen Diskussionen über CAP oft verloren, was zu einer pauschalen, vereinfachten Klassifizierung der Systeme als „CP“ oder „AP“ führt.

2. CAP ignoriert Latenz

Ein weiterer wichtiger Kritikpunkt ist, dass das CAP-Theorem die Latenz nicht berücksichtigt, obwohl Latenz und Partitionierung in der Praxis eng miteinander verbunden sind. Zum Beispiel:

• Ein langsames Netzwerk (hohe Latenz) lässt sich scheinbar nicht von einer Partition unterscheiden.
• Timeouts, die zur Erkennung von Fehlern verwendet werden, sind subjektiv und hängen stark vom Systemdesign und den Netzwerkbedingungen ab. Was ein System als „Partition“ definiert, kann für ein anderes nur eine vorübergehende Verzögerung sein.

In realen verteilten Systemen muss das System bei einer Partitionierung oder hohen Latenz innerhalb einer Timeout-Periode eine Entscheidung treffen: Verfügbarkeit priorisieren, indem möglicherweise ein veraltetes Ergebnis zurückgegeben wird, oder Konsistenz priorisieren, indem länger gewartet wird (und möglicherweise keine Antwort erfolgt). Die binäre Ansicht von CAP erfasst die Komplexität dieser Entscheidungen nicht.

3. CAP-Eigenschaften sind nicht binär

Das CAP-Theorem stellt Konsistenz, Verfügbarkeit und Partitionstoleranz als binäre Eigenschaften dar – entweder man hat sie oder man hat sie nicht. In der Praxis existieren jedoch alle drei Eigenschaften auf einem Spektrum :

• Verfügbarkeit ist keine binäre „Ein/Aus“-Eigenschaft, sondern reicht von 0 % bis 100 %. Ein System kann beispielsweise eine Verfügbarkeit von 99,99 % garantieren, aber trotzdem kurze Zeiträume der Nichtverfügbarkeit zulassen.
• Konsistenz hat verschiedene Stufen, von eventueller Konsistenz über kausale Konsistenz bis hin zu starker Konsistenz. Nicht jede Anwendung erfordert vollständige Linearisierbarkeit.
• Die Partitionstoleranz selbst ist kein eindeutiges Ereignis. Systeme können sich nicht darüber einig sein, ob eine Partition vorhanden ist (z. B. betrachtet ein Knoten ein Timeout als Fehler, während ein anderer normal weiterarbeitet).

Aufgrund der kontinuierlichen Natur der Eigenschaften ist CAP für die Modellierung der Komplexität moderner verteilter Systeme zu simpel.

PACELC-Theorem

Obwohl CAP unser Verständnis von Kompromissen in verteilten Systemen revolutioniert hat, ist es nicht das letzte Wort zu diesem Thema. Das von Daniel J. Abadi beschriebene PACELC-Theorem gilt als alternativer Ansatz für den Entwurf verteilter Systeme. Es basiert auf dem CAP-Modell, berücksichtigt aber neben Konsistenz, Verfügbarkeit und Partitionstoleranz auch Latenz und logische Ausschlüsse zwischen Kombinationen dieser Konzepte.

PACELC führt zwei unterschiedliche Betriebsmodi für verteilte Systeme ein:

1. Partitionsmodus ( PAC ): Welchen Kompromiss macht das System, wenn eine Partitionierung erfolgt? Hier betrachten wir noch einmal den klassischen CAP-Kompromiss zwischen Verfügbarkeit (A) und Konsistenz (C) .
2. Else-Modus ( ELC ): Welchen Kompromiss macht das System, wenn keine Partition vorhanden ist und das Netzwerk normal funktioniert? In diesem Modus muss das System einen anderen Kompromiss eingehen – zwischen Latenz (L) und Konsistenz (C) .

Der Kompromiss zwischen Latenz und Konsistenz

Obwohl Partitionen in verteilten Systemen unvermeidlich sind, sind sie im Vergleich zu den Herausforderungen, die während des normalen Betriebs auftreten, selten. In modernen verteilten Systemen ist die Latenz oft ein größerer Engpass als Netzwerkpartitionen, insbesondere bei Anwendungen im globalen Maßstab. Hier konzentriert sich PACELC – indem es die Kompromisse berücksichtigt, die auftreten, wenn das System ohne Partitionen betrieben wird. Im Gegensatz zu CAP, das sich ausschließlich auf das Verhalten während Fehlerszenarien konzentriert, betont PACELC die Entscheidungen, die Architekten täglich treffen müssen, um Latenz (L) und Konsistenz (C) auszugleichen:

• Für eine starke Konsistenz ist eine Koordination und Synchronisierung zwischen Knoten erforderlich, um eine einheitliche Ansicht der Daten zu gewährleisten. Dieser Mehraufwand führt zu Verzögerungen und verlängert die Reaktionszeiten.
• Systeme mit geringer Latenz (wie solche mit letztendlicher Konsistenz) priorisieren die Geschwindigkeit, indem sie Konsistenzgarantien lockern. Diese Systeme reagieren schneller, können aber gelegentlich veraltete oder inkonsistente Daten zurückgeben.

Indem PACELC den Dialog über Partitionen hinaus auf den Normalbetrieb ausweitet, stellt es sicher, dass der Alltagsleistung verteilter Systeme die Bedeutung beigemessen wird, die sie verdient.

Verpacken

Die Formulierung des CAP-Theorems war ein bedeutendes Ereignis in der Gemeinschaft, und Studien zu seinen Auswirkungen auf den Entwurf verteilter Systeme haben gezeigt, dass Designer verteilter Systeme das System nicht auf zwei Eigenschaften beschränken sollten - sie sollten danach streben, die in jedem Einzelfall erforderlichen Garantien zu maximieren. Zu diesem Zweck ist es sinnvoll, das System in Segmente aufzuteilen, von denen jedes seine eigenen Anforderungen hat, und das System basierend auf den Anforderungen jedes einzelnen Segments zu entwerfen.

Das CAP-Theorem ist seit Jahrzehnten ein Eckpfeiler des Denkens über verteilte Systeme. Es gab uns einen Rahmen, um über die inhärenten Kompromisse zwischen Konsistenz, Verfügbarkeit und Partitionstoleranz nachzudenken. Aber in vielerlei Hinsicht ist es eine Vereinfachung der Realität, da es binäre Entscheidungen annimmt und kritische Faktoren wie Latenz ignoriert.

PACELC baut auf CAP auf und erkennt Folgendes an:

• Es bestehen Kompromisse, auch wenn dies bei Partitionen nicht der Fall ist.
• Die Latenz ist ein vorrangiges Problem bei der Entwicklung verteilter Systeme.

Sowohl CAP als auch PACELC sind wertvolle Tools, aber keines von beiden ist ein Schritt-für-Schritt-Rezept zum Erstellen von Systemen. Stattdessen bieten sie mentale Modelle zur Bewertung von Kompromissen und zum Verständnis der Grenzen verteilter Architekturen.

Zusätzliche Materialien

• CAP zwölf Jahre später: Wie sich die „Regeln“ geändert haben
• Cassandra: Der ultimative Leitfaden
• Bitte hören Sie auf, Datenbanken CP oder AP zu nennen und Eine Kritik des CAP-Theorems von Martin Kleppmann
• Hinweise zu verteilten Systemen für Young Bloods

Vielen Dank fürs Lesen!

Sind Sie neugierig auf etwas oder möchten Sie Ihre Gedanken mit uns teilen? Hinterlassen Sie unten Ihren Kommentar! Sehen Sie sich meinen Blog an oder folgen Sie mir über LinkedIn , Substack oder Telegram .