Modele de consistență

Consecvența descrie ce valori văd cititorii și în ce ordine în timpul schimbărilor competitive. Alegerea corectă a modelului este echilibrul dintre rigoarea invarianților, latență, disponibilitate și cost (PACELC). Mai jos este un ghid practic pentru modele și aplicarea lor.

1) modele „stricte”

Linearizable (Puternic)

Comportament ca în cazul în care toate operațiile au fost efectuate instantaneu într-o ordine uniformă care respectă în timp real.
Pro: model mental simplu, sigur pentru bani și unicitate.
Contra: cvorumuri/lider → creștere p95/p99, în special la nivel interregional.
Utilizați cazuri: solduri, inventar cu limite grele, nume/chei unice.

Consistență secvențială

Toate firele văd aceeași ordine a operațiunilor, dar ordinea în timp real nu este necesară. Puțin mai slab decât liniarizabil, rareori expuse direct în produse.

Serializabil

Echivalent cu unele ordine secvențială a tranzacțiilor (nu operațiuni individuale).
Pro: corectitudinea invarianților complexi la nivel de interogare/masă.
Contra: mai scump (blocarea/versionarea/validarea conflictelor).
Cazuri de utilizare: tranzacții financiare complexe, renumărări consistente, inventar.

Izolarea instantaneului (SI)

Fiecare tranzacție citește un instantaneu imuabil în timp; intrările intră în conflict pe „aceleași linii”, dar scrie skew este posibil.
Pro: citește rapid fără încuietori, rapoarte stabile.
Contra: nu serializabil, scrie capcana skew (exemplu: medici de serviciu).
Utilizați cazuri: analize, rapoarte, majoritatea CRUD-urilor fără invarianți duri.

2) Pe sesiune și garanții cauzale

Read-Your-Writes (RYW)

Clientul o vede întotdeauna în citirile ulterioare după intrarea sa.
Pro: bun UX (formular → confirmare).
Contra: garanție locală, nu globală.

Monotonic Citește/Scrie

Lecturile nu „se rostogolesc”; înregistrările unui client sunt aplicate în aceeași ordine ca și cele trimise.

Consistența cauzală

Dacă operațiunea depinde de un altul (A → B), toată lumea vede A înainte de B.
Pro: intuitiv pentru feed-uri sociale, comentarii.
Contra: Etichetele de rutare și cauzalitate (ceasuri vectoriale) sunt mai dificile.
Cheile utilizatorului: comunicații, editare comună, feed-uri de evenimente.

3) Modele slabe și hibride

Împietrire mărginită

Citește poate lag nu mai mult de Δ t sau versiuni N.
Pro: UX previzibil, bun compromis interregional.
Contra: Nu protejează împotriva conflictelor de scriere.

Eventuala consecventa

În timp, toate copiile converg; comanda și întârzierea nu sunt garantate.

Pro: Latență/cost minim, disponibilitate ridicată (AP)

Contra: Aveți nevoie de o îmbinare explicită (reguli CRDT/domeniu).
Utilizați cazuri: cache-uri, feed-uri, metrici, like-uri, directoare critice nen.

4) Anomalii tipice și ce înseamnă acestea

Citire murdară: citirea datelor neangajate.
Citire nerepetabilă: Aceeași citire dintr-o tranzacție oferă valori diferite.
Phantom: la cerere repetată, apare/dispare un șir care se potrivește cu predicatul.
Scrieți Skew (cu SI): două tranzacții citesc invariantul care se intersectează și scriu linii diferite, încălcând condiția „suma trebuie să fie ≥ 1”.
Actualizare pierdută: Înregistrarea „suprascrie” schimbările concurentului.

5) Cvorumuri și niveluri de citire/scriere

Multe magazine vă permit să setați nivelurile „R ”/„ W” (numărul de replici pentru a citi/scrie).

Cvorumul (R + W> N) oferă „intersecție” și garanții puternice de citiri ale ultimei înregistrări.
W = 1, R = 1 → latență scăzută, dar datele vechi sunt posibile.
Tuning: operațiuni critice - mare „W” (sau lider), restul - scăzut „R” pentru viteză.
Read-repair/Hinted handoff ajută la obținerea consistenței în fundal.

6) Ore și ordine: cum „înțelegem” cauzalitatea

