Dasturlash kitobi/9-QISM — Arxitektura32 daqiqa

9.10-bob: Distributed systems, CAP teoremasi

9-QISM — Arxitektura va ilg'or backend · 10-mavzu

1. Kirish va motivatsiya

9-QISM (Arxitektura)ning yakuniy va eng nazariy-fundamental mavzusi — taqsimlangan tizimlar (distributed systems) va CAP teoremasi. Shu paytgacha o'rgangan mavzularimiz — mikroservis 9.5-bob, replication/sharding 9.9-bob, eventual consistency 9.7-bob — barchasi taqsimlangan tizim. Endi ularning nazariy poydevorini tushunamiz: taqsimlangan tizim nima, nega qiyin, va eng mashhur qonun — CAP teoremasi (Consistency, Availability, Partition tolerance — uchtasidan faqat ikkitasini tanlash mumkin). Bu — har taqsimlangan tizim qarorining asosi (DB tanlash, arxitektura), va System Design intervyuning (15) klassik savoli.

Taqsimlangan tizim — bir necha kompyuter (node) bir maqsad uchun birga ishlaydigan tizim (mikroservis, replicated DB, cluster). Afzalligi — masshtab, chidamlilik 9.9-bob. Lekin u tubdan qiyin: tarmoq ishonchsiz (xabar yo'qoladi, kechikadi), node'lar yiqiladi, vaqt sinxron emas, qism node'lar bir-birini ko'rmay qoladi (partition). Bu qiyinchiliklar bir kompyuterda yo'q (funksiya chaqiruvi ishonchli). CAP teoremasi shu qiyinchilikning matematik haqiqatini ifodalaydi: tarmoq bo'linganda, izchillik (consistency) va mavjudlik (availability) o'rtasida tanlov qilishga majbursiz (ikkalasini birga olib bo'lmaydi).

