Konsistenzmodelle

Konsistenz beschreibt, welche Werte und in welcher Reihenfolge die Leser im Wettbewerbswandel sehen. Die richtige Wahl des Modells ist die Balance zwischen der Strenge der Invarianten, Latenz, Verfügbarkeit und Kosten (PACELC). Im Folgenden finden Sie einen praktischen Leitfaden zu Modellen und deren Anwendung.

1) „Strenge“ Modelle

Linearisierbar (Linearisierbarkeit, stark)

Es ist, als würden alle Operationen sofort in einer einzigen Reihenfolge ausgeführt, die die Echtzeit respektiert.
Vorteile: einfaches mentales Modell, sicher für Geld und Einzigartigkeit.
Nachteile: Quorum/Leader → p95/p99-Wachstum, insbesondere interregional.
Uscays: Salden, Inventar mit engen Grenzen, eindeutige Namen/Schlüssel.

Sequential consistency

Alle Threads sehen die gleiche Reihenfolge der Operationen, aber die Real-Time-Reihenfolge ist nicht erforderlich. Etwas schwächer als linearizable, selten direkt in Produkten ausgestellt.

Serializable (Transaktionale Serialisierbarkeit)

Entspricht einer sequentiellen Reihenfolge von Transaktionen (nicht einzelnen Transaktionen).
Vorteile: Korrektheit komplexer Invarianten auf Abfrage-/Tabellenebene.
Die Minus: teuerer (der Blockierung/wersionirowanije/Validation der Konflikte).
Yuzkays: komplexe Finoperationen, konsistente Neuberechnungen, Inventar.

Snapshot Isolation (SI)

Jede Transaktion liest eine unveränderliche Momentaufnahme im Laufe der Zeit; Datensätze stehen in Konflikt mit „gleichen Zeilen“, aber es ist möglich, skew zu schreiben.
Vorteile: Schnelle Lesungen ohne Sperren, stabile Berichte.
Nachteile: nicht serialisierbar, Schreibfalle skew (Beispiel: diensthabende Ärzte).
Yuzkays: Analysen, Berichte, die meisten CRUDs ohne harte Invarianten.

2) Pro-Sitzung und kausale Garantien

Read-Your-Writes (RYW)

Der Kunde sieht es nach seiner Aufnahme immer in nachfolgenden Lesungen.
Vorteile: gute UX (Form → Bestätigung).
Nachteile: lokale Garantie, nicht global.

Monotonic Reads / Writes

Lesungen werden nicht „zurückgerollt“; Datensätze eines Kunden werden in der gleichen Reihenfolge wie die gesendeten Datensätze angewendet.

Kausale Consistency

Wenn die Operation von einer anderen (A → B) abhängt, sieht jeder A vor B.
Vorteile: Intuitiv für Soc-Feeds, Kommentare.
Nachteile: Schwieriges Routing und Kausalitätsmarkierungen (Vektoruhren).
Uzkays: Kommunikation, gemeinsame Bearbeitung, Event-Feeds.

3) Schwache und hybride Modelle

Bounded Staleness

Lesungen können nicht mehr als Δ t oder N Versionen zurückbleiben.
Vorteile: vorhersehbare UX, guter Kompromiss überregional.
Nachteile: schützt nicht vor Schreibkonflikten.

Eventual Consistency

Im Laufe der Zeit konvergieren alle Kopien; Reihenfolge und Verzögerung sind nicht garantiert.
Vorteile: minimale Latenz/Kosten, hohe Verfügbarkeit (AP).
Nachteile: Sie benötigen eine explizite Merge (CRDT/Domain Rules).
Uscays: Caches, Feeds, Metriken, Likes, Nen kritische Nachschlagewerke.

4) Typische Anomalien und was sie bedeuten

Dirty Read: Lesen Sie ungesicherte Daten.
Non-repeatable Read: Das gleiche Lesen innerhalb einer Transaktion ergibt unterschiedliche Werte.
Phantom: Wenn Sie erneut gefragt werden, erscheint/verschwindet eine Zeile, die dem Prädikat entspricht.
Write Skew (bei SI): Zwei Transaktionen lesen die sich überschneidende Invariante und schreiben verschiedene Zeilen, wodurch die Bedingung „die Summe muss ≥ 1 sein“ verletzt wird.
Lost Update: Der Eintrag „verwischt“ die Änderungen des Konkurrenten.

5) Quoren und Lese-/Schreibstufen

In vielen Speichern können Sie die Ebenen'R '/' W'(Anzahl der Lese-/Schreibreplikate) festlegen.

Das Quorum (R + W> N) gibt „Schnittmenge“ und starke Garantien für die Lesungen des letzten Eintrags.
W = 1, R = 1 → geringe Verzögerung, aber alte Daten sind möglich.
Tuning: Kritische Operationen sind hoch'W'(oder Führer), der Rest ist niedrig'R 'für Geschwindigkeit.
Read-repair/Hinted handoff hilft, Konsistenz im Hintergrund zu erreichen.

