Strong Consistency quando necessario

Strong Consistency è un modello in cui tutte le operazioni sembrano essere eseguite in modo immediato e coerente in un unico ordine globale coerente con il tempo reale. L'utente leggerà l'ultimo valore confermato e i due client paralleli non si supereranno a vicenda logicamente.

La coerenza rigorosa fornisce un modello semplice e mentale e protegge gli invarianti rigidi, ma richiede un coordinamento (quorum/leader) che aumenta la latenza e la sensibilità alle divise di rete.

1) Quando Strong è obbligatorio

Finanza e calcoli

Bilanci e addebiti: «doppio spreco» non è valido.
Traduzioni e reciproci: la stessa cifra non può essere effettuata due volte.

Inventario e limiti

I saldi della merce/posto in hotel/biglietti non possono essere inviati in valori negativi.
Limiti di transazione in unità di tempo (limiti di credito, crediti API).

Unicità e integrità

Login/ID/regole di deduplicazione univoci.
Invarianti a livello di dominio: «Il medico deve essere in servizio nel reparto», «Non può essere in coda> N attività attive».

Controllo e registri invariati

Gli eventi che sono la fonte legale della verità, l'ordine e la completezza sono critici.

Se una violazione dell'invariante comporta un rischio di business inaccettabile (perdita di denaro, sanzioni, perdita di fiducia) - scegli Strong Consistency.

2) Esattamente «rigoroso»

Linearizability (livello operativo) - La lettura vede l'ultima scrittura riuscita. I tempi sono rispettati.
Serializable (livello transazionale) - Il risultato è equivalente all'esecuzione delle transazioni in sequenza (può essere strong, ma a volte implementato senza un ordine real-time rigido).
Una differenza importante è che Serializable protegge contro le anomalie del livello di transazione (phantom/write-skew), mentre Linearizable protegge l'istantaneità e l'ordine delle singole operazioni. Spesso sono necessarie entrambe le proprietà (ad esempio denaro in database + registro eventi).

3) Prezzo del rigore: PACELC e CAP

PACELC: quando si divide una rete (P), è necessario selezionare C (rigore) o A (disponibilità). Strong: è meglio rifiutare o bloccare che violare l'invariante. Quando non ci sono separazioni (EL), paghiamo L - coordinati/quorum cresce p95/p99.
Pratica: strong per «core invarianti», intorno ci sono proiezioni veloci/cache con eventual per evitare che la UX soffra.

4) Come raggiungono Strong Consistency

Leadership e quorum

L'unico leader accetta le registrazioni; letture: il leader o il quorum delle repliche.
Il quorum "W" per scrivere e "R" per leggere con "R + W>" N "aumenta le probabilità di leggere" ultimo ".

Algoritmi di negoziazione

Raft/Paxos: Loga di replica, conferma di maggioranza, termine/indice.
Replica sincrona: la scrittura viene confermata solo dopo la personalizzazione del quorum.

Orologio e ordine

TrueTime/Hybrid Logical Clocks (HLC) - Limita la rassincrona dell'orologio per una serializzazione globale sicura.
Fence-token/versioning: protezione da leader mattutini e split-breen.

Isolamento transazioni

Serializable (SI + test di conflitti/loop per predici) - Protezione da phantom/write-skew.
Strict-serializable: serializzazione + linearità rispetto al tempo reale.

5) Multi-Regione - Opzioni e compromessi

Leader globale (COP)

Le registrazioni passano attraverso una regione leader; letture: cache/proiezioni locali o tramite un leader.
I vantaggi sono un modello semplice. Contro: p95/RTT a capo, con P - blocco record.

Leader regionali + quorum sincronizzato

quorum georaschirenico da diverse regioni; ogni voce è in attesa di conferma> 50%.
I vantaggi, senza un collo stretto, alta resistenza. Contro, latitanza intercontinentale.

Geo-partitioning

Dati «domestici» per la regione (tenente/giurisdizione); transazioni globali attraverso saghe/aggregazioni.
Più: ritardi ridotti per i record locali. Contro - Pianificazione dei limiti dei dati.

6) Impostazioni R/W e letture

«W = majority» è lo standard per strong.

• «Il più recente» è «R = majority» o la lettura da un leader.
• Per ridurre L - «stale-ok» di lettura da repliche per schermate secondarie (con marcatura esplicita in UX).
• Read-repair/lease read: ottimizzazione senza perdita di rigore per i brevi affitti del leader.

