Silna konsystencja: w razie potrzeby

Strong Consistency to model, w którym wszystkie operacje wyglądają jak wykonywane natychmiast i konsekwentnie w jednym globalnym porządku zgodnym z czasem rzeczywistym. Użytkownik przeczyta ostatnią potwierdzoną wartość, a dwóch równoległych klientów nie wyprzedzi się logicznie.

Ścisła spójność daje prosty model umysłowy i chroni twarde niezmienne, ale wymaga koordynacji (kworum/lidera), co zwiększa opóźnienie i wrażliwość na przegrody sieciowe.

1) Kiedy silny jest obowiązkowy

Finanse i rozliczenia

Salda i odpisy: „Podwójne wydatki” są niedopuszczalne.
Przelewy i rozliczenia: tej samej kwoty nie można opublikować dwukrotnie.

Zapasy i limity

Pozostałe towary/miejsca hotelowe/bilety: nie można przejść do wartości ujemnych.
Limity transakcji na jednostkę czasu (limity kredytowe, kredyty API).

Wyjątkowość i integralność

Unikalne logowania deduplicacyjne/identyfikatory/reguły.
Niezmienne na poziomie domeny: „≥ 1 lekarz musi być na dyżurze”, „nie może być> N aktywnych zadań w kolejce”.

Audyt i niezmienne dzienniki

Wydarzenia, które służą jako prawne źródło prawdy: porządek i kompletność są krytyczne.

Jeśli naruszenie niezmiennika niesie za sobą niedopuszczalne ryzyko biznesowe (utrata pieniędzy, sankcje, utrata zaufania) - wybierz Silną Spójność.

2) Co dokładnie jest „surowe”

linearyzability (poziom operacyjny): czytanie widzi najnowszy udany zapis; czasy są szanowane.
Serializowalny (poziom transakcji): wynik jest równoważny z wykonywaniem transakcji kolejno (może być silny, ale czasami realizowany bez trudnego zamówienia w czasie rzeczywistym).
Istotna różnica: Serializowalna chroni przed anomaliami na poziomie transakcji (fantom/write-skew), a Linearizable chroni przed pojedynczym momentem i kolejnością pojedynczych operacji. Często potrzebujesz obu właściwości (na przykład pieniędzy w bazie danych + dziennik zdarzeń).

3) Rygor cenowy: PACELC i CAP

PACELC: Podczas dzielenia sieci (P), trzeba wybrać C (rigor) lub A (dostępność). Silne → CP: lepiej odmówić lub zablokować niż naruszyć niezmienne. Gdy nie ma separacji (EL), płacimy z L - p95/p99 rośnie w koordynacji/kworums.
Praktyka: silne dla „jądra niezmiennych”, wokół - szybkie projekcje/bufory z ostatecznym, tak, że UX nie cierpi.

4) Jak silna jest spójność

Przywództwo i kworum

Jedyny lider akceptuje nagrania; czytanie - na lidera lub przez kworum replik.
Kworum 'W' do pisania i 'R' do czytania z 'R + W> N' improves szanse na czytanie „last”.

Dopasowanie algorytmów

Raft/Paxos: dziennik replikacji, potwierdzenie większości, termin/indeksy.
Replikacja synchroniczna - Rekord jest walidowany dopiero po utrzymaniu się kworum.

Godziny i zamówienie

• Czas/hybrydowe zegary logiczne (HLC): Ograniczenie niewłaściwości zegara w celu bezpiecznej globalnej serializacji.
Żetony ogrodzeniowe/wersioning: ochrona przed „porannymi” przywódcami i podziałami mózgu.

Izolacja transakcji

Serializowalne (SI + predykat conflict checking/lock): ochrona przed phantom/write-skew.
Ściśle serializowany: serializowalność + linearyzacja względem czasu rzeczywistego.

5) Multi-region: opcje i kompromisy

Globalny lider (CP)

Rekordy przechodzą przez jeden wiodący region; odczytuje - lokalne bufory/projekcje lub za pośrednictwem lidera.
Plusy: Prosty model. Minusy: p95/RTT do lidera, z P - blokady rekordowe.

Przywódcy regionalni + kworum synchroniczne

Rozszerzony geograficznie kworum z kilku regionów; każdy rekord czeka na potwierdzenie> 50%.
Plusy: bez pojedynczej „wąskiej szyi”, wysoka stabilność. Minusy: Opóźnienie międzykontynentalne.

Podział geograficzny

Dane domowe dla regionu (najemca/jurysdykcja); operacje globalne - poprzez sagi/agregaty.
Plusy: Niskie opóźnienia dla lokalnych nagrań. Minusy: Planowanie granic danych.

6) Skonfigurować R/W i odczytać

Wpisy: 'W = większość' jest standardem dla silnych.

• „Najświeższy” - 'R = większość' lub czytanie na lidera.
• Aby zmniejszyć L - „stale-ok” odczytuje z replik ekranów wtórnych (wyraźnie zaznaczone w UX).
• Odczyt/leasing: optymalizacja bez utraty wagi w przypadku krótkich dzierżaw lidera.

