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   . Doch im Laufe der Zeit entwickelte es sich weiter, erhielt einen formalen Beweis und entwickelte sich zum CAP-Theorem, wie wir es heute kennen. ACID und BASE  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   . Im CAP-Theorem bezieht es sich auf   oder   . Dies bedeutet, dass   , unabhängig davon, welcher Knoten die Anfrage verarbeitet. Dies bedeutet, dass jeder Lesevorgang den letzten Schreibvorgang widerspiegelt, unabhängig davon, welchen Knoten Sie abfragen. ACID-Transaktionen Linearisierbarkeit starke Konsistenz alle Knoten in einem verteilten System immer eine einzige, aktuelle Ansicht der Daten präsentieren müssen  💡 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   . Mit anderen Worten: Wenn ein fehlerfreier Knoten eine Anfrage erhält, muss er sie verarbeiten und beantworten. CAP   – es stellt nur sicher, dass der Knoten nicht unbemerkt ausfällt (beispielsweise könnten Knoten in   während einer Partitionierung mit veralteten Daten antworten, um die Verfügbarkeit sicherzustellen). jeder nicht ausfallende Knoten für jede empfangene Anfrage eine Antwort zurückgeben muss, unabhängig von Netzwerkpartitionen garantiert jedoch nicht, dass die Antwort immer „korrekt“ oder aktuell ist AP-Systemen  💡 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   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   . die Reaktionszeit (oder Timeouts) diesem Blogbeitrag  Partitionstoleranz   Bei der Partitionstoleranz geht es darum, Netzwerkausfälle zu überstehen.   Eine Partitionierung erfolgt, wenn Knoten aufgrund verlorener Pakete, Timeouts oder Netzwerkaufteilungen nicht kommunizieren können. Wenn Knoten aufgrund einer Netzwerkaufteilung (Partition) nicht kommunizieren können, muss das System je nach Designauswahl dennoch seine Konsistenz- oder Verfügbarkeitsgarantien erfüllen.  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   – 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. ist die Partitionstoleranz in jedem verteilten System nicht verhandelbar  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   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: Netzwerkpartitionierung    während der andere isoliert ist, weisen die beiden Teile inkonsistente Zustände auf. Dies führt zu einem Verlust von   . Wenn ein Teil des Systems Aktualisierungen akzeptiert, C (Konsistenz)    , 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   , da einige Anforderungen abgelehnt oder auf unbestimmte Zeit verzögert werden. Wenn das System konsistent bleiben möchte A (Verfügbarkeit)    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. Wenn das System verfügbar (A) und konsistent (C) bleiben möchte,    kann das System also nur   erfüllen. Sobald die Partition aufgelöst ist (d. h. die Knoten interagieren erneut), kann das System alle drei Eigenschaften wiedererlangen, aber   sind Kompromisse unvermeidlich. Während einer Partition zwei der drei Eigenschaften (C, A oder P) während der Partition selbst  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   und   – nur dann gelten, wenn tatsächlich   auftritt. Im Normalbetrieb, wenn das Netzwerk stabil ist und keine Partitionen vorhanden sind, gibt es keinen inhärenten Kompromiss zwischen Konsistenz und Verfügbarkeit. Konsistenz (C) Verfügbarkeit (A) eine Netzwerkpartition (P)  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   nicht berücksichtigt, obwohl Latenz und Partitionierung in der Praxis eng miteinander verbunden sind. Zum Beispiel: die Latenz  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   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. Timeout-Periode  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    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. Verfügbarkeit    hat verschiedene Stufen, von eventueller Konsistenz über kausale Konsistenz bis hin zu starker Konsistenz. Nicht jede Anwendung erfordert vollständige Linearisierbarkeit. Konsistenz    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). Die Partitionstoleranz  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.   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. Das von Daniel J. Abadi beschriebene PACELC-Theorem  PACELC führt zwei unterschiedliche Betriebsmodi für verteilte Systeme ein:    (   ): Welchen Kompromiss macht das System, wenn eine Partitionierung erfolgt? Hier betrachten wir noch einmal den klassischen CAP-Kompromiss zwischen   und   . Partitionsmodus PAC Verfügbarkeit (A) Konsistenz (C)    (   ): 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   und   .  Else-Modus ELC Latenz (L) 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   oft ein größerer Engpass als Netzwerkpartitionen, insbesondere bei Anwendungen im globalen Maßstab. Hier konzentriert sich   – 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   und   auszugleichen: die Latenz PACELC Latenz (L) Konsistenz (C)  Für   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. eine starke Konsistenz    (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. Systeme mit geringer Latenz  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.    bei der Entwicklung verteilter Systeme. Die Latenz ist ein vorrangiges Problem  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   zur Bewertung von Kompromissen und zum Verständnis der Grenzen verteilter Architekturen. mentale Modelle  Zusätzliche Materialien   CAP zwölf Jahre später: Wie sich die „Regeln“ geändert haben   Cassandra: Der ultimative Leitfaden    und  Bitte hören Sie auf, Datenbanken CP oder AP zu nennen 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   an oder folgen Sie mir über   ,   oder   . meinen Blog LinkedIn Substack Telegram

Subscribe

Buy My Book

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Zu lang; Lesen

Make resilience your competitive advantage

Warum verteilte Systeme nicht alles haben können

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Celebrating Our Tech Stories Community!

Starting 2025 with New Features: Settings Dashboard, HackerNoon Decoded, Updated Search UI, and More

HackerNoon Decoded 2024: Celebrating Our Life Hacking Community!

HackerNoon Decoded 2024: Celebrating Our Writing Community!

HackerNoon Decoded 2024: Celebrating Our Tech Stories Community!

Starting 2025 with New Features: Settings Dashboard, HackerNoon Decoded, Updated Search UI, and More

HackerNoon Decoded 2024: Celebrating Our Life Hacking Community!

HackerNoon Decoded 2024: Celebrating Our Writing Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps