Modele spójności
Spójność opisuje, jakie wartości widzą czytelnicy i w jakiej kolejności podczas zmian konkurencyjnych. Właściwym wyborem modelu jest równowaga między rygorystycznymi, opóźnieniami, dostępnością i kosztami (PACELC). Poniżej znajduje się praktyczny przewodnik po modelach i ich zastosowaniu.
1) Modele „ścisłe”
Linearyzacja (silna)
Zachowanie jakby wszystkie operacje były wykonywane natychmiast w jakiejś jednolitej kolejności, która szanuje czas rzeczywisty.
Plusy: prosty model psychiczny, bezpieczny dla pieniędzy i wyjątkowości.
Minusy: kworum/lider → wzrost p95/p99, szczególnie międzyregionalnie.
Użyj przypadków: salda, zapasy z twardymi limitami, unikalne nazwy/klucze.
Konsystencja sekwencyjna
Wszystkie wątki widzą tę samą kolejność operacji, ale zamówienie w czasie rzeczywistym nie jest wymagane. Nieco słabsze niż liniowalne, rzadko wystawiane bezpośrednio w produktach.
Możliwy do serializacji
Odpowiednik kolejności transakcji (nie poszczególnych operacji).
Plusy: poprawność złożonych niezmienników na poziomie zapytania/tabeli.
Minusy: droższe (blokowanie/wersioning/walidacja konfliktu).
Użyj przypadków: złożone transakcje finansowe, spójne obliczenia, inwentaryzacja.
Izolacja migawek (SI)
Każda transakcja odczytuje niezmienną migawkę w czasie; wpisy konfliktu na „tych samych liniach”, ale pisać skew jest możliwe.
Plusy: szybko czyta bez zamków, stabilne raporty.
Minusy: nie do serializacji, napisz pułapkę (przykład: lekarze na dyżurze).
Użyj przypadków: analityka, raporty, większość CRUD bez twardych niezmienników.
2) Gwarancje na sesję i gwarancje przyczynowe
Czytaj swoje pisma (RYW)
Klient zawsze widzi to w kolejnych odczytach po wpisie.
Plusy: dobry UX (formularz → potwierdzenie).
Minusy: lokalna gwarancja, nie globalna.
Monotoniczne odczyty/pisma
Odczyty nie „cofają się”; zapisy jednego klienta są stosowane w tej samej kolejności co te wysłane.
Spójność przyczynowa
Jeśli operacja zależy od innego (A → B), każdy widzi A przed B.
Plusy: intuicyjne na kanały towarzyskie, komentarze.
Minusy: Etykiety routingu i przyczynowości (zegary wektorowe) są trudniejsze.
Klucze użytkownika: komunikacja, wspólna edycja, kanały zdarzeń.
3) Słabe i hybrydowe modele
Ograniczona Stalowość
Odczyty mogą opóźniać się nie więcej niż w wersjach Na lub Na.
Plusy: przewidywalny UX, dobry kompromis międzyregionalny.
Wady: Nie chroni przed konfliktami pisania.
Ewentualna spójność
Z czasem wszystkie kopie zbiegają się; zamówienie i opóźnienie nie są gwarantowane.
Plusy: Minimalne opóźnienie/koszt, wysoka dostępność (AP)
Minusy: Potrzebujesz wyraźnego połączenia (reguły CRDT/domeny).
Użyj skrzynek: buforów, kanałów, mierników, lubi, nen katalogów krytycznych.
4) Typowe anomalie i co oznaczają
Brudny Read: czytanie danych niezbyt często.
Non-repeatable Read: Ten sam odczyt w ramach transakcji daje różne wartości.
Phantom: na powtarzające się żądanie pojawia się/znika ciąg pasujący do predykatu.
Napisz Skew (z SI): dwie transakcje przeczytać przecięcia niezmienne i zapisać różne linie, naruszając warunek „suma musi być ≥ 1”.
Lost Update: Rekord „nadpisuje” zmiany konkurenta.
5) Kworum i poziomy odczytu/zapisu
Wiele sklepów pozwala ustawić poziomy 'R '/' W' (liczba replik do odczytu/zapisu).
Kworum (R + W> N) daje „przecięcie” i mocne gwarancje odczytu ostatniego rekordu.
W = 1, R = 1 → niskie opóźnienie, ale stare dane są możliwe.
Dostrajanie: operacje krytyczne - wysoka „W” (lub lider), reszta - niska „R” dla prędkości.
Naprawa odczytu/Podpowiedź pomaga uzyskać spójność w tle.
6) Godziny i porządek: jak „rozumiemy” przyczynowość
Zegary Lamport: częściowy porządek wydarzeń.
Zegary wektorowe: naprawić przyczynowość, umożliwić wykrywanie konfliktów.
Podejście hybrydowo-czasowe: ograniczenie rozprzestrzeniania się zegarów w klastrze w celu zamawiania transakcji i ciągłości wiązania.
Wersioning: 'wersja/ts + aktor' do połączenia; w CRDT, zamknięte półgrupy (komutacyjność/idempotencja).
7) CRDT i fuzja domen
CRDT (typy danych konwertowanych/replikowanych) gwarantuje konwergencję bez koordynacji: G-Counter, OR-Set, LWW-Register, Map, text OT/WOOT variants.
Kiedy przydatne: lubi, wiele znaczników, kosze, dokumenty.
Ograniczenia: Wymyśl poprawną semantykę „scalania” dla konkretnego podmiotu domeny.
8) Komunikacja z WPR/PACELC
Rygorystyczne modele (linearyzable/serializable) w wielu regionach → CP z rosnącą opóźnieniem (PACELC: wybierz C i zapłać L).
Modele słabe/hybrydowe → AP i/lub low L, ale wymagają połączenia/rozwiązywania konfliktów.
Hybryda: jądro CP dla niezmienników + projekcje AP/bufory do odczytu.
9) Wybór modelu: lista kontrolna
1. Niezmiennicy: czego nie należy naruszać? (wyjątkowość, równowaga, granice).
2. Regionalność: Gdzie są pisma/odczyty wykonane? (lokalne/globalne).
3. SLO według opóźnienia: p95/p99 dla ścieżek krytycznych?
4. Cena koordynacyjna: gotowa do zapłaty za pomocą kworum międzyregionalnego?
5. Konflikty: Czy masz deterministyczne połączenie czy potrzebujesz koordynatora?
6. Oczekiwania UX: RYW/monotoniczne/przyczynowe są ważne dla klienta?
7. Obserwowalność: jak mierzyć opóźnienie/konflikt/stopień przestarzałości?
8. Folbacks: Co się dzieje, gdy sieć jest podzielona (P)? tylko do odczytu/lokalny wpis/kolejki?
10) Szybkie przepisy kulinarne
Płatność/saldo: linearyzable/serializable, leader + quorum, short timeouts; Odczyty RYW.
Profile/pasze: Przyczynowa/Ograniczona stalowość + pamięć podręczna; CRDT dla upodobań/liczeń; RYW dla autora.
Search/Analytics: SI/Read Committed, asynchroniczne projekcje, ewentualnie dla indeksów.
Global SaaS: Geo-partycjonowanie; „home records” - CP, raporty/katalogi - AP.
Współedytowanie: przyczynowe/ostateczne + CRDT/OT; zachowanie „historii”.
11) Obserwowana spójność
Mierniki lag: 'replikacja _ lag', 'staleness _ age _ ms' (p50/p95/p99).
Konflikt: odsetek konfliktów, średni czas rozwiązania.
Kworum: sukces kworum R/W, terminy ścieżek międzyregionalnych.
Gwarancje klienta: RYW/monotoniczne - znaczniki śladowe według sesji.
12) Typowe błędy
Wymagający silny „wszędzie” bez podstawy biznesowej → eksplozja opóźnień i kosztów.
Podwójne pisanie do różnych regionów bez sagi/CRDT → fantomy i utrata niezmienników.
Ignoruj RYW/monotoniczność w UX → „brakuje” dane właśnie wysłane.
Nie śledzić starzenia się buforów/projekcji → „wieczne” rozbieżności.
Źle poczęte połączenie → nieoczekiwane wartości strat/duplikatów.
13) Mini-wzorcowa architektura
Write-core (CP): leader, quorum records, SLO i timeouts, logs.
Czytaj-płaszczyzna (AP): zmaterializowane widoki, bufory TTL, odczyt-naprawa.
Klient: gwarancje sticky-session/session (RYW/monotoniczne), etykiety wersji.
Konflikt silnika: zasady CRDT/domeny, kolejka rozrachunku ręcznego.
Monitorowanie: opóźnienia, konflikty, akcje przestarzałych odczytów.
Wnioski
Model spójności jest umową inżynierską między danymi, opóźnieniami i dostępnością. Zacznij od niezmiennych i SLO, wybierz dokładnie tam, gdzie go potrzebujesz, a słabiej, gdzie możesz, nie zapominając o gwarancjach klienta, kworumach, godzinach i obserwowalności. Kompetentne połączenie modeli daje skalę, przewidywalność i trwałość - bez poświęcania prawdy biznesowej i zaufania użytkowników.