Bu bob: taqsimlangan tizim (nima, nega qiyin), distributed computing fallacies (noto'g'ri taxminlar), CAP teoremasi (chuqur — C/A/P, nega ikkitasi), CP vs AP (DB tanlash), PACELC (CAP kengaytmasi — latency), consistency modellari (strong/eventual/BASE), consensus (Raft/Paxos — node'lar kelishuvi), va amaliy ma'no. Bu bob 9.5 (mikroservis), 9.7 (eventual consistency), 9.9 (replication), 6.9 (ACID) bilan bog'liq. Bu — taqsimlangan tizim fundament1 (senior+/arxitektor nazariy asosi).

O'xshatish: CAP teoremasi — uzoqdagi do'stlar bilan qaror qabul qilish. Siz va do'stingiz (ikki node) turli shaharda, telefon orqali kelishasiz (tarmoq). Hammasi yaxshi ishlaganda — muammo yo'q. Lekin telefon uzilsa (partition — tarmoq bo'linishi), ikki yo'l qoladi: (1) izchillik — "telefon ulanmaguncha hech qaror qabul qilmaymiz" (ikkalamiz bir xil bilamiz, lekin ish to'xtaydi — mavjudlik yo'q); yoki (2) mavjudlik — "har birimiz o'zimizcha qaror qilamiz" (ish davom etadi, lekin ikkalamiz har xil bilishimiz mumkin — izchillik yo'q). Telefon uzilganda ikkalasini birga (izchil + ish davom) qilib bo'lmaydi — bu CAP. Telefon ishlaganda (partition yo'q) — boshqa savol: tez javob (latency) yoki puxta tekshirish (consistency) — bu PACELC.

Nega muhim?

Taqsimlangan tizim asosi — mikroservis, replicated DB nazariyasi.
DB tanlash — CP (MongoDB strong/PostgreSQL) vs AP (Cassandra) — CAP.
Trade-off tushunish — izchillik vs mavjudlik (majburiy tanlov).
System Design — intervyu (15) klassik savoli.

2. Nazariya — chuqur tushuntirish

2.1. Taqsimlangan tizim nima va nega qiyin

text

  TAQSIMLANGAN TIZIM — ko'p node birga ishlaydi (bir maqsad):
  mikroservis 9.5-bob, replicated DB 9.9-bob, cluster, P2P

  NEGA QIYIN (bir kompyuterda yo'q muammolar):
   Tarmoq ishonchsiz (xabar yo'qoladi, kechikadi, takrorlanadi)
   Node'lar yiqiladi (qism ishlaydi, qism yo'q)
   Vaqt sinxron emas (har node'da boshqa soat)
   Partition (qism node'lar bir-birini ko'rmaydi — tarmoq bo'linishi)
   Tartib kafolat qiyin (qaysi event oldin?)
   Qisman nosozlik (A ishlaydi, B yo'q — noaniq holat)

   Bir kompyuter: funksiya chaqiruvi ishonchli; taqsimlangan: hammasi noaniq

Taqsimlangan tizim — ko'p node bir maqsad uchun birga (mikroservis, replicated DB, cluster). Nega qiyin (bir kompyuterda yo'q muammolar): tarmoq ishonchsiz (xabar yo'qoladi/kechikadi), node'lar yiqiladi, vaqt sinxron emas, partition (node'lar bir-birini ko'rmaydi), tartib qiyin, qisman nosozlik (noaniq holat). Bir kompyuterda funksiya chaqiruvi ishonchli; taqsimlanganda hammasi noaniq (xabar yetdimi? node tirikmi?). Bu — taqsimlangan tizimning tub qiyinligi (CAP shuni ifodalaydi).

2.2. Distributed computing fallacies (noto'g'ri taxminlar)

text

  8 FALLACY (taqsimlangan tizimning noto'g'ri taxminlari — L. Peter Deutsch):
  1. Tarmoq ishonchli ( — yo'qoladi, uziladi)
  2. Latency nol ( — masofa, kechikish bor)
  3. Bandwidth cheksiz ( — cheklangan)
  4. Tarmoq xavfsiz ( — hujum bor)
  5. Topologiya o'zgarmas ( — node qo'shiladi/o'chadi)
  6. Bitta administrator ( — ko'p)
  7. Transport narxi nol ( — serializatsiya, tarmoq)
  8. Tarmoq bir xil ( — turli)

   Bu taxminlar — eng keng XATOLAR manbai (taqsimlangan tizimda)
   Har tarmoq chaqiruvi xato bo'lishi mumkin (himoyalan — 9.6: 2.9)

Distributed computing fallacies (8 noto'g'ri taxmin — L. Peter Deutsch): tarmoq ishonchli (), latency nol (), bandwidth cheksiz (), tarmoq xavfsiz (), topologiya o'zgarmas (), va h.k. Bu taxminlar — taqsimlangan tizimdagi eng keng xatolar manbai (dasturchilar tarmoqni bir kompyuterdek deb o'ylaydi). Har tarmoq chaqiruvi xato/sekin bo'lishi mumkin himoyalanish (timeout, retry, circuit breaker — 9.6: 2.9). Bu fallacy'larni bilish — taqsimlangan tizim mulohazasining boshlanishi.

2.3. CAP teoremasi (uch xususiyat)

text

  CAP TEOREMASI (Eric Brewer 2000) — uch xususiyat:

  C — CONSISTENCY (izchillik):
      har o'qish ENG SO'NGGI yozuvni qaytaradi (barcha node bir xil)

  A — AVAILABILITY (mavjudlik):
      har so'rov JAVOB oladi (node ishlayotgan bo'lsa — kutmaydi)

  P — PARTITION TOLERANCE (bo'linishga chidamlilik):
      tarmoq bo'linsa ham tizim ISHLAYDI (node'lar bir-birini ko'rmasa ham)

  TEOREMA: tarmoq bo'linganda (P), C va A ni BIRGA olib bo'lmaydi
   faqat ikkitasi: CP yoki AP (P majburiy — tarmoq bo'linadi)

CAP teoremasi (Eric Brewer): uch xususiyat — C (consistency — har o'qish eng so'nggi yozuvni, barcha node bir xil), A (availability — har so'rov javob oladi, kutmaydi), P (partition tolerance — tarmoq bo'linsa ham ishlaydi). Teorema: tarmoq bo'linganda (P), C va A ni birga olib bo'lmaydi faqat ikkitasi: CP yoki AP. P amalda majburiy (tarmoq bo'linadi — bu haqiqat), shuning uchun haqiqiy tanlov: C yoki A (partition paytida). Bu — taqsimlangan tizimning matematik haqiqati.

2.4. Nega faqat ikkitasi (chuqur tushuntirish)

text

  TARMOQ BO'LINGANDA (partition) — 2 node bir-birini ko'rmaydi:

  Node A ──╳── Node B  (tarmoq uzildi)
  Mijoz Node A'ga yozadi (balans = 1000)

  TANLOV (A va B uzilgan):
  CP (consistency tanlash):
   Node A "men B bilan kelisha olmayman"  yozishni RAD etadi
   izchil (noto'g'ri ma'lumot yo'q), lekin MAVJUD EMAS (A ishlamaydi)

  AP (availability tanlash):
   Node A yozishni QABUL qiladi (B bilmaydi)
   mavjud (A ishlaydi), lekin IZCHIL EMAS (A=1000, B=eski)

   Uzilgan node'lar bir xil bo'la OLMAYDI + ikkalasi javob bera olmaydi
   C va A — partition paytida bir-biriga ZID (ikkalasi mumkin emas)

Nega faqat ikkitasi (chuqur): tarmoq bo'linganda 2 node bir-birini ko'rmaydi. Mijoz A'ga yozadi. CP (consistency): A "B bilan kelisha olmayman" yozishni rad etadi (izchil — noto'g'ri yo'q, lekin mavjud emas). AP (availability): A yozishni qabul qiladi (B bilmaydi) mavjud, lekin izchil emas (A yangi, B eski). Uzilgan node'lar bir vaqtda izchil (bir xil) va mavjud (javob beradi) bo'la olmaydi — bu fizik/mantiqiy haqiqat. Partition paytida C va A zid. Shuning uchun tanlov majburiy.

2.5. CP vs AP (DB tanlash)

text

  CP TIZIMLAR (Consistency + Partition — izchillikni tanlaydi):
  - Partition paytida — javob bermaydi (izchillikni saqlaydi)
  - Misol: MongoDB (default), HBase, Redis (cluster), Zookeeper
  - Qachon: izchillik kritik (bank, to'lov, inventar — noto'g'ri = falokat)

  AP TIZIMLAR (Availability + Partition — mavjudlikni tanlaydi):
  - Partition paytida — javob beradi (eski bo'lsa ham — eventual)
  - Misol: Cassandra, DynamoDB, CouchDB
  - Qachon: mavjudlik kritik (social feed, savat, like — eski OK)

   "CA" (partition'siz) — amalda yo'q (tarmoq doim bo'linadi)
   bir node DB (PostgreSQL) — CA (lekin taqsimlanmagan)

CP vs AP (DB tanlash): CP (consistency — partition paytida javob bermaydi, izchil saqlaydi — MongoDB, HBase, Zookeeper — izchillik kritik: bank, to'lov, inventar); AP (availability — partition paytida javob beradi, eski bo'lsa ham — Cassandra, DynamoDB — mavjudlik kritik: social feed, savat, like). "CA" (partition'siz) — taqsimlangan tizimda yo'q (tarmoq doim bo'linadi — P majburiy); bir node DB (PostgreSQL) — CA lekin taqsimlanmagan. DB tanlash — biznes ehtiyojiga (izchillik vs mavjudlik).

2.6. PACELC (CAP kengaytmasi — latency)

text

  PACELC (Daniel Abadi) — CAP'ning to'liqroq ifodasi:

  IF Partition (P):      A yoki C tanlash (CAP — 2.3)
  ELSE (E — normal):     L yoki C tanlash (latency yoki consistency)

   Partition YO'Q bo'lganda ham tanlov bor:
  - Latency (L): tez javob (replica'dan — eski bo'lishi mumkin)
  - Consistency (C): puxta (barcha replica kelishadi — sekinroq)

  Misol:
  - PA/EL (DynamoDB, Cassandra): mavjudlik + latency (tez, eventual)
  - PC/EC (MongoDB strong, HBase): izchillik (sekinroq, puxta)

   CAP faqat partition haqida; PACELC normal holatni ham qamraydi

PACELC (Daniel Abadi — CAP to'liqroq): IF Partition A yoki C (CAP); ELSE (normal) L yoki C (latency yoki consistency). Partition yo'q bo'lganda ham tanlov bor: tez javob (replica'dan — eski bo'lishi mumkin) yoki puxta (barcha replica kelishadi — sekinroq). Misol: DynamoDB/Cassandra (PA/EL — mavjudlik+latency); MongoDB strong/HBase (PC/EC — izchillik). PACELC realroq (CAP faqat partition; PACELC normal holatni ham — bu ko'proq vaqt). Trade-off doim bor (partition'da ham, normal'da ham).

2.7. Consistency modellari (strong eventual)

text

  CONSISTENCY SPEKTRI (kuchli  bo'sh):

  STRONG (linearizable): har o'qish eng so'nggi yozuvni (bir node kabi)
   kuchli, lekin sekin/mavjudlik past (CP)

  CAUSAL: sababiy bog'liq tartib saqlanadi (AB bo'lsa, hamma A'ni B'dan oldin)

  READ-YOUR-WRITES: o'z yozganingizni doim o'qiysiz (profil o'zgartirdingiz — ko'rasiz)
  MONOTONIC READS: bir marta yangi ko'rgach, keyin eski ko'rmaysiz (orqaga ketmaydi)
   bular "session guarantees" (foydalanuvchi seansi doirasida — eventual'ni yumshatadi)

  EVENTUAL: oxir-oqibat izchil (biroz keyin — vaqtincha eski mumkin)
   tez, mavjud (AP — 9.7: 2.7)

  BASE (NoSQL falsafasi — ACID'ga muqobil):
  Basically Available, Soft state, Eventually consistent

   ACID (6.9 — kuchli, SQL) vs BASE (bo'sh, NoSQL) — spektr
   biznes: bank  strong; feed  eventual

Consistency modellari (spektr — kuchlibo'sh): strong/linearizable (har o'qish eng so'nggi — bir node kabi — kuchli, lekin sekin/CP); causal (sababiy tartib — AB bo'lsa hamma A'ni B'dan oldin ko'radi); read-your-writes (o'z yozganingizni doim o'qiysiz) va monotonic reads (yangi ko'rgach eski ko'rmaysiz) — bular session guarantees (foydalanuvchi seansi doirasida eventual'ni yumshatadi, amaliyotda juda muhim); eventual (oxir-oqibat izchil — vaqtincha eski mumkin — tez/AP — 9.7: 2.7). BASE (NoSQL falsafasi — Basically Available, Soft state, Eventually consistent — ACID'ga muqobil). ACID (6.9 — kuchli, SQL) vs BASE (bo'sh, NoSQL) — spektr. Biznes tanlaydi: bank balansi strong; social feed eventual. Modern DB — tunable (per-query — 2.10). Consistency — biznes qarori.

2.8. Consensus (node'lar kelishuvi — Raft/Paxos)

text

  CONSENSUS — node'lar bitta qiymatga KELISHISHI (ishonchsiz tarmoqda):
  Muammo: 5 node, qaysi qiymat to'g'ri? (ba'zi yiqilgan, tarmoq sekin)

  RAFT (tushunarli, keng) / PAXOS (klassik, murakkab):
  - Leader saylanadi (bitta node — qaror qabul qiladi)
  - Majority (yarmidan ko'p — quorum) kelishsa — qaror qabul
  - Leader yiqilsa — yangi saylov

   CP tizimlar consensus ishlatadi (kuchli izchillik — etcd, Zookeeper, Raft)
   Quorum: 5 node'da 3 kelishsa — yetadi (2 yiqilsa ham ishlaydi)

   Consensus — taqsimlangan izchillikning asosi (kelishish mexanizmi)

Consensus (node'lar kelishuvi — ishonchsiz tarmoqda bitta qiymatga kelishish): muammo — 5 node, qaysi to'g'ri (ba'zi yiqilgan). Raft (tushunarli, keng) / Paxos (klassik, murakkab): leader saylanadi (qaror qabul qiladi), majority/quorum (yarmidan ko'p kelishsa — qaror), leader yiqilsa yangi saylov. CP tizimlar consensus ishlatadi (kuchli izchillik — etcd, Zookeeper, Kafka). Quorum: 5 node'da 3 kelishsa yetadi (2 yiqilsa ham ishlaydi — chidamlilik). Consensus — taqsimlangan izchillikning matematik asosi.

2.8.1. Raft batafsil (leader election + log replication)

Consensus ustuvor amaliy algoritmi — Raft (Diego Ongaro, 2014). Paxos to'g'ri, biroq tushunish qiyin bo'lgani uchun Raft "tushunarlilik" maqsadida yaratilgan va bugungi kunda etcd, Consul, TiKV, CockroachDB da ishlatiladi. Raft ikki asosiy mexanizmga bo'linadi: leader election (rahbar saylash) va log replication (jurnalni ko'chirish).

text

  RAFT — node uch holatda bo'ladi:

  FOLLOWER ──(leader'dan heartbeat kelmasa, timeout)──▶ CANDIDATE
  CANDIDATE ──(majority ovoz oldi)──▶ LEADER
  LEADER ──(kattaroq term ko'rdi)──▶ FOLLOWER

  TERM (davr) — mantiqiy vaqt hisoblagichi (monotonik o'sadi):
  har saylov yangi term boshlaydi (eski leader'ni "eskirgan" deb aniqlash)

  1) LEADER ELECTION (rahbar saylash):
     - Follower election timeout (150–300 ms tasodifiy) kutadi
     - Leader'dan heartbeat kelmasa  Candidate bo'ladi, term++
     - O'ziga ovoz beradi + boshqalardan ovoz so'raydi (RequestVote RPC)
     - Majority ovoz olsa  Leader (heartbeat yubora boshlaydi)
     - Tasodifiy timeout  split vote (bo'lingan ovoz) kamayadi

  2) LOG REPLICATION (jurnal ko'chirish):
     - Mijoz buyrug'i faqat Leader'ga boradi
     - Leader log'iga yozadi  AppendEntries RPC (follower'larga)
     - Majority follower yozgach  entry "committed" (bajarildi)
     - Committed entry state machine'ga qo'llaniladi (apply)
     - Leader commit indeksni follower'larga bildiradi

   SAFETY: faqat eng to'liq log'li node leader bo'la oladi
      committed ma'lumot hech qachon yo'qolmaydi

Raft — consensus'ning tushunarli algoritmi (etcd, Consul, CockroachDB). Node uch holatda: follower, candidate, leader. Term — mantiqiy vaqt (monotonik o'sadi, eski leader'ni aniqlaydi). 1) Leader election: follower election timeout (150–300 ms tasodifiy — split vote'ni kamaytiradi) kutadi; leader heartbeat'i kelmasa candidate bo'ladi, term++, o'ziga ovoz beradi va RequestVote yuboradi; majority ovoz olsa leader bo'ladi. 2) Log replication: mijoz buyrug'i faqat leader'ga boradi leader log'iga yozadi AppendEntries bilan follower'larga ko'chiradi majority yozgach entry "committed" state machine'ga qo'llaniladi. Safety kafolati: faqat eng to'liq log'li node leader bo'la oladi (committed ma'lumot yo'qolmaydi). Qachon kerak: distributed lock, konfiguratsiya saqlash (etcd), leader tanlash, kritik metadata. Oddiy ilovada Raft'ni o'zingiz yozmaysiz — tayyor tizim (etcd/Zookeeper) ishlatasiz.

2.8.2. Replikatsiya turlari (leader-follower / multi-leader / leaderless)

Ma'lumotni bir necha node'da nusxalash — replikatsiya 9.9-bob. Uch asosiy model bor, har biri boshqacha consistency/availability trade-off beradi.

text

  1) LEADER-FOLLOWER (master-slave) — bitta yozuvchi:
     Yozish  LEADER; o'qish  LEADER yoki FOLLOWER (replica)
     ┌────────┐  replikatsiya  ┌──────────┐
     │ LEADER │ ─────────────▶ │ FOLLOWER │ (read-only)
     └────────┘                └──────────┘
     + Oddiy, konflikt yo'q; − leader yiqilsa yozish to'xtaydi (failover)
     Sinxron replikatsiya: kuchli (sekin) | Asinxron: tez (replica lag)

  2) MULTI-LEADER (master-master) — bir necha yozuvchi:
     Har datacenter'da leader (geografik tarqoq, offline ilovalar)
     + Har mintaqada tez yozish; − KONFLIKT (bir yozuvni ikki leader o'zgartirsa)
      konflikt hal qilish kerak (2.8.5: LWW/CRDT)

  3) LEADERLESS (Dynamo-style — quorum) — leader yo'q:
     Mijoz bir necha node'ga yozadi/o'qiydi (Cassandra, DynamoDB)
     N = replika soni; W = yozish quorum; R = o'qish quorum
      R + W > N    strong consistency (o'qish va yozish quorum kesishadi)
     Misol: N=3, W=2, R=2  2+2>3  o'qish doim so'nggi yozuvni ko'radi
     N=3, W=1, R=1  tez, lekin eventual (kesishmasligi mumkin)

Replikatsiya modellari 9.9-bob: 1) Leader-follower (master-slave) — bitta yozuvchi (leader), o'qish leader yoki follower'dan; oddiy, konfliktsiz, lekin leader yiqilsa failover kerak. Replikatsiya sinxron (kuchli, sekin) yoki asinxron (tez, lekin replica lag — follower biroz orqada). 2) Multi-leader (master-master) — har datacenter'da leader (geo-tarqoq, offline ilovalar); har mintaqada tez, biroq konflikt (bir yozuvni ikki leader o'zgartirsa — hal qilish kerak). 3) Leaderless (Dynamo-style, quorum — Cassandra/DynamoDB) — leader yo'q, mijoz bir necha node bilan ishlaydi. N — replika soni, W — yozish quorum, R — o'qish quorum. R + W > N bo'lsa strong consistency (o'qish/yozish quorum'lari kesishadi — so'nggi yozuv doim ko'rinadi). Misol: N=3, W=2, R=2 kuchli; N=3, W=1, R=1 tez, lekin eventual. Bu — tunable consistency 2.10-bob ning matematik asosi.

2.8.3. Partitioning / sharding (consistent hashing)

Ma'lumot bitta node'ga sig'masa — uni bo'lish (partitioning/sharding — 9.9). Har partition mustaqil node'da yashaydi.

text

  QAYSI NODE'GA? — partitioning strategiyalari:

  RANGE (oraliq): A–H  node1, I–P  node2, Q–Z  node3
  + Oraliq so'rov tez (range scan); − nomutanosib (hot partition)

  HASH: hash(key) % N  node
  + Bir tekis taqsimot; − N o'zgarsa (node qo'shilsa) HAMMASI ko'chadi (%N buziladi)

  CONSISTENT HASHING (ring — Dynamo/Cassandra):
     Node va key'lar bitta doiraga (0..2^32) joylashadi:
        node qo'shilsa/o'chsa — faqat qo'shni key'lar ko'chadi (hammasi emas)

     VIRTUAL NODES (vnodes): har fizik node = ko'p virtual nuqta
      yuk bir tekis; rebalancing silliq (yangi node qo'shsangiz — bir oz oladi)

   Consistent hashing = elastik masshtab (rebalancing minimal)

Partitioning/sharding 9.9-bob — ma'lumot bir node'ga sig'masa uni bo'lish. Range (oraliq bo'yicha) — range-scan tez, biroq nomutanosib (hot partition). Hash (hash(key) % N) — bir tekis, lekin N o'zgarsa (node qo'shilsa) %N buzilib hammasi ko'chadi. Consistent hashing (Dynamo/Cassandra) — node va kalitlar bitta halqaga (0..2³²) joylashadi; node qo'shilsa/o'chsa faqat qo'shni kalitlar ko'chadi (hammasi emas — bu asosiy afzallik). Virtual nodes (vnodes) — har fizik node halqada ko'p nuqta egallaydi yuk bir tekis, rebalancing silliq (yangi node qo'shganda har kimdan bir oz oladi). Consistent hashing = elastik masshtab (minimal ko'chirish bilan node qo'shish/o'chirish).

2.8.4. Voqealar tartibi (Lamport timestamp, vector clock)

Taqsimlangan tizimda soatlar sinxron emas 2.1-bob — "qaysi voqea oldin bo'ldi?" degan savol qiyin. Fizik vaqt (wall clock) ishonchsiz. Yechim — mantiqiy soat.

text

  MUAMMO: node A da voqea, node B da voqea — qaysi oldin? (soatlar har xil)

  LAMPORT TIMESTAMP (mantiqiy hisoblagich):
     Har node counter tutadi; har voqeada counter++
     Xabar yuborilganda counter birga ketadi; qabul: max(o'z, kelgan)+1
      AB (sababiy) bo'lsa: L(A) < L(B) KAFOLAT
      Lekin: L(A) < L(B) bo'lsa ham AB bo'lishi SHART EMAS (faqat bir yo'nalish)

  VECTOR CLOCK (har node uchun alohida counter — [n1,n2,n3]):
     A=[2,0,0], B=[2,1,0]  A "oldin" (har komponenti ≤)
     A=[2,0,0], C=[0,0,3]  KONKURENT (taqqoslab bo'lmaydi — konflikt!)
      Sababiylikni TO'LIQ aniqlaydi (konkurent yozuvlarni topadi)

   Vector clock: konfliktni aniqlash (Dynamo, Riak — 2.8.5)

Voqealar tartibi: taqsimlangan tizimda soatlar sinxron emas, shuning uchun "qaysi voqea oldin?" fizik vaqt bilan aniqlanmaydi. Lamport timestamp — har node counter tutadi (har voqeada ++), xabar bilan counter ketadi, qabulda max(o'z, kelgan)+1. Kafolat: sababiy bog'liq bo'lsa (AB) L(A) < L(B); lekin teskarisi shart emas (L(A)<L(B) bo'lsa ham AB bo'lmasligi mumkin). Vector clock — har node uchun alohida counter ([n1,n2,n3]): agar bir vektorning har komponenti ikkinchisidan ≤ bo'lsa — biri "oldin"; aks holda konkurent (taqqoslab bo'lmaydi — konflikt!). Vector clock sababiylikni to'liq aniqlaydi va konkurent yozuvlarni (konflikt) topadi — shuning uchun Dynamo/Riak konflikt aniqlashda ishlatadi.

2.8.5. Konflikt hal qilish (LWW, CRDT, version vector)

AP/multi-leader tizimlarda bir yozuv turli node'da har xil o'zgarishi mumkin (2.8.4 — konkurent). Konfliktni hal qilish kerak.

text

  KONFLIKT: X=5 (node A), X=8 (node B) — bir vaqtda (konkurent)

  1) LWW (Last-Write-Wins): eng katta timestamp yutadi
     + Oddiy; − MA'LUMOT YO'QOLADI (bir yozuv ustidan yoziladi)
      Cassandra default (timestamp bo'yicha)

  2) VERSION VECTOR / siblings: ikkala qiymatni SAQLA
      ilova/foydalanuvchi hal qiladi (savat: birlashtirish)
     Dynamo/Riak: konkurent yozuvlar = siblings (app resolve)

  3) CRDT (Conflict-free Replicated Data Type): avtomatik birlashadi
     Ma'lumot turi shunday tuzilganki, har tartibda birlashsa BIR XIL natija
     Misol: G-Counter (o'suvchi hisoblagich), OR-Set (qo'shish/o'chirish to'plami)
      Redis CRDT, Riak, kollaborativ editor (Google Docs, Figma)

   LWW = oddiy lekin yo'qotish; CRDT = murakkab lekin yo'qotishsiz

Konflikt hal qilish (AP/multi-leader): 1) LWW (Last-Write-Wins) — eng katta timestamp yutadi; oddiy, biroq ma'lumot yo'qoladi (Cassandra default). 2) Version vector / siblings — ikkala qiymatni saqlash, ilova/foydalanuvchi hal qiladi (masalan xarid savati — birlashtirish; Dynamo/Riak). 3) CRDT (Conflict-free Replicated Data Type) — ma'lumot turi shunday tuzilganki, qaysi tartibda birlashtirilsa ham bir xil natija (G-Counter — o'suvchi hisoblagich, OR-Set — to'plam). CRDT Redis, Riak va kollaborativ muharrirlarda (Google Docs, Figma) ishlatiladi. LWW oddiy, ammo yo'qotadi; CRDT murakkab, ammo yo'qotishsiz avtomatik birlashadi.

2.8.6. Distributed tranzaksiya (2PC / 3PC / Saga / TCC)

Bir necha node/xizmat bo'ylab atomik o'zgartirish — taqsimlangan tranzaksiya (05/07-bob, 9.5 Saga). Bir DB dagi ACID 6.9-bob bu yerda ishlamaydi.

text

  1) 2PC (Two-Phase Commit) — koordinator boshqaradi:
     FAZA 1 (prepare): koordinator "tayyormisiz?"  hamma "HA/YO'Q"
     FAZA 2 (commit):  hamma HA desa  "commit"; biri YO'Q  "abort"
      MO'RT: koordinator faza 2 da yiqilsa  node'lar LOCK'da qotadi (bloklanish)
      Sinxron, sekin, availability past (CP)

  3PC: qo'shimcha "pre-commit" fazasi (bloklanishni kamaytiradi)
      murakkabroq, amalda kam (tarmoq partition'da baribir muammo)

  2) SAGA (eventual — 9.5, 07-bob): lokal tranzaksiyalar ketma-ketligi
     Har qadam mustaqil commit; xato  KOMPENSATSIYA (orqaga qadam)
     + Bloklanmaydi, availability yuqori; − eventual (oraliq holat ko'rinadi)

  3) TCC (Try-Confirm-Cancel): biznes-darajali 2PC
     TRY: resursni REZERV qil (masalan pulni "muzlat")
     CONFIRM: rezervni tasdiqla | CANCEL: rezervni bo'shat
      Saga'dan qat'iyroq (rezerv orqali izolyatsiya)

   Taqsimlanganda 2PC'dan qoch (mo'rt)  Saga/TCC (eventual, chidamli)

Distributed tranzaksiya (05/07-bob, 9.5): 1) 2PC (Two-Phase Commit) — koordinator boshqaradi: prepare ("tayyormisiz?") hamma "ha" desa commit, biri "yo'q" desa abort. Mo'rt: koordinator 2-fazada yiqilsa node'lar lock'da qotadi (bloklanish); sinxron, sekin, availability past. 3PC qo'shimcha "pre-commit" bilan bloklanishni kamaytiradi, biroq murakkab va amalda kam (partition'da baribir muammo). 2) Saga (9.5, 07-bob) — lokal tranzaksiyalar ketma-ketligi, har qadam mustaqil commit, xato bo'lsa kompensatsiya (orqaga qadam); bloklanmaydi, availability yuqori, biroq eventual (oraliq holat ko'rinadi). 3) TCC (Try-Confirm-Cancel) — biznes-darajali 2PC: Try (resursni rezerv qiladi, masalan pulni "muzlatadi"), Confirm (tasdiq) yoki Cancel (bo'shatish); Saga'dan qat'iyroq (rezerv orqali izolyatsiya). Taqsimlanganda 2PC'dan qoching (mo'rt) — Saga/TCC afzal (eventual, chidamli).

2.8.7. Nosozlikni aniqlash, heartbeat, split-brain

Taqsimlangan tizim node yiqilganini bilishi kerak (leader saylash, failover uchun). Biroq "node yiqildi"mi yoki "tarmoq sekin"mi — farqlash qiyin 2.1-bob.

text

  FAILURE DETECTION (nosozlikni aniqlash):

  HEARTBEAT: har node davriy "tirikman" signali yuboradi
     N ta heartbeat kelmasa  "o'lgan" deb hisobla
      Muammo: tarmoq sekinligi = "o'lgan" deb xato aniqlash (false positive)

  PHI-ACCRUAL (Cassandra, Akka): binar emas — SHUBHA darajasi (phi)
     Tarmoq statistikasiga qarab moslashadi (o'zgaruvchan kechikish)
      aniqroq (barqaror tarmoqda tez, o'zgaruvchanida sabrli)

  SPLIT-BRAIN (miya bo'linishi) — partition'ning xavfli holati:
     Partition tufayli IKKI node o'zini "leader" deb biladi
      ikkalasi yozadi = ma'lumot buziladi (falokat!)

  YECHIM: QUORUM (majority) — faqat yarmidan ko'p node ko'rgan tomon ishlaydi
      ozchilik tomon o'zini o'chiradi (fencing / STONITH)
     3 node: 2 vs 1  2-taraf leader, 1-taraf to'xtaydi (split-brain yo'q)

Nosozlikni aniqlash: node yiqilganini bilish kerak (failover uchun), biroq "yiqildi"mi yoki "tarmoq sekin"mi — farqlash qiyin. Heartbeat — har node davriy "tirikman" signali; N marta kelmasa "o'lgan" deb hisoblanadi (kamchilik: tarmoq sekinligi false positive beradi). Phi-accrual (Cassandra, Akka) — binar emas, shubha darajasi (phi) qaytaradi va tarmoq statistikasiga moslashadi (aniqroq). Split-brain (miya bo'linishi) — partition'ning eng xavfli holati: ikki node o'zini "leader" deb biladi va ikkalasi yozadi ma'lumot buziladi. Yechim: quorum (majority) — faqat yarmidan ko'p node ko'rgan tomon ishlaydi, ozchilik o'zini o'chiradi (fencing). Shuning uchun klasterlar toq sonli (3, 5) node bilan quriladi (majority aniq bo'lishi uchun).

2.8.8. Vaqt: clock skew, NTP, TrueTime

Taqsimlangan tizimda vaqtga ishonmang — har node soatida farq (clock skew) bor 2.1-bob. Bu tartib, TTL, timestamp uchun muammo.

text

  CLOCK SKEW: node A soati 10:00:05, node B 10:00:02 (3s farq)
   timestamp bo'yicha tartib XATO bo'lishi mumkin (LWW noto'g'ri yutadi)

  NTP (Network Time Protocol): soatlarni sinxronlash (server bilan)
   farqni kamaytiradi (odatda ~ms), lekin NOL emas (kafolat yo'q)

  GOOGLE TRUETIME (Spanner): vaqtni ORALIQ sifatida beradi [earliest, latest]
   GPS + atom soat; noaniqlikni (uncertainty) O'LCHAYDI (~7ms)
  Spanner "commit wait": noaniqlik oralig'i o'tguncha kutadi
   global strong consistency (external consistency) — soatga asoslangan

   Oddiy tizimda: fizik vaqtga tartib uchun ISHONMANG  mantiqiy soat (2.8.4)

Vaqt — taqsimlangan tizimning yashirin tuzoqi. Clock skew — node soatlari orasidagi farq (3s ham bo'lishi mumkin) timestamp bo'yicha tartib xato (LWW noto'g'ri qiymatni yutqazadi). NTP (Network Time Protocol) soatlarni serverga sinxronlaydi (farqni ~ms ga tushiradi, biroq nol emas — kafolat yo'q). Google TrueTime (Spanner) vaqtni bitta nuqta emas, oraliq [earliest, latest] sifatida beradi (GPS + atom soat, noaniqlikni ~7ms o'lchaydi); Spanner commit wait bilan noaniqlik o'tguncha kutadi va global strong consistency (external consistency) beradi. Oddiy tizimda tartib uchun fizik vaqtga ishonmang — mantiqiy soat (2.8.4) ishlating. TrueTime — Google infratuzilmasi (GPS/atom soat) tufayli mumkin, oddiy bulut'da yo'q.

2.8.9. Idempotency va distributed tracing

Taqsimlangan tizim ishonchli bo'lishi uchun ikki amaliy tayanch: idempotency (takror xavfsizligi) va observability (kuzatuvchanlik).

text

  IDEMPOTENCY 8.20-bob: bir amal bir necha marta bajarilsa ham NATIJA BIR XIL
   tarmoq ishonchsiz (fallacy 2.2)  retry bo'ladi  dublikat xavfi
  Yechim: idempotency key (client yuboradi)  server takrorni tanadi
  Misol: to'lov "req-123" — ikki marta kelsa, bir marta bajariladi

  DISTRIBUTED TRACING (kuzatuv — bitta so'rov ko'p xizmat bo'ylab):
     Trace ID: so'rov boshida yaraladi, hamma xizmatga UZATILADI
     Span: har xizmatdagi ish qismi (vaqt, xato)
     Gateway  Order(span)  Payment(span)  Inventory(span)
      butun yo'lni ko'rish (qayerda sekin/xato — 9.6)
  Standart: OpenTelemetry; ko'rish: Jaeger, Zipkin, Tempo

   Taqsimlanganda: idempotency (retry xavfsiz) + tracing (xatoni topish) SHART

Idempotency 8.20-bob — bir amal necha marta bajarilsa ham natija bir xil. Tarmoq ishonchsiz (2.2) retry bo'ladi dublikat xavfi (masalan ikki marta to'lov). Yechim — idempotency key (mijoz req-123 yuboradi, server takrorni tanib bir marta bajaradi). Distributed tracing — bitta so'rov ko'p xizmat bo'ylab o'tadi, uni kuzatish uchun trace ID so'rov boshida yaratilib hamma xizmatga uzatiladi; har xizmatdagi ish qismi — span (vaqt, xato). Bu butun yo'lni ko'rsatadi (qayerda sekin/xato — 9.6). Standart — OpenTelemetry; ko'rish vositalari — Jaeger, Zipkin, Tempo. Taqsimlangan tizimda idempotency (retry xavfsizligi) va tracing (nosozlikni topish) — majburiy amaliyot.

2.9. Amaliy ma'no (qaror)

text

  CAP/PACELC AMALDA (qaror qabul qilish):

  Ma'lumot izchilligi KRITIKmi? (noto'g'ri = falokat)
   HA (bank balansi, inventar, to'lov)  CP/strong (PostgreSQL, MongoDB strong)
   YO'Q (feed, like, savat)  AP/eventual (Cassandra, DynamoDB)

  Misollar:
  - Bank o'tkazma  strong consistency (CP) — pul yo'qolmasligi kerak
  - Instagram like soni  eventual (AP) — biroz noto'g'ri OK (mavjudlik muhim)
  - E-commerce inventar  strong (oxirgi mahsulot ikki kishiga sotilmasin)
  - Social feed  eventual (1s eski post — muammo emas)

   Bir tizimda har xil (balans — strong; feed — eventual) — tunable

Amaliy ma'no (qaror): izchillik kritikmi? Ha (bank balansi, inventar, to'lov — noto'g'ri = falokat) CP/strong (PostgreSQL, MongoDB strong); yo'q (feed, like, savat — eski OK) AP/eventual (Cassandra, DynamoDB). Misol: bank o'tkazma strong (pul yo'qolmasin); Instagram like eventual (mavjudlik muhim); e-commerce inventar strong (oxirgi mahsulot ikki kishiga sotilmasin). Bir tizimda har xil (balans strong, feed eventual — tunable — 2.10). CAP — biznes ehtiyojiga texnik qaror.

2.10. Modern yondashuv (tunable consistency)

text

  MODERN DB — TUNABLE consistency (per-query tanlov):

  Eski: DB butunlay CP yoki AP (qat'iy)
  Modern: har so'rovga consistency darajasi (moslashuvchan)

  Misol (Cassandra/DynamoDB):
  - Muhim yozish  QUORUM (kuchli — majority kelishadi)
  - Oddiy o'qish  ONE (tez — bitta node yetadi)

   Bir ilovada: kritik (balans) strong; oddiy (profil) eventual
   Eng yaxshi balans (har ma'lumotga mos consistency)

   CAP "qat'iy ikkitasi" emas — spektr (per-operation tanlov)

Modern yondashuv (tunable consistency): eski DB butunlay CP yoki AP (qat'iy); modern — per-query consistency (moslashuvchan). Cassandra/DynamoDB: muhim yozish QUORUM (kuchli — majority); oddiy o'qish ONE (tez — bitta node). Bir ilovada har xil: kritik (balans) strong, oddiy (profil) eventual. Eng yaxshi balans (har ma'lumotga mos). CAP — "qat'iy ikkitasi" emas, spektr (per-operation). Bu — 2026 amaliyoti (qattiq CP/AP emas, moslashuvchan). Pragmatik consistency.

2.11. Best practices (distributed/CAP)

text

   Fallacy'larni bil (tarmoq ishonchsiz — himoyalan — 2.2, 9.6: 2.9)
   CAP: izchillik kritik  CP; mavjudlik kritik  AP (2.5, 2.9)
   PACELC: normal holatda ham latency vs consistency 2.6-bob
   Consistency biznesga mos (bank strong, feed eventual — 2.7, 2.9)
   Tunable consistency (per-query — modern — 2.10)
   Consensus (CP — Raft/quorum — 2.8)
   Eventual consistency'ni boshqar (9.7: 2.7 — UI, version)
   Taqsimlanmagan yetsa — taqsimlama (monolit — 9.5; bir DB — CA)
   Idempotency, timeout, retry (taqsimlangan ishonchlilik — 9.6)

3. Sintaksis — tez ma'lumotnoma

text

CAP 2.3-bob: C (izchillik) | A (mavjudlik) | P (bo'linish) — partition'da C yoki A
CP 2.5-bob: MongoDB strong, PostgreSQL, Zookeeper (izchillik — bank)
AP 2.5-bob: Cassandra, DynamoDB (mavjudlik — feed)
PACELC 2.6-bob: partition'da A/C; normal'da L/C
Consistency 2.7-bob: strong  causal  read-your-writes  eventual (ACID  BASE)
Consensus 2.8-bob: Raft/Paxos — leader + quorum (majority)
Raft (2.8.1): leader election (term, RequestVote) + log replication (AppendEntries)
Replikatsiya (2.8.2): leader-follower | multi-leader | leaderless (R+W>N = strong)
Sharding (2.8.3): range | hash | consistent hashing (vnodes, minimal rebalancing)
Tartib (2.8.4): Lamport timestamp | vector clock (konkurent = konflikt)
Konflikt (2.8.5): LWW (yo'qotish) | version vector (siblings) | CRDT (yo'qotishsiz)
Dist. tranzaksiya (2.8.6): 2PC (mo'rt) | Saga (eventual) | TCC (rezerv)
Nosozlik (2.8.7): heartbeat | phi-accrual | split-brain  quorum/fencing
Vaqt (2.8.8): clock skew | NTP (~ms) | TrueTime (oraliq, Spanner)
Amaliyot (2.8.9): idempotency (key) | tracing (trace ID + span, OpenTelemetry)
Tunable 2.10-bob: per-query consistency (QUORUM/ONE)

4. Batafsil kod namunalari

Misol 1 — Fallacy himoyasi (tarmoq ishonchsiz — 2.2)

typescript

// Tarmoq ishonchsiz  har chaqiruvni himoyala (9.6: 2.9)
async tashqiXizmat(data: any) {
  return firstValueFrom(
    this.http.post("http://service-b/api", data).pipe(
      timeout(5000),                                  // latency NOL emas (fallacy 2)
      retry({ count: 3, delay: 1000 }),               // tarmoq ishonchsiz (fallacy 1)
      catchError((e) => {
        // Node yiqilishi mumkin (qisman nosozlik — 2.1)
        throw new ServiceUnavailableException("Xizmat javob bermadi");
      }),
    ),
  );
}
//  Bir kompyuterda funksiya chaqiruvi ishonchli; tarmoqda — himoya kerak (2.2)

Misol 2 — CP tizim (strong consistency — 2.5)

typescript

// Bank o'tkazma — STRONG consistency kerak (CP — izchillik kritik — 2.9)
async pulOtkaz(fromId: string, toId: string, summa: number) {
  // Tranzaksiya (ACID — 6.9) — strong consistency (bir DB / consensus)
  return this.dataSource.transaction("SERIALIZABLE", async (manager) => {   // eng kuchli izolyatsiya
    const from = await manager.findOne(Account, { where: { id: fromId }, lock: { mode: "pessimistic_write" } });
    if (from.balans < summa) throw new BadRequestException("Mablag' yetarli emas");
    await manager.decrement(Account, { id: fromId }, "balans", summa);
    await manager.increment(Account, { id: toId }, "balans", summa);
    //  izchil (pul yo'qolmaydi/ikkilanmaydi); partition'da rad etadi (CP)
  });
}
//  Pul = strong consistency (eventual XATO — pul ikki marta/yo'qolishi mumkin)

Misol 3 — AP tizim (eventual consistency — 2.5, 2.7)

typescript

// Like soni — EVENTUAL consistency OK (AP — mavjudlik kritik — 2.9)
async like(postId: string, userId: string) {
  // Tez yozish (eventual — biroz noto'g'ri son OK)
  await this.redis.sadd(`post:${postId}:likes`, userId);   // tez (mavjud)
  // Like soni eventual — keyin DB'ga sinxron (background)
  this.eventEmitter.emit("like.added", { postId });        // async (9.7)
  // Darrov taxminiy son (aniq emas — lekin mavjud, tez)
  return { likes: await this.redis.scard(`post:${postId}:likes`) };
}
//  Like soni 1-2 farq qilsa — muammo emas (mavjudlik muhim — partition'da ham ishlaydi)

Misol 4 — Consistency tanlovi (biznesga qarab — 2.9)

typescript

// Bir ilovada HAR XIL consistency (biznesga mos — 2.9, 2.10)
@Injectable()
export class OrderService {
  async buyurtmaYarat(dto: any) {
    // Inventar — STRONG (oxirgi mahsulot ikki kishiga sotilmasin — 2.9)
    return this.dataSource.transaction(async (manager) => {
      const product = await manager.findOne(Product, {
        where: { id: dto.productId }, lock: { mode: "pessimistic_write" },   // strong
      });
      if (product.zaxira < dto.miqdor) throw new BadRequestException("Zaxira yo'q");
      await manager.decrement(Product, { id: dto.productId }, "zaxira", dto.miqdor);
      const order = await manager.save(Order, dto);
      return order;
    });
  }

  async tavsiyalar(userId: string) {
    // Tavsiyalar — EVENTUAL OK (biroz eski — mavjudlik muhim — 2.9)
    return this.cache.get(`recommendations:${userId}`);   // cache (eventual, tez)
  }
}

Misol 5 — Quorum (consensus — 2.8)

typescript

// Tunable consistency — Cassandra/DynamoDB quorum (2.10)
// Yozish — QUORUM (majority kelishsin — kuchli)
await cassandra.execute(query, params, {
  consistency: cassandra.types.consistencies.quorum,   // majority node (kuchli — 2.8)
});

// O'qish — ONE (tez — bitta node yetadi — oddiy ma'lumot)
await cassandra.execute(readQuery, params, {
  consistency: cassandra.types.consistencies.one,      // tez (eventual — 2.10)
});
//  QUORUM yozish + QUORUM o'qish = strong (R+W > N); ONE = tez/eventual
//  per-query tanlov (kritik strong, oddiy tez — 2.10)

Misol 6 — Eventual consistency boshqaruvi (2.7, 9.7)

typescript

// Eventual consistency — UI/version bilan boshqarish (9.7: 2.7)
@Post("orders")
async yarat(@Body() dto: any) {
  const order = await this.commandBus.execute(new CreateOrderCommand(dto));
  // Read model eventual (replica/projection biroz orqada — 2.7)
  return {
    order,
    version: order.version,                           // versiya (consistency token)
    // Frontend: bu version bilan o'qiydi (read model tayyor bo'lguncha poll)
  };
}
// Yoki write natijasini darrov qaytarish (read'siz — stale oldini olish)

Misol 7 — CAP qaror jadvali (DB tanlash — 2.5, 2.9)

text

  DB TANLASH (CAP asosida):

  ┌─────────────────┬──────────┬─────────────────────────────┐
  │ Ehtiyoj         │ Tanlov   │ DB                          │
  ├─────────────────┼──────────┼─────────────────────────────┤
  │ Bank, to'lov    │ CP/strong│ PostgreSQL (ACID — 6.9)     │
  │ Inventar        │ CP/strong│ PostgreSQL, MongoDB strong  │
  │ User profil     │ CP       │ PostgreSQL/MongoDB          │
  │ Social feed     │ AP/event │ Cassandra, DynamoDB         │
  │ Like/view soni  │ AP/event │ Cassandra, Redis            │
  │ Log/analytics   │ AP       │ Cassandra, Elasticsearch    │
  │ Cache/sessiya   │ AP       │ Redis 8.15-bob                │
  │ Config/lock     │ CP       │ etcd, Zookeeper (consensus) │
  └─────────────────┴──────────┴─────────────────────────────┘
   Izchillik kritik  CP; mavjudlik/masshtab kritik  AP

Misol 8 — Distributed lock (consensus amaliyoti — 2.8)

typescript

// Taqsimlangan lock — bir vaqtda bitta node bajarishi (8.18: 2.14, Redis/consensus)
async kritikIsh(resurs: string) {
  // Redis lock (oddiy — yetarli ko'p holatda)
  const lock = await this.redis.set(`lock:${resurs}`, this.nodeId, "EX", 30, "NX");
  if (!lock) throw new ConflictException("Resurs band (boshqa node)");
  try {
    await this.bajar(resurs);                         // faqat bitta node (izchil)
  } finally {
    // Lock'ni faqat egasi o'chiradi (Lua — atomik)
    await this.redis.eval(`if redis.call("get",KEYS[1])==ARGV[1] then return redis.call("del",KEYS[1]) end`,
      1, `lock:${resurs}`, this.nodeId);
  }
}
//  Kuchli kafolat kerak bo'lsa — Zookeeper/etcd (consensus — 2.8); Redis — oddiy holatlar

Misol 9 — Saga (taqsimlangan tranzaksiya — CAP amaliyoti — 9.5)

typescript

// Taqsimlangan tizimda ACID yo'q  Saga (eventual consistency — 9.5: 2.10)
async buyurtmaSaga(dto: any) {
  const order = await this.orderService.yarat(dto);   // 1-node (xizmat)
  try {
    await this.inventoryService.band(dto);            // 2-node (tarmoq — fallacy 2.2)
    await this.paymentService.tolov(dto);             // 3-node
    await this.orderService.tasdiqla(order.id);
  } catch (e) {
    // Kompensatsiya (orqaga — taqsimlangan "rollback" — eventual)
    await this.inventoryService.bekor(dto);
    await this.orderService.bekor(order.id);
    throw e;
  }
}
//  Taqsimlangan: ACID o'rniga Saga (eventual consistency — CAP haqiqati)

Misol 10 — Taqsimlangan tizim qaror (umumiy)

text

  TAQSIMLANGAN TIZIM QARORI (CAP/PACELC asosida):

  1. Taqsimlangan KERAKMI? 9.5-bob
      YO'Q (kichik)  monolit + bir DB (CA — eng oddiy, izchil)
      HA  davom et (CAP qoidalari)

  2. Ma'lumot izchilligi kritikmi?
      HA (pul, inventar)  CP/strong (PostgreSQL, transaction — Misol 2)
      YO'Q (feed, like)  AP/eventual (Misol 3)

  3. Aralash?  tunable / har ma'lumotga mos (Misol 4, 2.10)

  4. Taqsimlangan amaliyot:
     - Fallacy himoya (timeout/retry — Misol 1)
     - Taqsimlangan tranzaksiya  Saga (Misol 9)
     - Lock  Redis/consensus (Misol 8)
     - Eventual  UI/version boshqar (Misol 6)

   Eng oddiy yechim (monolit/bir DB) yetsa — taqsimlama (CAP murakkabligidan qoch)

5. To'g'ri va noto'g'ri holatlar

1) Tarmoqni ishonchli deb taxmin

text

 timeout/retry'siz (fallacy — 2.2)
 himoya (timeout, retry, circuit breaker — 9.6)

2) Pulga eventual consistency

text

 bank balansi eventual (pul yo'qoladi — 2.9)
 strong consistency (CP — ACID)

3) Like'ga strong consistency

text

 like soni strong (sekin, mavjudlik past — 2.9)
 eventual (AP — tez, mavjud)

4) Kichik loyihaga taqsimlangan

text

 keraksiz taqsimlash (CAP murakkabligi — 9.5)
 monolit + bir DB (CA — oddiy)

5) CAP'ni "har doim ikkitasi" deb qat'iy olish

text

 butunlay CP yoki AP (2.10)
 tunable (per-query — har ma'lumotga mos)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — Taqsimlangan tizim "bir kompyuter"dek

Sababi: fallacy 2.2-bob. Yechimi: tarmoq ishonchsiz — himoya 9.6-bob.

Xato 2 — Ma'lumot nomutanosib (replica)

Sababi: eventual consistency e'tiborsiz 2.7-bob. Yechimi: strong (kritik) / boshqaruv (UI/version).

Xato 3 — Noto'g'ri DB (CAP)

Sababi: ehtiyoj DB mos emas 2.5-bob. Yechimi: izchillik kritik CP; mavjudlik AP.

Xato 4 — Taqsimlangan tranzaksiya buzildi

Sababi: ACID yo'q 2.4-bob. Yechimi: Saga + kompensatsiya (Misol 9).

Xato 5 — Distributed lock ishonchsiz

Sababi: oddiy lock (race). Yechimi: atomik (Redis Lua / consensus — Misol 8).

Xato 6 — Over-engineering (taqsimlangan)

Sababi: keraksiz taqsimlash. Yechimi: monolit/bir DB yetsa — shu 9.5-bob.

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

Mikroservis 9.5-bob: taqsimlangan tizim.
Eventual consistency 9.7-bob: AP/CQRS.
Replication 9.9-bob: CAP amaliyoti.
ACID 6.9-bob: strong consistency (CP).
Saga 9.5-bob: taqsimlangan tranzaksiya.
Ishonchlilik 9.6-bob: fallacy himoya.
DB tanlash: SQL (CP) vs NoSQL (AP — 6.1).
Lock 8.18-bob: consensus.

8. Eng yaxshi amaliyotlar (best practices)

Fallacy'larni bil (tarmoq ishonchsiz — himoyalan — 2.2).
CAP: izchillik kritik CP; mavjudlik AP (2.5, 2.9).
PACELC (normal holatda ham latency vs consistency — 2.6).
Consistency biznesga mos (bank strong, feed eventual — 2.9).
Tunable consistency (per-query — modern — 2.10).
Consensus (CP — Raft/quorum — 2.8).
Eventual consistency boshqaruvi (UI/version — 9.7).
Taqsimlanmagan yetsa — taqsimlama (monolit/CA — 9.5).
Idempotency, timeout, retry (taqsimlangan ishonchlilik — 9.6).
Saga (taqsimlangan tranzaksiya — 9.5).

9. Amaliy loyiha: "Taqsimlangan Tizim Qarorlari"

CAP/distributed'ni amalda mustahkamlash.

Maqsad

Taqsimlangan tizimda to'g'ri consistency qarorlari: CP (kritik), AP (mavjudlik), tunable.

Talablar (requirements)

Fallacy himoya: timeout/retry (Misol 1, 2.2).
CP (strong): bank/inventar transaction (Misol 2, 4, 2.5).
AP (eventual): like/feed (Misol 3, 2.5).
Aralash consistency: biznesga qarab (Misol 4, 2.9).
Quorum: tunable (Misol 5, 2.10).
Eventual boshqaruv: version/UI (Misol 6, 2.7).
DB tanlash: CAP jadvali (Misol 7, 2.5).
Distributed lock: atomik (Misol 8, 2.8).
Saga: taqsimlangan tranzaksiya (Misol 9, 9.5).
Qaror: taqsimlangan kerakmi (Misol 10).

Maslahatlar (hint)

Fallacy himoya (2.2, 1-xato).
Pul strong (2.9, 2-holat).
Like eventual (2.9, 3-holat).
Tunable (2.10, 5-holat).
Saga (taqsimlangan ACID yo'q — 2.4, 4-xato).
Oddiy yetsa — taqsimlama (9.5, 4-holat).

"Tayyor" mezonlari (acceptance criteria)

Fallacy himoya.
CP (strong).
AP (eventual).
Aralash consistency.
Quorum.
Eventual boshqaruv.
DB tanlash (CAP).
Distributed lock.
Saga.
Qaror.

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa va keyingi bobga ko'prik

Bu bobda taqsimlangan tizimlar va CAP'ni chuqur o'rgandik:

Taqsimlangan tizim (nega qiyin — 2.1); fallacies (noto'g'ri taxminlar — 2.2); CAP teoremasi (C/A/P — ikkitasi — 2.3, 2.4).
CP vs AP (DB tanlash — 2.5); PACELC (latency — 2.6); consistency modellari (strong/eventual/BASE — 2.7); consensus (Raft/quorum — 2.8).
Amaliy ma'no (qaror — 2.9); tunable consistency (modern — 2.10).

9-QISM (Arxitektura va ilg'or backend) TO'LIQ TUGADI! (9.1–9.10: SOLID, design patterns, Clean Architecture, DDD, monolith vs microservices, service communication, event-driven/CQRS/ES, API Gateway, scalability, distributed/CAP). Endi siz arxitektor darajasidagi fikrlashga egasiz — texnologiyani bilish emas, to'g'ri qaror qabul qilish (qaysi arxitektura, qaysi DB, qaysi consistency).

Keyingi QISM — 10-QISM: DevOps va Deploy (Linux, SSH, Nginx, Docker, CI/CD, AWS, Kubernetes, monitoring). Bu — kodni real dunyoda ishga tushirish va boshqarish — "ideal backendchi" ning eng katta yetishmayotgan bo'lagi (siz so'ragan).

Foydalanilgan rasmiy/ishonchli manbalar

Fundamental nazariya:

Eric Brewer — "CAP Theorem" (2000, keyingi qayta ko'rib chiqish: "CAP Twelve Years Later")
Seth Gilbert, Nancy Lynch — CAP teoremasining rasmiy isboti
Daniel Abadi — "Consistency Tradeoffs in Modern Distributed Database System Design" (PACELC)
L. Peter Deutsch, James Gosling — "Fallacies of Distributed Computing" (8 fallacy)

Consensus va algoritmlar:

Diego Ongaro, John Ousterhout — "In Search of an Understandable Consensus Algorithm" (Raft), raft.github.io
Leslie Lamport — "Paxos Made Simple"; "Time, Clocks, and the Ordering of Events" (Lamport timestamp)

Replikatsiya, konflikt, vaqt:

Amazon — "Dynamo: Amazon's Highly Available Key-value Store" (leaderless quorum, consistent hashing, vector clock)
Marc Shapiro va boshqalar — CRDT (Conflict-free Replicated Data Types) tadqiqoti
Google — "Spanner: Google's Globally-Distributed Database" (TrueTime, external consistency)

Kitob va hujjatlar:

Martin Kleppmann — "Designing Data-Intensive Applications" (taqsimlangan tizim bo'yicha asosiy manba)
Cassandra, MongoDB, DynamoDB, etcd rasmiy hujjatlari — consistency darajalari
OpenTelemetry rasmiy hujjatlari — distributed tracing

Izohlar (0)

Izoh yozish uchun kiring.

Hozircha izoh yo'q. Birinchi bo'ling!