Starke Consistency: Wenn nötig

Strong Consistency (Linearität) ist ein Modell, bei dem alle Operationen so aussehen, als würden sie sofort und konsistent in einer einzigen globalen Ordnung ausgeführt, die mit der realen Zeit übereinstimmt. Der Benutzer liest den letzten bestätigten Wert und die beiden parallelen Clients „überholen“ sich nicht logisch.

Strikte Konsistenz gibt ein einfaches mentales Modell und schützt starre Invarianten, erfordert jedoch Koordination (Quorum/Leader), was die Latenz und Empfindlichkeit gegenüber Netzwerkpartitionen erhöht.

1) Wenn Strong ein Muss ist

Finanzen und Kalkulationen

Bilanzen und Abschreibungen: Eine „doppelte Verschwendung“ ist unzulässig.
Überweisungen und gegenseitige Abrechnungen: Der gleiche Betrag kann nicht zweimal ausgeführt werden.

Inventar und Limits

Warenreste/Hotelplätze/Tickets: Sie können nicht in negative Werte gehen.
Transaktionslimits pro Zeiteinheit (Kreditlimits, API-Credits).

Einzigartigkeit und Integrität

Eindeutige Logins/IDs/Deduplizierungsregeln.
Invarianten auf Domänenebene: „Der ≥1 Arzt sollte in der Abteilung im Einsatz sein“, „Es kann keine> N aktiven Aufgaben in der Warteschlange geben“.

Audit und unveränderliche Protokolle

Ereignisse, die als rechtliche Quelle der Wahrheit dienen: Ordnung und Vollständigkeit sind kritisch.

Wenn die Verletzung der Invarianz ein inakzeptables Geschäftsrisiko birgt (Geldverlust, Sanktionen, Vertrauensverlust), wählen Sie Strong Consistency.

2) Was genau ist „streng“

Linearizability (operative Ebene): Lesen sieht den zuletzt erfolgreichen Eintrag; Zeiten respektiert werden.
Serializable (Transaktionsebene): Das Ergebnis entspricht der Ausführung von Transaktionen nacheinander (kann stark sein, wird aber manchmal ohne eine starre Echtzeit-Reihenfolge implementiert).
Ein wichtiger Unterschied: Serializable schützt vor Anomalien der Transaktionsebene (Phantom/Write-Skew) und Linearizable schützt vor der Momentanität und Reihenfolge einzelner Operationen. Oft werden beide Eigenschaften benötigt (z.B. Geld in der DB + Ereignisprotokoll).

3) Der Preis der Strenge: PACELC und CAP

PACELC: Wenn Sie das Netzwerk trennen (P), müssen Sie C (Strenge) oder A (Verfügbarkeit) wählen. Strong → CP: Es ist besser, abzulehnen oder zu blockieren, als die Invariante zu brechen. Wenn es keine Trennung gibt (EL), zahlen wir L - durch Koordination/Quorum wächst p95/p99.
Praxis: stark für den „Kern der Invarianten“, rundherum - schnelle Projektionen/Caches mit eventual, damit UX nicht leidet.

4) Wie Strong Consistency erreicht wird

Führung und Quorum

Der einzige Führer akzeptiert Aufzeichnungen; Lesungen - beim Führer oder im Quorum von Bemerkungen.
Das Quorum'W 'zum Schreiben und' R 'zum Lesen mit' R + W> N 'erhöht die Chancen, „Letzteres“ zu lesen.

Anpassungsalgorithmen

Raft/Paxos: Replikationsprotokoll, Mehrheitsbestätigungen, Begriff/Indizes.
Synchrone Replikation: Die Aufzeichnung wird erst nach Persistenz im Quorum bestätigt.

Uhr und Reihenfolge

TrueTime/Hybrid Logical Clocks (HLC): Beschränkung des Clock-Debugging für eine sichere globale Serialisierung.
Fence-Token/Versionierung: Schutz vor „Morgen“ -Führern und Split-Breen.

Transaktionen isolieren

Serializable (SI + Konfliktprüfung/Loks nach Prädikaten): Schutz vor Phantom/Write-Skew.
Strict-serializable: Serialisierbarkeit + Linearisierbarkeit relativ zu Echtzeit.

5) Multi-Region: Optionen und Kompromisse

Global Leader (CP)

Die Einträge laufen über eine Leader-Region; Lesen - lokale Caches/Projektionen oder durch den Führer.
Vorteile: einfaches Modell. Nachteile: p95/RTT zum Anführer, mit P - Blockierung von Datensätzen.

Regionale Führungskräfte + synchrones Quorum

Geo-expandiertes Quorum aus mehreren Regionen; jeder Eintrag wartet auf Bestätigungen> 50%.
Vorteile: ohne einen einzigen „schmalen Hals“, hohe Stabilität. Nachteile: interkontinentale Latenz.

Geo-partitioning

Daten „home“ für die Region (Tenant/Gerichtsbarkeit); globale Operationen - durch Sagas/Aggregate.
Vorteile: Geringe Latenz bei lokalen Einträgen. Nachteile: Planung von Datengrenzen.

6) Einstellung von R/W und Lesungen

Einträge:'W = majority 'ist der Standard für strong.

• Das „Frischeste“ ist das'R = majority 'oder die Lektüre beim Leader.
• Zur Reduzierung L - „stale-ok“ Lesen von Replikaten für kleinere Bildschirme (mit expliziten Markierungen in UX).
• Read-repair/lease read: Optimierung ohne Verlust der Strenge bei kurzen Lead-Leases.