Ceasuri cu lampă: ordinea parțială a evenimentelor.
Ceasuri vectoriale: remediați cauzalitatea, permiteți detectarea conflictelor.
Abordări hibride/TrueTime: limitați răspândirea ceasurilor în cluster pentru ordonarea tranzacțiilor și staleness-ul legat.
Versioning: 'versiune/ts + actor' pentru îmbinare; în CRDT, semigrupuri închise (comutativitate/idempotență).

7) CRDT și fuzionarea domeniului

CRDT (tipuri de date convergente/replicate) garantează convergența fără coordonare: G-Counter, OR-Set, LWW-Register, Map, text OT/WOOT variante.
Când este util: îi place, multe etichete, coșuri, documente.
Limitări: Veniți cu semantica corectă de „îmbinare” pentru o anumită entitate de domeniu.

8) Comunicarea cu PAC/PACELC

Modele stricte (Linearizable/Serializable) în multi-regiune → CP cu latență crescândă (PACELC: selectați C și plătiți L).
Modele slabe/hibride → AP și/sau low L, dar au nevoie de unificare/rezolvare a conflictelor.
Hibrid: kernel-ul CP pentru invarianți + proiecții AP/cache pentru citiri.

9) Selecția modelului: listă de verificare

1. Invarianți: ce nu ar trebui încălcat? (unicitate, echilibru, limite).
2. Regionalitate: Unde sunt scrise/citite? (local/global).
3. SLO după latență: p95/p99 pentru căi critice?
4. Preț de coordonare: gata să plătească cu cvorumuri interregionale?
5. Conflicte: Aveți o fuziune deterministă sau aveți nevoie de un coordonator?
6. Așteptările UX: RYW/monotonic/cauzal sunt importante pentru client?
7. Observabilitate: cum măsurați decalajul/conflictul/gradul de obsolescență?
8. Folback-uri: Ce se întâmplă atunci când o plasă este împărțită (P)? read-only/intrare locală/cozi?

10) Rețete rapide

Plata/sold: Linearizable/Serializable, leader + cvorum, scurte intervale de timp; Citiri RYW.
Profile/hrană pentru animale: Cauzal/Limitat staleness + cache; CRDT pentru likes/counts; RYW pentru autor.
Căutare/Analytics: SI/Read Committed, proiecții asincrone, eventual pentru indici.
Global SaaS: Geo-partiționare; "home records' - CP, rapoarte/directoare - AP.
Co-editare: cauzal/eventual + CRDT/OT; păstrarea „istoriei”.

11) Consistența observată

Lag metrics: 'replication _ lag', 'staleness _ age _ ms' (p50/p95/p99).
Conflict: procent de conflicte, timp mediu de rezolvare.
Cvorumuri: succesul cvorumurilor „R/W”, timeout-urile căilor interregionale.
Garanțiile clienților: RYW/monotonic - urme de etichete de sesiune.

12) Erori tipice

Exigent Puternic „peste tot” fără o bază de afaceri → o explozie de latență și costuri.
Scrierea duală în diferite regiuni fără sagas/CRDT → fantome și pierderea invarianților.
Ignorați RYW/monotonicitatea în UX → „lipsește” datele trimise.
Nu urmăriți îmbătrânirea cache-urilor/proiecțiilor → discrepanțele „eterne”.
Fuziune prost concepută → valori neașteptate pierdere/duplicat.

13) Arhitectura mini-referință

Write-core (CP): lider, înregistrări cvorum, SLO-uri și timeout-uri, jurnale.
Read-plane (AP): vizualizări materializate, cache-uri TTL, citire-reparare.
Client: sticky-session/session guarantes (RYW/monotonic), version labels.
Conflict motor: reguli CRDT/domeniu, coadă de decontare manuală.
Monitorizare: decalaje, conflicte, cote de lecturi învechite.

Concluzie

Un model de coerență este un contract de inginerie între date, latență și disponibilitate. Începeți cu invarianții și SLO-urile, alegeți strict unde aveți nevoie și mai slab unde puteți, fără a uita de garanțiile clienților, cvorumurile, orele și observabilitatea. O combinație competentă de modele oferă scară, predictibilitate și durabilitate - fără a sacrifica adevărul de afaceri și încrederea utilizatorilor.