Consistență puternică: Când este nevoie

Consistența puternică este un model în care toate operațiunile arată ca și cum ar fi efectuate instantaneu și consecvent într-o singură ordine globală în concordanță cu timpul real. Utilizatorul va citi ultima valoare confirmată, iar doi clienți paraleli nu se vor depăși logic unul pe celălalt.

Consistența strictă oferă un model mental simplu și protejează invarianții duri, dar necesită coordonare (cvorumuri/lider), ceea ce crește latența și sensibilitatea la partițiile de rețea.

1) Când Strong este obligatorie

Finanţe şi decontări

Balanțe și reduceri: „Cheltuieli duble” este inacceptabil.
Transferuri și decontări: aceeași sumă nu poate fi afișată de două ori.

Inventar și limite

Bunuri rămase/spațiu hotelier/bilete: nu puteți intra în valori negative.
Limite de tranzacție pe unitate de timp (limite de credit, credite API).

Unicitate și integritate

Login-uri/ID-uri/reguli unice de eliminare a duplicatelor.
Invarianți la nivel de domeniu: „≥1 medic trebuie să fie de serviciu în departament”, „nu pot exista> N sarcini active în coadă”.

Busteni de audit si neschimbare

Evenimentele care servesc drept sursă legală a adevărului: ordinea și exhaustivitatea sunt critice.

Dacă încălcarea invariantului prezintă un risc de afaceri inacceptabil (pierderea de bani, sancțiuni, pierderea încrederii) - alegeți Consistența puternică.

2) Ce este exact "strict'

Liniarizabilitate (nivel operațional): lectura vede cea mai recentă scriere de succes; timpurile sunt respectate.
Serializabil (nivel tranzacție): rezultatul este echivalent cu executarea tranzacțiilor secvențial (poate fi puternic, dar uneori implementat fără o ordine greu în timp real).
O diferență importantă: Serializable protejează împotriva anomaliilor la nivel de tranzacție (phantom/write-skew), iar Linearizable protejează împotriva unei singure instantaneități și a ordinii operațiunilor unice. De multe ori aveți nevoie de ambele proprietăți (de exemplu, bani în baza de date + jurnalul de evenimente).

3) Rigoarea prețurilor: PACELC și CAP

PACELC: Atunci când împărțiți o rețea (P), trebuie să alegeți C (rigoare) sau A (disponibilitate). Puternic → CP: este mai bine să refuzați sau să blocați decât să încălcați invariantul. Atunci când nu există separare (EL), plătim cu L - p95/p99 crește în coordonare/cvorumuri.
Practica: puternic pentru „nucleul de invarianți”, în jurul valorii de - proiecții rapide/cache cu eventual, astfel încât UX nu suferă.

4) Cum se obține o consistență puternică

Leadership și cvorumuri

Unicul lider acceptă înregistrările; lectură - la lider sau prin cvorumul de replici.
Quorum 'W' pentru scris și 'R' pentru citit cu 'R + W> N' îmbunătățește șansele de a citi „ultimul”.

Algoritmi de potrivire

Raft/Paxos: jurnal de replicare, confirmări majoritare, termen/indici.
Replicare sincronă - Înregistrarea este validată numai după persistența pe cvorum.

Ore și ordine

TrueTime/Hybrid Logical Clocks (HLC): Limitați alinierea greșită a ceasului pentru o serializare globală sigură.
Gard jetoane/versioning: protecție împotriva „dimineața” lideri și split-creier.

Izolarea tranzacțiilor

Serializable (SI + predicate conflict checking/lock): protecție împotriva phantom/write-skew.
Strict serializabil: serializabilitate + liniarizabilitate în raport cu timpul real.

5) Multi-regiune: opțiuni și compromisuri

Lider global (CP)

Înregistrările trec printr-o regiune de conducere; citește - cache-uri/proiecții locale sau printr-un lider.
Pro: Model simplu. Contra: p95/RTT la lider, cu P - înregistra încuietori.

Lideri regionali + cvorum sincron

Cvorum extins geografic din mai multe regiuni; fiecare înregistrare așteaptă confirmări> 50%.
Pro: fără un singur „gât îngust”, stabilitate ridicată. Contra: Latență intercontinentală.

Geo-partiționare

Date de origine pentru regiune (chiriaș/jurisdicție); operațiuni globale - prin sagas/agregate.
Pro: Latență scăzută pentru înregistrările locale. Contra: Planificarea limitelor de date.

6) Configurați R/W și citește

Intrări: „W = majoritate” este standardul pentru puternic.

• „Cel mai proaspăt” - 'R = majoritate' sau lectură la lider.
• Pentru a reduce L - „stale-ok” citește din replici pentru ecrane secundare (marcate explicit în UX).
• Citire-reparare/închiriere citire: optimizare fără pierderea severității pentru contractele de leasing scurte ale liderului.