7) Leistung und UX

Latenz: Fokus auf RTT zwischen Client und Leader/Quorum (interregional hunderte ms).
„write-strong, read-fast“ -Muster: stark auf Aufnahme + Cache/Projektionen auf Lesungen, mit RYW für den Autor.
Batch/Pakete: Gruppieren Sie die Einträge, aber achten Sie auf Schwanzlatenz.
Die Konturen der Degradation: beim Vorfall - read-only, die ehrlichen Zustände, das Verbot der gefährlichen Mutationen.

8) Beobachtbarkeit des Strict-Pfades

Metriken

p50/p95/p99 latency: write-quorum, read-quorum, leadership readings.
Erfolgsquoten, Wiederholungen/Pullbacks, Führungswechsel.
Replikationsfehler (erwartungsgemäß klein, aber unbedingt zu überwachen).
Anteil der „Steyl“ -Lesungen (falls enthalten).

Tracing

Die Spans: „Übernahme durch den Leader“, „Replikation“, „Beschlusskommit“.
Теги: `term`, `leader_id`, `quorum_size`, `region`.

Alerts

Wachstum p95/p99, häufige Wiederwahl des Führers, Quorum-Timeouts, Split-Brain-Indikatoren.

9) Tests und Chaos

Jepsen-like: Netztrennungen, Verzögerungen, Drops, Clock-Skew.
Sicherheitsinvarianten: Unmöglichkeit doppelter Ausgaben/negativer Salden/doppelter Buchungen.
Führung: Führungsverweigerung, Wiederwahl unter Belastung, Fence-Token.
Konsistenz der Lesungen: Das Lesen unmittelbar nach dem Schreiben sollte „neu“ (RYW/linearizable read) sehen.

10) Playbooks der Vorfälle

Verlust des Quorums: Wechseln Sie in Read-Only, benachrichtigen Sie die Kunden, leiten Sie den Eintrag an die „Home“ -Region weiter, wenn Geo-Partitionierung vorhanden ist.
Die Zunahme der Latenz interregional: vorübergehend reduzieren das Volumen der strengen Aufzeichnungen (Migration Teil der Ströme in der Warteschlange/Projektion), den Verkehr zu lokalisieren.
Leader-Flop: Wahlzeitpunkte erhöhen, Netzwerke/Stundendrifts/GC-Pausen prüfen.
Split-Brain: Aktivieren Sie Fence-Token/Lease-Checks, stoppen Sie alte Führer auf Betreiberebene.

11) Typische Fehler

Fordern Stark „überall“: Latenz- und Kostenexplosion statt Fokus auf Invarianten.
Versuchen Sie, CA mit echten Spaltungen zu sein: Zum Zeitpunkt P trifft das System immer noch Entscheidungen, oft implizit.
Dual-write zu verschiedenen Regionen ohne Sagen/Koordinator: Phantome und Verlust von Invarianten.
Mangel an RYW: Der Benutzer sieht seine neu aufgezeichnete Entität nicht - Vertrauensverlust.
Uhr ignorieren: Ohne HLC/TrueTime-Grenzen ist es einfach, „springende“ Zeit und Rennen zu bekommen.
Kein Abbauplan: Unter P beginnen chaotische Teilausfälle.

12) Schnelle Entscheidungen (Rezepte)

Zahlungen/Salden: Leader + Majority-Quorum; strict-serializable Transaktionen; kurze Timeouts, harter Ausfall bei P.
Buchung (Sitzplätze/Slots): schreibstark über Leader, Lesungen - Cache mit RYW; TTL-Reserven + TCC.
Global SaaS: Geo-Partition nach 'tenant/region'; strikter Betrieb in der Heimatregion, Berichte/Suche - durch Projektionen.
Audit/Protokoll: append-only CP-Protokoll; Lesungen können zwischengespeichert, aber mit Checkpoints verifiziert werden.

13) Checkliste vor dem Verkauf

• Invarianten, die strong erfordern, werden ausgeschrieben; der Rest ist in AR/Projektion.
• Modus ausgewählt: single leader/quorum interregional/geo-partition.
• Konfiguriert sind'W = majority','R = leader 'majority' für kritische Pfade.
• Zur Verfügung gestellt von RYW/monotonic für UX; deutlich markiert „stale-ok“ Lesen.
• Quorum-, Lag-, Latenzmetriken sind enthalten; Alerts auf p95/p99 und Wiederwahl.
• Es gibt einen Degrade-Plan: nur lesen, gefährliche Mutationen abschalten, Warteschlangen für „nach dem Sturm“.
• Chaos-Tests: Trennungen, Uhr-Skew, Versagen des Führers; Sicherheitsinvarianten geprüft.
• Vertragsdokumentation: Was ist streng, was kann „hinterherhinken“, Kommunikation für Produkt/Support.

Schlussfolgerung

Strong Consistency ist ein Instrument zum Schutz der Wahrheit, wo ein Fehler nicht akzeptabel ist. Wenden Sie es punktweise um starre Invarianten an und bezahlen Sie bewusst für die Koordination mit Latenz und Zugänglichkeit in Stürmen. Kombinieren: CP-Kern für kritisches, AP-Lesen und Projektion für Geschwindigkeit. Mit der richtigen Telemetrie, Degradation und Tests behalten Sie sowohl die Korrektheit als auch die Benutzererfahrung.