7) Wydajność i UX

Opóźnienie: Skupić się na RTT między klientem a liderem/kworum (międzyregionalnie setki ms).
„write-strong, read-fast” wzór: strong on write + cache/projection on reads, with RYW for author.
Partia/pakiety: Rekordy grupowe, ale uważaj na opóźnienia ogona.
Sprzeczności degradacji: w incydencie - tylko do odczytu, uczciwe statusy, zakaz niebezpiecznych mutacji.

8) Obserwowalność ścieżki ścisłej

Mierniki

p50/p95/p99 latency: pisać kworum, czytać kworum, odczyty przywództwa.
Sukces kworum, powtórki/rolki, zmiany lidera.
Opóźnienie replikacji (spodziewane małe, ale monitorowanie jest obowiązkowe).
Udział „steil” odczytuje (jeżeli jest włączony).

Odwzorowanie

Przęsła: „akceptacja przywódcy”, „replikacja”, „quorum commit”.
Тева: 'termin', 'leader _ id',' quorum _ size ',' region '.

Wpisy

Wzrost p95/p99, częsty lider reelekcji, kworum-timeouts, wskaźniki podziału mózgu.

9) Testy i chaos

Jepsen-like: partycje sieciowe, opóźnienia, krople, zegar-skew.
Niezmienne w zakresie bezpieczeństwa: brak możliwości podwójnych wydatków/ujemne salda/podwójna rezerwacja.
Przywództwo: odmowa przywódcy, reelekcja pod ładunkiem, żetony ogrodzeniowe.
Spójność odczytu: czytanie bezpośrednio po napisaniu powinno zobaczyć „nowe” (RYW/czytanie liniowe).

10) Playbooks incydentu

Utrata kworum: przełączyć się tylko do odczytu, powiadomić klientów, wysłać wpis do „home” region, jeśli geo-partycjonowanie jest obecny.
Wzrost opóźnień jest międzyregionalny: tymczasowo zmniejszyć objętość ścisłych rekordów (migracja niektórych strumieni w kolejce/projekcjach), zlokalizować ruch.
Klapa lidera: Zwiększ czas wyborów, sprawdź sieci/długie na godzinę dryfy/pauzy GC.
Split-brain: włączyć żetony ogrodzeniowe/dzierżawy, zatrzymać starych liderów na poziomie operatora.

11) Typowe błędy

Demand Strong „wszędzie”: eksplozja opóźnień i kosztów zamiast koncentrować się na niezmiennych.
Starając się być CA w prawdziwych podziałach: W punkcie P, system nadal dokonuje wyboru, często domyślnie.
Podwójne pisanie do różnych regionów bez sagi/koordynatora: fantomy i utrata stałych.
Brak RYW: użytkownik nie widzi nowo zarejestrowanego podmiotu - spadek zaufania.
Ignorowanie zegara: Bez granic HLC/Time, łatwo jest uzyskać „skoki” czas i wyścigi.
Nie ma planu degradacji: w P zaczynają się chaotyczne częściowe awarie.

12) Szybkie poprawki (przepisy)

Płatności/salda: lider + kworum większościowe; ściśle serializowane transakcje w krótkim czasie, ciężka awaria w P.
Rezerwacja (miejsca/sloty): write-strong przez lidera, czyta - cache z RYW; Rezerwy TTL + TCC.
Global SaaS: podział geograficzny według „najemcy/regionu”; ścisłe operacje w regionie macierzystym, raporty/wyszukiwanie - poprzez projekcje.
Audyt/dziennik: tylko do załączenia CP-log; odczyty mogą być buforowane, ale weryfikowane za pomocą punktów kontrolnych.

13) Lista kontrolna przedsprzedaży

• Napisano niezmienników wymagających silnych; reszta jest w AP/projekcji.
• Wybrano pojedynczego lidera/kworum międzyregionalnego/geo-partycji.
• Skonfigurowane 'W = majority', 'R = lider' majority 'dla ścieżek krytycznych.
• RYW/monotoniczne przewidziane dla UX; wyraźnie zaznaczone „stale-ok” czyta.
• W tym wskaźniki kworum, opóźnienia, opóźnienia; wpisy dotyczące p95/p99 i reelekcji.
• Istnieje plan degradacji: tylko do odczytu, wyłączanie niebezpiecznych mutacji, kolejki do „po burzy”.
• Testy chaosu: podziały, zegar-skew, awaria lidera; sprawdzono niezawodne środki bezpieczeństwa.
• Dokumentacja kontraktowa: co jest ścisłe, co „może być za”, komunikacja dla produktu/wsparcia.

Wnioski

Silna spójność jest narzędziem ochrony prawdy, gdzie błąd jest nie do przyjęcia. Zastosuj go wskazując wokół twardych niezmienników, świadomie płacąc za koordynację z opóźnieniem i dostępnością w burzach. Połączenie: jądro CP do odczytu krytycznego, odczytu AP i projekcji dla prędkości. Dzięki odpowiedniej telemetrii, degradacji i testom, zachowasz zarówno poprawność, jak i doświadczenie użytkownika.