7) Prestazioni e UX

Latitanza: concentrati su RTT tra cliente e leader/quorum (interregionale centinaia di mc).
Pattern «write-strong, read-fast»: strong in scrittura + cache/proiezione in lettura, con RYW per l'autore.
Batch/pacchetti: raggruppa i record, ma controlla la latenza di coda.
Tracciati di degrado: in caso di incidente - read-only, stato onesto, divieto di mutazioni pericolose.

8) Osservabilità percorsi strict

Metriche

p50/p95/p99 latency: quorum write, quorum read, letture leader.
Quorum di successo, ripetizioni/ritiri, cambi di leader.
La lega di replica (prevedibilmente piccola, ma obbligatoria).
Percentuale di letture stale (se attivate).

Tracking

Span's: «accettazione da leader», «replica», «commit quorum».
Теги: `term`, `leader_id`, `quorum_size`, `region`.

Alert

Crescita p95/p99, rielezione frequente del leader, quorum-timeouts, split-brain indicatori.

9) Test e caos

Jepsen-simili: separazioni di rete, ritardi, drop, clock-skew.
Safety-invarianti: impossibilità di doppio spreco/residui negativi/doppia prenotazione.
Leadership: rifiuto del leader, rielezione sotto carico, fence-token.
Coerenza di lettura: la lettura immediatamente dopo la scrittura deve vedere «nuovo» (RYW/linearizable read).

10) Playbook incidenti

Perdita del quorum: passa al read-only, avvisa i clienti, invia la voce alla regione «home» se c'è geo-partitioning.
Crescita della latitudine interregionale: riduzione temporanea del volume di record rigorosi (migrazione di parte dei flussi in code/proiezioni), localizzazione del traffico.
Flap leader: aumentare i timeout delle elezioni, controllare le reti/la deriva oraria/pausa GC.
Split-brain: attivare fence-token/lease-verifiche, fermare i vecchi leader a livello di operatore.

11) Errori tipici

Richiedere Strong «ovunque» è un'esplosione di latitanza e costo invece di concentrarsi sugli invarianti.
Cerca di essere CA nelle divise reali: al momento P, il sistema fa comunque una scelta, spesso implicita.
Dual-write in diverse regioni senza saghe/coordinatore: fantasmi e perdita di invarianti.
Assenza di RYW: l'utente non vede la propria entità appena registrata come una perdita di fiducia.
Ignora l'orologio: senza limiti HLC/TrueTime è facile ottenere un tempo e una corsa «salteggianti».
Nessun piano di degrado: la P inizia con problemi parziali caotici.

12) Soluzioni rapide (prescrizioni)

Pagamenti/bilanci: leader + majority-quorum; transazioni strict-serializable timeout breve, rigido rifiuto a P.
Prenotazione (posti/slot): write-strong tramite il leader, letture - cache con RYW; Riserve TTL + TCC.
Globale: geo-partition per tenant/region; operazioni rigorose nella regione domestica, report/ricerche attraverso proiezioni.
Controllo/registro: append-only Registro CAP; le letture possono essere memorizzate, ma i checkpoint possono essere verificati.

13) Foglio di assegno prima di vendere

• Estratti invarianti che richiedono strong; Il resto è in RC/proiezione.
• Modalità selezionata: leader/quorum unico interregionale/geo-partition.
• Configurato "W = majority", "R = leader" majority "per i percorsi critici.
• Assicurati con RYW/monotonic per UX; sono chiaramente contrassegnati «stale-ok» di lettura.
• Incluse metriche di quorum, lame, latentalità; alert su p95/p99 e rielezione.
• C'è un piano degrade: read-only, disattivazione di mutazioni pericolose, code per «dopo la tempesta».
• Test di caos: separazione, clock-skew, rifiuto del leader; gli invarianti safety sono stati testati.
• Documentazione dei contratti: rigorosamente, «può rimanere indietro», comunicazione per il prodotto/supporto.

Conclusione

Strong Consistency è uno strumento per proteggere la verità dove l'errore è inaccettabile. Usatela in modo puntuale intorno ad invarianti rigidi, pagando consapevolmente per coordinare la latenza e la disponibilità nelle tempeste. Combinare il kernel CAP per la lettura critica, PA e la proiezione per la velocità. Con la giusta telemetria, degrado e test, manterrete la correttezza e l'esperienza utente.