mirror of
https://github.com/kuhyx/praca_magisterska.git
synced 2026-07-04 13:43:05 +02:00
9.2 KiB
9.2 KiB
Pytanie 24: Modele spójności danych w systemach rozproszonych
Pytanie
"Omówić silne i słabe modele spójności danych w środowisku rozproszonym."
Przedmiot: ERSMS (Elementy Rozproszonych Systemów i Middleware'u Sieciowego)
📚 Odpowiedź główna
1. Problem spójności w systemach rozproszonych
┌─────────────────────────────────────────────────────────────────┐
│ Repliki danych: │
│ │
│ Client A Client B │
│ │ write(x=1) │ read(x)=? │
│ ↓ ↓ │
│ ┌───────┐ ┌───────┐ │
│ │Replica│──sync?──→│Replica│ │
│ │ 1 │ │ 2 │ │
│ │ x=1 │ │ x=0? │ │
│ └───────┘ └───────┘ │
│ │
│ Pytanie: Co zwróci read(x)? │
│ Odpowiedź zależy od modelu spójności! │
└─────────────────────────────────────────────────────────────────┘
2. Spektrum modeli spójności
Silne ←─────────────────────────────────────────→ Słabe
Linearizability Eventual
│ Consistency
↓ ↑
Sequential Causal
Consistency Consistency
│ ↑
↓ Session
Causal+ Guarantees
│
↓
PRAM
3. Silne modele spójności
Linearizability (Linearyzacja)
Definicja: Każda operacja wygląda jakby wykonała się atomowo
w pewnym momencie między wywołaniem a odpowiedzią.
Timeline:
Client A: ─────[write(x=1)]─────────────────────→
Client B: ───────────[read(x)]──────────────────→
↓
Musi zwrócić 1!
Właściwości:
- Najsilniejsza gwarancja
- "Globalny porządek rzeczywisty"
- Kosztowna (wymaga koordynacji)
Implementacja: Consensus (Paxos, Raft), single leader
Sequential Consistency
Definicja: Istnieje globalny porządek operacji zgodny
z porządkiem programu każdego procesu.
Client A: write(x=1) ──────────────────→
Client B: ──────────── write(x=2) ─────→
Client C: read(x)=? ── read(x)=? ──────→
Dozwolone: C widzi [1,2] lub [2,1]
(byle konsystentnie z innymi)
Różnica od linearyzacji:
- Nie wymaga zgodności z czasem rzeczywistym
- Wystarczy spójny porządek
4. Słabe modele spójności
Eventual Consistency
Definicja: Jeśli nie ma nowych zapisów, ostatecznie
wszystkie odczyty zwrócą tę samą wartość.
Timeline:
write(x=1) @ Replica A
↓ (propagacja)
↓
↓ ... czas ...
↓
read(x)=1 @ Replica B (eventually)
Gwarancje:
✅ Dostępność (AP w CAP)
✅ Niska latencja
❌ Stare dane przez jakiś czas
❌ Możliwe konflikty
Implementacja: DNS, Dynamo, Cassandra
Causal Consistency
Definicja: Operacje przyczynowo zależne widziane
w tej samej kolejności przez wszystkich.
P1: write(x=1) ─────────────────────────→
↓ (read x)
P2: ──────────── write(y=2) ────────────→
P3 widzi: x=1 przed y=2 (zawsze!)
(bo y=2 zależy przyczynowo od x=1)
Niezależne zapisy mogą być widziane w różnej kolejności.
Implementacja: Vector clocks, COPS
Session Guarantees
| Gwarancja | Opis |
|---|---|
| Read Your Writes | Odczyt widzi własne wcześniejsze zapisy |
| Monotonic Reads | Raz widziana wartość nie "cofa się" |
| Monotonic Writes | Zapisy aplikowane w kolejności sesji |
| Writes Follow Reads | Zapis po odczycie widzi ten odczyt |
Read Your Writes:
Session: write(x=5) ──── read(x)=? ────→
Musi być 5!
Monotonic Reads:
Session: read(x)=5 ──── read(x)=? ────→
Musi być ≥ 5!
5. CAP Theorem
┌─────────────────────────────────────────────────────────────────┐
│ CAP Theorem │
│ │
│ Consistency (C) │
│ /\ │
│ / \ │
│ / \ │
│ / CA \ │
│ / \ │
│ / CP \ │
│ Availability (A) ──────────── Partition Tolerance (P) │
│ AP │
│ │
│ W obecności partycji sieci (P): wybierz C lub A │
│ │
│ CP: Spójne, ale niedostępne (Zookeeper, etcd) │
│ AP: Dostępne, ale niespójne (Dynamo, Cassandra) │
└─────────────────────────────────────────────────────────────────┘
6. Porównanie modeli
| Model | Gwarancje | Wydajność | Przykłady |
|---|---|---|---|
| Linearizable | Najsilniejsze | Niska | Spanner, CockroachDB |
| Sequential | Silne | Średnia | Zookeeper |
| Causal | Przyczynowe | Dobra | COPS, MongoDB |
| Session | Per-sesja | Dobra | Dynamo sessions |
| Eventual | Najsłabsze | Najwyższa | DNS, Cassandra |
7. Strategie rozwiązywania konfliktów
Last-Writer-Wins (LWW)
Konflikt: write(x=1) || write(x=2)
Rozwiązanie: Większy timestamp wygrywa
Problem: Utrata danych!
Multi-Value (Siblings)
Konflikt: write(x=1) || write(x=2)
Rozwiązanie: Przechowaj oba: x=[1,2]
Klient rozwiązuje przy odczycie (Riak)
CRDTs (Conflict-free Replicated Data Types)
Struktury automatycznie łączące się:
- G-Counter (grow-only counter)
- OR-Set (observed-remove set)
- LWW-Register
Merge jest łączny, przemienny, idempotentny
→ Zawsze zbieżność!
🧠 Mnemoniki
"Linearizable = Real-time + Atomic":
Widoczne natychmiast, atomowo
"Eventual = Eventually, trust me":
Kiedyś będzie spójne (bez gwarancji kiedy)
"CAP = Choose 2 of 3":
Partition → wybierz Consistency lub Availability
"CRDT = Conflict-free":
Matematyczna gwarancja zbieżności
❓ Pytania dodatkowe
Q1: "Czym różni się linearizability od serializability?"
Odpowiedź: Linearizability = dla pojedynczych operacji, real-time ordering. Serializability = dla transakcji, jakiś serial order. Strict serializability = oba razem.
Q2: "Kiedy wybrać eventual consistency?"
Odpowiedź: Wysoka dostępność ważniejsza niż spójność, tolerancja na stale reads, możliwość rozwiązania konfliktów (shopping cart, likes counter, DNS).
Q3: "Co to jest Quorum?"
Odpowiedź: W = write quorum, R = read quorum, N = repliki. W + R > N gwarantuje odczyt najnowszej wartości. Dynamo: N=3, W=2, R=2.
🎯 Kluczowe punkty
- Linearizable: Najsilniejszy, atomowy, kosztowny
- Sequential: Globalny porządek, bez real-time
- Causal: Przyczynowo zależne w kolejności
- Eventual: Ostatecznie spójne, najszybszy
- CAP: Partition → C xor A
- CRDTs: Automatyczne rozwiązywanie konfliktów
📖 Źródła
- Herlihy, Wing - "Linearizability" (1990)
- Vogels - "Eventually Consistent" (Amazon CTO)
- Gilbert, Lynch - "CAP Theorem" (2002)
- Shapiro et al. - "CRDTs" (2011)