6) Uhr und Ordnung: Wie wir Kausalität „verstehen“

Lamportglocken: Teilreihenfolge der Ereignisse.
Vektorglocken: erfassen Kausalität, ermöglichen die Erkennung von Konflikten.
Hybrid/TrueTime-Ansätze: Begrenzen Sie die Taktstreuung in einem Cluster, um Transaktionen und Bound-Staleness zu ordnen.
Versionierung: 'version/ts + actor' für merge; in CRDT - geschlossene Halbgruppen (Kommutativität/Idempotenz).

7) CRDT und Domain Merge

CRDTs (Converged/Replizable Data Types) garantieren Konvergenz ohne Koordination: G-Counter, OR-Set, LWW-Register, Map, Text OT/WOOT-Varianten.
Wenn nützlich: Likes, viele Tags, Einkaufswagen, Dokumente.
Einschränkungen: Entwickeln Sie eine korrekte „Merge“ -Semantik für eine bestimmte Domäneneinheit.

8) Kommunikation mit CAP/PACELC

Strenge Modelle (Linearizable/Serializable) in der Multiregion → CP mit Latenzwachstum (PACELC: C wählen und L zahlen).
Schwache/hybrid-Modelle → AP und/oder low-L, aber brauchen merge/conflict-resolve.
Hybrid: CP-Kern für Invarianten + AP-Projektionen/Caches für Lesungen.

9) Modellauswahl: Checkliste

1. Invarianten: Was darf nicht verletzt werden? (Einzigartigkeit, Balance, Grenzen).
2. Regionalität: Wo werden Schreib-/Lesungen durchgeführt? (lokal/global).
3. SLO nach Latenz: p95/p99 für kritische Pfade?
4. Koordinationskosten: Bereit, mit überregionalen Quorum zu zahlen?
5. Konflikte: Gibt es eine deterministische Merge oder wird ein Koordinator benötigt?
6. UX-Erwartungen: RYW/monotonic/causal für den Kunden wichtig?
7. Beobachtbarkeit: Wie misst man Lag/Konflikthaftigkeit/Grad der Obsoleszenz?
8. Folbacks: Was passiert, wenn ein Netzwerk geteilt wird (P)? read-only/lokaler Eintrag/Warteschlangen?

10) Schnelle Rezepte

Zahlung/Balance: Linearizable/Serializable, Leader + Quorum, kurze Timeouts; RYW-Lesungen.
Profile/Feed: Causal/Bounded staleness + Cache; CRDT für Likes/Zähler; RYW für den Autor.
Suche/Analyse: SI/Read Committed, asynchrone Projektionen, eventual für Indizes.
Global SaaS: Geo-Partitionierung; „home records“ - CP, Berichte/Verzeichnisse - AP.
Co-Editing: kausal/eventual + CRDT/OT; Erhaltung der „Geschichte“.

11) Beobachtbarkeit der Konsistenz

Schlagzahl: 'replication _ lag', 'staleness _ age _ ms' (p50/p95/p99).
Konflikthaftigkeit: Anteil der Konflikte, durchschnittliche Lösungszeit.
Quorums: Erfolg der 'R/W' Quorums, Zeiträume der interregionalen Wege.
Kundengarantien: RYW/monotonic - Trace-Tags nach Session.

12) Typische Fehler

Fordern Sie Strong „überall“ ohne Geschäftsgrundlage → eine Explosion von Latenz und Kosten.
Dual-write zu verschiedenen Regionen ohne Sagen/CRDT → Phantome und Verlust von Invarianten.
Ignorieren RYW/monotonicity in UX → „Verlust“ der gerade gesendeten Daten.
Verfolgen Sie nicht die Veralterung von Caches/Projektionen → „ewige“ Diskrepanzen.
Unüberlegte Merge → unerwartete Verluste/Doppelwerte.

13) Mini-Referenz der Architektur

Write-Core (CP): Leader, Quorum Records, SLOs und Timeouts, Logs.
Read-plane (AP): materialisierte Ansichten, TTL-Caches, Read-Repair.
Kunde: Sticky-Session/Session-Garantien (RYW/monotonic), Versionsbeschriftungen.
Konflikt-Engine: CRDT/Domain-Regeln, manuelle Abrechnung Warteschlange.
Monitoring: Verzögerungen, Konflikte, Anteile veralteter Lesungen.

Schlussfolgerung

Ein Konsistenzmodell ist ein Engineering-Vertrag zwischen Daten, Latenz und Verfügbarkeit. Beginnen Sie mit Invarianten und SLOs, wählen Sie streng dort, wo Sie müssen, und schwächer, wo Sie können, ohne die Kundengarantien, Quorums, Stunden und Beobachtbarkeit zu vergessen. Eine kompetente Kombination von Modellen gibt Maßstab, Vorhersehbarkeit und Nachhaltigkeit - ohne die Geschäftswahrheit und das Vertrauen der Nutzer zu opfern.