7) Performanță și UX

Latență: Focus pe RTT între client și lider/cvorum (interregional sute de ms).
„scrie-puternic, citit-rapid” model: puternic pe scrie + cache/proiecție pe citește, cu RYW pentru autor.
Lot/pachete: înregistrări de grup, dar urmăriți latența cozii.
Contururi de degradare: într-un incident - doar citire, statusuri oneste, interzicerea mutațiilor periculoase.

8) Observabilitatea căii stricte

Măsurători

p50/p95/p99 latență: scrieți cvorum, citiți cvorum, lecturi de conducere.
Succes de cvorum, reluări/rollback-uri, schimbări de lider.
Decalaj replicare (de așteptat mici, dar monitorizarea este obligatorie).
Cota de „steil” citește (dacă este inclus).

Urmărire

Spans: „acceptare lider”, „replicare”, „cvorum comite”.
Теги: 'termen', 'leader _ id',' quorum _ size ',' regiune '.

Alerte

Creștere p95/p99, lider electoral frecvent, cvorum-timeout, indicatori split-creier.

9) Teste și haos

Jepsen-ca: partiții de rețea, întârzieri, picături, ceas-skew.
Safety-invariants: imposibilitatea dublării cheltuielilor/soldurilor negative/dublei rezervări.
Leadership: refuz de lider, realegere sub sarcină, jetoane de gard.
Citiți coerența: citirea imediat după scriere ar trebui să vadă „nou” (RYW/citire liniarizabilă).

10) Registrele de redare incidente

Pierderea cvorumului: treceți la citire, notificați clienții, trimiteți o intrare în regiunea „acasă” dacă geo-partiționarea este prezentă.
Creșterea latenței este interregională: reducerea temporară a volumului de înregistrări stricte (migrarea unor fluxuri în coadă/proiecții), localizarea traficului.
Leader Flap: Creșteți timpii electorali, verificați rețelele/pauzele de ore/GC.
Split-creier: activați jetoanele/cecurile de închiriere, opriți liderii vechi la nivelul operatorului.

11) Erori tipice

Cerere puternică „peste tot”: o explozie de latență și costuri în loc să se concentreze pe invarianți.
Încercarea de a fi CA sub scindări reale: La punctul P, sistemul încă face o alegere, adesea implicit.
Scriere dublă în diferite regiuni fără saga/coordonator: fantome și pierderea invarianților.
Absența RYW: utilizatorul nu vede entitatea sa nou înregistrată - o scădere a încrederii.
Ignorarea ceasului: Fără limitele HLC/TrueTime, este ușor să obțineți timp de „sărituri” și curse.
Nu există niciun plan de degradare: la P, încep eșecurile parțiale haotice.

12) remedieri rapide (rețete)

Plăţi/solduri: lider + cvorum majoritar; tranzacții strict serializabile timp scurt, eșec greu la P.
Rezervare (locuri/sloturi): scrie-puternic prin lider, citește - cache cu RYW; TTL-rezerve + TCC.
Global SaaS: geo-partiție prin „chiriaș/regiune”; operațiuni stricte în regiunea de origine, rapoarte/căutare - prin proiecții.
Audit/jurnal: adăugați numai CP-log; citește pot fi cache, dar verificate cu puncte de control.

13) Lista de verificare pre-vânzare

• Invarianți care necesită puternic au fost scrise; restul este în AP/proiecție.
• Singur lider/cvorum interregional/geo-partiție selectat.
• Configurat "W = majoritate", "R = lider" majoritate "pentru căi critice.
• RYW/monotonic prevăzut pentru UX; marcat explicit „stale-ok” citește.
• Metrica inclusă de cvorum, lag-uri, latențe; alerte privind p95/p99 și realegerea.
• Există un plan degradant: numai citire, dezactivarea mutațiilor periculoase, cozi pentru „după furtună”.
• Teste de haos: diviziuni, ceas-skew, eșec lider; invarianţii de siguranţă au fost verificaţi.
• Documentația contractului: ceea ce este strict, ceea ce „poate fi în urmă”, comunicare pentru produs/suport.

Concluzie

Consistența puternică este un instrument pentru protejarea adevărului în cazul în care eroarea este inacceptabilă. Aplicați-l în mod corespunzător în jurul invarianților duri, plătind în mod conștient pentru coordonarea cu latența și disponibilitatea în furtuni. Combinați: kernel-ul CP pentru citirea critică, AP și proiecția pentru viteză. Cu telemetria, degradarea și testele potrivite, veți păstra atât corectitudinea, cât și experiența utilizatorului.