Bu qatlamda nima bor
Core darslik asoslarni berdi. Bu Deep qatlam senior darajadagi chuqur mexanikani ochadi: izchillik modellari spektri (linearizable→eventual), kvorum matematikasi (N/R/W), PACELC tasnifi, consensus nega CP ekani, Spanner’ning TrueTime bilan izchilligi, Dynamo/Cassandra ichki mexanikasi va CRDT bilan konfliktsiz AP. Oxirida — model tanlash va senior cheklist.
Izchillik modellari spektri
linearizable · causal · eventualCore’da "izchillik" bitta narsadek ko‘rindi. Aslida u — spektr: eng kuchli (linearizability) dan eng zaif (eventual) gacha. Har biri boshqa kafolat va boshqa narx.
| Model | Kafolat |
|---|---|
| Linearizability | Har amal real-time nuqtada bo‘lib o‘tgandek — tizim bitta nusxadek. Yozib bo‘lgach, hamma darhol ko‘radi. |
| Sequential | Barcha amallar bitta umumiy tartibda ko‘rinadi va har jarayonning o‘z tartibi saqlanadi — lekin real-time shart emas. |
| Causal | Sababiy bog‘liq amallar (A → B) hammaga shu tartibda ko‘rinadi; bog‘liqmas (parallel) amallar turlicha ko‘rinishi mumkin. |
| Eventual | Yangi yozuv bo‘lmasa, replikalar oxir-oqibat bir xil holatga keladi. Tartib kafolati yo‘q. |
Linearizability qimmat (global koordinatsiya), eventual esa ba’zan juda zaif ("kommentga javob asl kommentdan oldin ko‘rindi"). Causal consistency ko‘p ilova uchun "shirin nuqta": arzon (global tartib shart emas), lekin sababiy tartibni saqlaydi — chat, komment kabi holatlarda yetarli.
Kvorum matematikasi (N, R, W)
R+W>N · sloppy quorumTunable izchillikning yuragi — kvorum matematikasi. Uch raqam (N, R, W) izchillik, tezlik va mavjudlik o‘rtasidagi muvozanatni belgilaydi.
// KVORUM: N ta replika, W ta yozuv tasdig'i, R ta o'qish javobi
//
// R + W > N -> o'qish va yozuv kvorumlari KESISHADI
// -> har o'qish kamida bitta ENG SO'NGGI nusxani ko'radi (kuchli)
// W > N/2 -> ikki yozuv bir vaqtda ajralgan to'plamga tushmaydi (tartib)
//
// N=3 misollar:
// W=3, R=1 -> yozuv sekin (hammani kutadi), o'qish tez; durable, past mavjudlik
// W=1, R=1 -> ikkalasi tez; R+W=2 <= 3 -> ESKIRISH mumkin (AP)
// W=2, R=2 -> R+W=4 > 3 -> KUCHLI izchil, VA bittasi o'lsa ham ishlaydi (muvozanat)
Bo‘linish paytida kerakli N node’dan ba’zisi yetib bo‘lmasa — Dynamo yozuvni keyingi mavjud node’larga yozadi (sloppy quorum) va "asl node tuzalganda unga yetkaz" deb belgi (hinted handoff) qoldiradi. Bu mavjudlikni oshiradi, lekin izchillikni yanada bo‘shashtiradi — sof AP xatti-harakat.
PACELC tasnifi
PA/EL · PC/ECCore’da PACELC’ni tanishtirdik. Senior darajada u tizimlarni to‘liq tasniflaydi: bo‘linishda ham, normal holatda ham qanday tanlov qilishini.
PACELC: if P then A or C, Else L or C. Ya’ni ikki o‘q — bo‘linishda (A/C) va normal holatda (L/C):
| Tasnif | Bo‘linishda | Normal holatda | Misol |
|---|---|---|---|
| PA/EL | Mavjudlik | Kechikish (past) | Dynamo, Cassandra, Riak |
| PC/EC | Izchillik | Izchillik | Spanner, VoltDB, HBase |
| PA/EC | Mavjudlik | Izchillik | Ba’zi sozlamalar |
| PC/EL | Izchillik | Kechikish | PNUTS (kam uchraydi) |
Bu PACELC’ning muhim tushunchasi: tarmoq soppa-sog‘ bo‘lsa ham, izchillikni oshirsang — hamma replikani/kvorumni kutasan, bu kechikishni oshiradi. Ya’ni izchillik bo‘linishda mavjudlikka, normal holatda esa tezlikka to‘lanadigan narx. CAP faqat birinchisini, PACELC ikkalasini ham ko‘radi.
Consensus va CAP
Paxos/Raft · majority7-mavzuda Raft/quorum’ni failover uchun ko‘rdik. CAP nuqtai nazaridan konsensus — tabiiy CP: u izchillikni beradi, lekin bo‘linishda mavjudlikni qurbon qiladi.
Nega konsensus = CP
Paxos/Raft kabi konsensus algoritmlari amalni faqat ko‘pchilik (majority quorum) tasdiqlagach "committed" deb belgilaydi. Bu linearizability beradi. Lekin oqibati:
Ozchilik tomonda qolgan node’lar ko‘pchilikka yeta olmaydi, demak yangi amalni tasdiqlay olmaydi — o‘sha tomon mavjud emas (rad etadi/bloklaydi). Faqat ko‘pchilik tomon ishlaydi.
etcd, ZooKeeper, Consul — konsensus asosidagi CP tizimlar (konfiguratsiya, leader election, qulf uchun — aynan shu izchillik kerak). Spanner ham har shardda Paxos ishlatadi (keyingi bo‘lim). Konsensusni AP qilib bo‘lmaydi — bu uning mohiyatiga zid.
Spanner va TrueTime
TrueTime · commit-waitGoogle Spanner — global miqyosda linearizable (tashqi izchil) SQL bazasi. "CP tizim yuqori mavjudlikka ega bo‘la olmaydi" degan tasavvurni buzadi.
Asosiy hiyla — TrueTime
Taqsimlangan izchillikning tub muammosi — vaqt: node’lar soatlari mos kelmaydi, "qaysi yozuv oldin bo‘ldi?" aniq emas. Spanner buni TrueTime bilan hal qiladi: GPS + atom soatlari orqali vaqtni chegaralangan noaniqlik (ε) bilan biladi — TT.now() aniq nuqta emas, [eng erta, eng kech] oralig‘ini qaytaradi.
Commit-wait: Spanner tranzaksiyani commit qilganda, timestamp’ning noaniqlik oralig‘i o‘tguncha ataylab biroz kutadi. Shunda commit vaqti aniq "o‘tmishda" bo‘ladi — global, real-time tartib (external consistency) kafolatlanadi. Har shard esa Paxos bilan replikatsiya qilinadi.
Spanner — PC/EC (CP): bo‘linishda izchillikni saqlaydi. Lekin Google’ning ishonchli tarmog‘i tufayli bo‘linish juda kam va tez tuzaladi — natijada amalda 5 to‘qqizli (99.999%) mavjudlik. Xulosa: "CP tizim ham, agar bo‘linish nodir bo‘lsa, deyarli doim mavjud bo‘la oladi." Aqlli qism — izchillikni sinxronlashtirilgan vaqt bilan hal qilish.
Dynamo & Cassandra ichi
ring · hinted handoff · gossipAmazon Dynamo (va undan ilhomlangan Cassandra) — teskari falsafa: AP. "Har doim yozib olish mumkin" (masalan, savatga qo‘shish hech qachon rad etilmasin).
Qanday ishlaydi
- Consistent hashing ring (4/6-mavzular): kalitlar halqada, har biri keyingi N node’ga replikatsiya qilinadi.
- Tunable izchillik: har amalda darajani tanlaysan —
ONE/QUORUM/ALL(kvorum matematikasi, 2-bo‘lim). - Gossip protocol: node’lar bir-birining holatini o‘zaro "mish-mish" orqali biladi (markaziy koordinatorsiz).
- Hinted handoff: o‘lik node uchun yozuv vaqtincha boshqasida saqlanadi, tuzalganda yetkaziladi.
- Read repair + anti-entropy: o‘qishda eskirgan replika sezilsa tuzatiladi; fonda Merkle daraxti bilan replikalar solishtiriladi.
AP’da ikki node bir kalitni bir vaqtda yozishi mumkin — konflikt. Dynamo vector clock bilan "kim kimdan keyin"ni aniqlaydi (aniqlab bo‘lmasa — ilovaga beradi). Cassandra oddiyroq — last-write-wins (timestamp bo‘yicha, lekin soat muammosi bilan). Keyingi bo‘limda yanada yaxshi yechim — CRDT.
2007-yilgi Dynamo maqolasi butun bir avlod AP bazalarni tug‘dirdi: DynamoDB, Cassandra, Riak, Voldemort. Ularning umumiy DNK’si — koordinatsiyani minimallashtirib, mavjudlikni maksimallashtirish.
CRDT bilan konfliktsiz AP
G-Counter · convergenceAP tizimda konflikt muqarrar. LWW (last-write-wins) yozuvni jimgina yo‘qotadi. CRDT — koordinatsiyasiz, avtomatik va yo‘qotishsiz birlashadigan ma’lumot turlari.
CRDT g‘oyasi
Conflict-free Replicated Data Types — shunday tuzilganki, ularning birlashish (merge) amali matematik jihatdan kommutativ, assotsiativ va idempotent. Demak node’lar istalgan tartibda, istalgan necha marta sinxronlashsa ham — bir xil natijaga keladi (konvergensiya), hech qanday markaziy koordinatsiyasiz:
// G-COUNTER (grow-only): har node O'Z hisobini yuritadi; MERGE = har node bo'yicha MAX
class GCounter {
counts: Record<string, number> = {}; // { nodeA: 3, nodeB: 5 }
inc(node: string) { this.counts[node] = (this.counts[node] ?? 0) + 1; }
value() { return Object.values(this.counts).reduce((a, b) => a + b, 0); }
merge(other: GCounter) { // KONFLIKTSIZ birlashish
for (const n in other.counts)
this.counts[n] = Math.max(this.counts[n] ?? 0, other.counts[n]);
}
}
// merge kommutativ + assotsiativ + idempotent
// -> qaysi tartibda/necha marta birlashtirsang ham -> BIR XIL natija (konvergensiya)
| CRDT turi | Nima uchun |
|---|---|
| G-Counter / PN-Counter | Faqat o‘suvchi / o‘sadi-kamayadi hisoblagich (layk, ko‘rish) |
| G-Set / OR-Set | Element qo‘shiladigan / qo‘shiladi-o‘chiriladi to‘plam |
| LWW-Register | Bitta qiymat (timestamp bilan) |
Riak, Redis (Active-Active CRDT), Automerge/Yjs (birgalikda tahrirlash — Google Docs uslubi). State-based (CvRDT — butun holatni sinxronlaydi) va op-based (CmRDT — amallarni tarqatadi) variantlari bor. CRDT — AP’ga "izchillik yo‘qotishsiz" berishning eng nafis yo‘li, lekin faqat maxsus ma’lumot turlari uchun ishlaydi.
Model tanlash va senior cheklist
Qaror — izchillik modeli va mexanizm tanlash
| Ehtiyoj | Model / mexanizm |
|---|---|
| Pul, balans, noyoblik, qulf | Linearizable — konsensus (etcd/Raft), Spanner, sync RDBMS (CP) |
| Chat, komment, sababiy tartib | Causal consistency |
| Har doim yozib olish (savat, layk) | AP + kvorum; konflikt uchun CRDT |
| Lenta, katalog, analitika | Eventual (AP), past kechikish |
| Parallel hisoblagich/to‘plam | CRDT (yo‘qotishsiz merge) |
Senior tayyorlik cheklisti
| Savol / amaliyot | Bo‘lim |
|---|---|
| Izchillik modellari spektrini (linearizable→eventual) va farqini bilaman | 1 |
| Kvorum matematikasini (R+W>N) qo‘llab, izchillik/tezlik/mavjudlik muvozanatini sozlayman | 2 |
| Tizimlarni PACELC bilan tasniflayman (bo‘linishda VA normal holatda) | 3 |
| Konsensus nega CP ekanini va qayerda ishlatishni bilaman | 4 |
| Spanner’ning TrueTime/commit-wait bilan izchillikka erishishini tushunaman | 5 |
| Dynamo/Cassandra ichki mexanikasini (ring, hinted handoff, read repair) bilaman | 6 |
| AP konfliktni CRDT bilan yo‘qotishsiz hal qilaman; LWW cheklovini bilaman | 7 |
Bu 11-mavzuning Deep/Senior qatlami edi — Core bilan birga, CAP endi to‘liq.
Keyingi mavzu: “12-mavzu: Observability” — taqsimlangan tizimda nima bo‘layotganini ko‘rish (logs, metrics, traces). Core’dan boshlaymiz.