Biz sizni sistema dizayn intervyuolarini o'rganishda bizga qo'shilishga qaror qilganingizdan juda xursandmiz. Sistema dizayn intervyu savollari barcha texnik intervyular orasida eng qiyin bo'lib hisoblanadi. Savollar intervyuistlardan dasturiy ta'minot tizimining arxitekturasini loyihalashni talab qiladi, bu yangiliklar tasmasi, Google qidiruvi, chat tizimi va boshqalar bo'lishi mumkin. Bu savollar qo'rqinchli bo'lib, ularga amal qilish uchun muayyan namuna yo'q. Savollar odatda juda katta qamravli va noaniq bo'ladi. Jarayonlar ochiq va standart yoki to'g'ri javobsiz ravshan bo'lmagan.

Kompaniyalar sistem dizayn intervyualarini keng qabul qiladi, chunki bu intervyularda sinagan muloqot va muammolarni hal qilish ko'nikmalari dasturiy injinerni kundalik ishida talab qiladigan ko'nikmalarga o'xshash. Intervyustit qanday qilib noaniq muammoni tahlil qilishi va muammoni qadam-ba-qadam qanday hal qilishi bo'yicha baholanadi. Sinangan qobiliyatlar shuningdek, u o'z g'oyasini qanday tushuntirishi, boshqalarni bilan muhokama qilishi va tizimni baholashi va optimallashtirishi bilan bog'liq. Ingliz tilida "she" "he or she" yoki ularni o'rtasida o'zgartirishdan ko'ra yaxshi oqadi. O'qishni osonlashtirish uchun biz butun kurs davomida ayol olmoshini ishlatamiz. Erkak injinerlar uchun hech qanday beshishaw niyati yo'q.

Sistema dizayn savollari ochiq-oydindir. Real dunyoda bo'lgani kabi, tizimda ko'p farqlar va o'zgarishlar mavjud. Kerakli natija sistema dizayn maqsadlarini erishish uchun arxitektura o'ylash bo'ladi. Muhokamalar intervyuist qayd qilgan yo'nalish asosida turli xil yo'llar bilan ketishi mumkin. Ba'zi intervyuistlar barcha aspektlarni qamrab olish uchun yuqori darajali arxitekturani tanlashlari mumkin; ba'zilari esa bir yoki bir nechta sohalarga e'tibor qaratishlari mumkin. Odatda, sistema talablari, cheklovlari va engilliklari intervyuist va intervyustin yo'nalishini shakllantirish uchun yaxshi tushunilishi kerak.

Bu kursning maqsadi sistema dizayn savollariga yondashish uchun ishonchli strategiya taqdim etishdir. To'g'ri strategiya va bilim intervyu muvaffaqiyatiga juda muhimdir.

Bu kurs masshtablanuvchi tizim qurish bo'yicha mustahkam bilim beradi. Siz bu kursni o'qishdan ko'proq bilim olsangiz, sistema dizayn savollarini hal qilishda shuncha yaxshi tayyorlangan bo'lasiz.

Bu kurs shuningdek sistema dizayn savolini qanday hal qilish bo'yicha bosqichma-bosqich framework taqdim etadi. U tizimli yondashuvni siz amal qila olgan batafsil qadam-badam bilan tasvirlash uchun ko'p misollarni taqdim etadi. Doimiy amaliyot bilan, siz sistema dizayn intervyu savollarini hal qilishga yaxshi tayyorlangan bo'lasiz.

Biz a'zolar uchun maxsus Discord guruhini yaratdik. U quyidagi mavzular bo'yicha jamoaviy muhokamalar uchun mo'ljallangan:

- Tizim dizaynining asoslari. - Dizayn diagrammalarini namoyish etish va fikr olish. - Mock interview do'stlarini topish. - Jamoа a'zolari bilan umumiy suhbat.

Bizga qo'shiling va bugun jamoaga o'zingizni taqdim eting!

Millionlab foydalanuvchini qo'llab-quvvatlaydigan tizimni loyihalash murakkab jarayon bo'lib, bu doimiy takomillashtirish va cheksiz yaxshilashni talab etadigan yo'ldir. Ushbu bobda biz bitta foydalanuvchini qo'llab-quvvatlaydigan tizim quramiz va uni asta-sekin millionlab foydalanuvchiga xizmat ko'rsatadigan darajaga yetkazamiz. Ushbu bobni o'qib bo'lgach, siz tizim dizayni bo'yicha suhbat savollarini yechishga yordam beradigan bir qancha usullarni o'zlashtirgan bo'lasiz.

Yagona server sozlamasi

Ming chaqirimlik yo'l bitta qadamdan boshlanadi va murakkab tizim qurish ham bundan farq qilmaydi. Oddiydan boshlash uchun, hamma narsa yagona serverda ishlaydi. 1-rasmda yagona server sozlamasining ko'rinishi ko'rsatilgan: web-ilova, ma'lumotlar bazasi, kesh va boshqa komponentlar bitta serverda joylashgan.

So'rov oqimi va trafik manbai

Ushbu sozlamani tushunish uchun so'rov oqimi va trafik manbaini o'rganish foydali bo'ladi. Avval so'rov oqimiga qaraylik (2-rasm).

1. Foydalanuvchilar veb-saytlarga domen nomlari orqali kirishadi, masalan api.mysite.com. Odatda, Domen Nomlari Tizimi (DNS) uchinchi tomon provayderlari tomonidan to'lov asosida taqdim etiladigan xizmat bo'lib, bizning serverlarimizda joylashmagan.

2. Brauzer yoki mobil ilovaga Internet Protokoli (IP) manzil qaytariladi. Misolda, 15.125.23.214 IP manzil qaytariladi.

3. IP manzil olingandan so'ng, Gipermatn Uzatish Protokoli (HTTP) [1] so'rovlari to'g'ridan-to'g'ri veb-serveringizga yuboriladi.

4. Veb-server ko'rsatish uchun HTML sahifalar yoki JSON javobini qaytaradi.

Keyingi qadamda trafik manbaini ko'rib chiqaylik. Veb-serveringizga keladigan trafik ikki manbadan keladi: veb-ilova va mobil ilova.

**Veb-ilova:** u biznes mantiqini, saqlashni va boshqalarni boshqarish uchun server tomonidagi tillardan (Java, Python va h.k.) va taqdimot uchun mijoz tomonidagi tillardan (HTML va JavaScript) foydalanadi.

**Mobil ilova:** HTTP protokoli mobil ilova va veb-server o'rtasidagi aloqa protokoli hisoblanadi. JavaScript Object Notation (JSON) soddaligi tufayli ma'lumotlarni uzatishda keng qo'llaniladigan API javob formatidir. Quyida JSON formatidagi API javobining namunasi ko'rsatilgan:

``` GET /users/12 – id = 12 bo'lgan foydalanuvchi ob'ektini olish

{ "id": 12, "firstName": "John", "lastName": "Smith", "address": { "streetAddress": "21 2nd Street", "city": "New York", "state": "NY", "postalCode": 10021 }, "phoneNumbers": [ "212 555-1234", "646 555-4567" ] } ```

Ma'lumotlar bazasi

Foydalanuvchilar soni o'sishi bilan bitta server yetarli bo'lmay qoladi va bizga bir nechta server kerak bo'ladi: biri veb/mobil trafik uchun, ikkinchisi ma'lumotlar bazasi uchun (3-rasm). Veb/mobil trafik (veb qatlami) va ma'lumotlar bazasi (ma'lumotlar qatlami) serverlarini ajratish ularni mustaqil ravishda kengaytirish imkonini beradi.

Qaysi ma'lumotlar bazasini tanlash kerak?

Siz an'anaviy relyatsion ma'lumotlar bazasi yoki relyatsion bo'lmagan ma'lumotlar bazasi o'rtasida tanlashingiz mumkin. Ularning farqlarini ko'rib chiqaylik.

**Relyatsion ma'lumotlar bazalari** relyatsion ma'lumotlar bazasini boshqarish tizimi (RDBMS) yoki SQL ma'lumotlar bazasi deb ham ataladi. Eng mashhurlari MySQL, Oracle database, PostgreSQL va boshqalar. Relyatsion ma'lumotlar bazalari ma'lumotlarni jadval va qatorlar ko'rinishida ifodalaydi va saqlaydi. Siz SQL yordamida turli ma'lumotlar bazasi jadvallarida birlashtirish (join) amallarini bajarishingiz mumkin.

**Relyatsion bo'lmagan ma'lumotlar bazalari** NoSQL ma'lumotlar bazalari deb ham ataladi. Mashhurlari: CouchDB, Neo4j, Cassandra, HBase, Amazon DynamoDB va boshqalar [2]. Bu ma'lumotlar bazalari to'rt turkumga bo'linadi: kalit-qiymat xotiralari, graf xotiralari, ustun xotiralari va hujjat xotiralari. Relyatsion bo'lmagan ma'lumotlar bazalarida birlashtirish amallari odatda qo'llab-quvvatlanmaydi.

Ko'pchilik dasturchilar uchun relyatsion ma'lumotlar bazalari eng yaxshi tanlov hisoblanadi, chunki ular 40 yildan ko'proq vaqtdan beri mavjud va tarixan yaxshi ishlagan. Biroq, agar relyatsion ma'lumotlar bazalari sizning aniq foydalanish holatlaringizga mos kelmasa, relyatsion ma'lumotlar bazalaridan tashqariga chiqishni o'rganish muhim. Agar quyidagilar zarur bo'lsa, NoSQL ma'lumotlar bazalari to'g'ri tanlov bo'lishi mumkin:

- Ilovangiz juda past kechikishni talab qilsa. - Sizning ma'lumotlaringiz tuzilmagan bo'lsa yoki relyatsion ma'lumotlaringiz bo'lmasa. - Siz faqat ma'lumotlarni seriyalash va deseriyalash kerak bo'lsa (JSON, XML, YAML va h.k.). - Juda katta hajmdagi ma'lumotlarni saqlash kerak bo'lsa.

Vertikal kengaytirish vs gorizontal kengaytirish

Vertikal kengaytirish, "yuqoriga kengaytirish" deb ham ataladi, bu serverlaringizga ko'proq quvvat (CPU, RAM va h.k.) qo'shish jarayonini anglatadi. Gorizontal kengaytirish, "tashqariga kengaytirish" deb ham ataladi, resurslariingiz havzasiga ko'proq serverlar qo'shish orqali kengaytirish imkonini beradi.

Trafik past bo'lganda, vertikal kengaytirish ajoyib variant bo'lib, uning soddaligi asosiy afzalligidir. Afsuski, u jiddiy cheklovlarga ega:

- Vertikal kengaytirishning qat'iy chegarasi bor. Yagona serverga cheksiz CPU va xotira qo'shib bo'lmaydi. - Vertikal kengaytirishda xato bardoshlilik va ortiqchalik mavjud emas. Agar bitta server ishdan chiqsa, veb-sayt/ilova ham butunlay ishdan chiqadi.

Vertikal kengaytirishning cheklovlari tufayli gorizontal kengaytirish katta miqyosli ilovalar uchun afzalroqdir.

Oldingi dizaynda foydalanuvchilar veb-serverga to'g'ridan-to'g'ri ulanishadi. Veb-server oflayn bo'lsa, foydalanuvchilar veb-saytga kira olmaydi. Boshqa stsenariida, agar ko'p foydalanuvchilar bir vaqtning o'zida veb-serverga kirsa va u veb-serverning yuklanish chegarasiga yetsa, foydalanuvchilar odatda sekinroq javob oladi yoki serverga ulana olmaydi. Load balancer bu muammolarni hal qilishning eng yaxshi usuli hisoblanadi.

Load balancer

Load balancer yuklangan to'plamda belgilangan veb-serverlar o'rtasida kiruvchi trafikni bir tekis taqsimlaydi. 4-rasmda load balancer qanday ishlashi ko'rsatilgan.

4-rasmda ko'rsatilganidek, foydalanuvchilar to'g'ridan-to'g'ri load balancerning umumiy IP manziliga ulanishadi. Bunday sozlama bilan veb-serverlar mijozlar tomonidan bevosita kirish mumkin bo'lmagan holga keladi. Xavfsizlikni yaxshilash uchun serverlar o'rtasidagi aloqada shaxsiy IP manzillardan foydalaniladi. Shaxsiy IP manzil faqat bir xil tarmoqdagi serverlar o'rtasida kirish mumkin bo'lgan IP manzil; lekin u internetda kirish mumkin emas. Load balancer veb-serverlar bilan shaxsiy IP manzillar orqali muloqot qiladi.

4-rasmda load balancer va ikkinchi veb-server qo'shilgandan so'ng, biz muvaffaqiyatli tarzda xato bardoshlilik muammosini hal qildik va veb-qatlamning mavjudligini yaxshiladik. Tafsilotlar quyida tushuntirilgan:

- Agar 1-server oflayn bo'lsa, barcha trafik 2-serverga yo'naltiriladi. Bu veb-saytning oflayn bo'lishining oldini oladi. Biz shuningdek yukni muvozanatlash uchun server havzasiga yangi sog'lom veb-server qo'shamiz. - Agar veb-sayt trafigi tezda o'ssa va ikki server trafikni uda qila olmasa, load balancer bu muammoni munosib tarzda hal qila oladi. Faqat veb-server havzasiga ko'proq serverlar qo'shishingiz kerak va load balancer avtomatik ravishda ularga so'rovlar yuborishni boshlaydi.

Endi veb-qatlam yaxshi ko'rinadi, ma'lumotlar qatlamichi? Joriy dizaynda bitta ma'lumotlar bazasi bor, shuning uchun u xato bardoshlilik va ortiqchalikni qo'llab-quvvatlamaydi. Ma'lumotlar bazasini replikatsiya qilish bu muammolarni hal qilishning umumiy usuli hisoblanadi.

Ma'lumotlar bazasini replikatsiya qilish

Vikipediyadan iqtibos: "Ma'lumotlar bazasini replikatsiya qilish ko'plab ma'lumotlar bazasini boshqarish tizimlarida qo'llanilishi mumkin, odatda asl nusxa (master) va nusxalar (slave) o'rtasida master/slave munosabati bilan" [3].

Master ma'lumotlar bazasi odatda faqat yozish amallarini qo'llab-quvvatlaydi. Slave ma'lumotlar bazasi master ma'lumotlar bazasidan ma'lumotlar nusxasini oladi va faqat o'qish amallarini qo'llab-quvvatlaydi. Kiritish, o'chirish yoki yangilash kabi barcha ma'lumotlarni o'zgartiruvchi buyruqlar master ma'lumotlar bazasiga yuborilishi kerak. Ko'pchilik ilovalar yozishga nisbatan o'qishning ancha yuqori nisbatini talab qiladi; shuning uchun tizimdagi slave ma'lumotlar bazalari soni odatda master ma'lumotlar bazalari sonidan ko'p bo'ladi. 5-rasmda bir nechta slave ma'lumotlar bazasiga ega master ma'lumotlar bazasi ko'rsatilgan.

**Ma'lumotlar bazasini replikatsiya qilishning afzalliklari:**

- **Yaxshilangan ishlash:** Master-slave modelida barcha yozish va yangilash amallari master tugunlarida amalga oshiriladi; o'qish amallari esa slave tugunlar bo'ylab taqsimlanadi. Bu model so'rovlarning ko'proqini parallel ravishda qayta ishlash imkonini berganligi uchun ishlashni yaxshilaydi. - **Ishonchlilik:** Agar ma'lumotlar bazasi serverlaringizdan biri tayfun yoki zilzila kabi tabiiy ofat natijasida vayron bo'lsa, ma'lumotlar saqlanib qoladi. Ma'lumotlar bir nechta joylarda replikatsiya qilinganligi sababli ma'lumotlarni yo'qotish haqida tashvishlanishingiz shart emas. - **Yuqori mavjudlik:** Ma'lumotlarni turli joylarda replikatsiya qilish orqali, ma'lumotlar bazasi oflayn bo'lsa ham veb-saytingiz ishlashda davom etadi, chunki boshqa ma'lumotlar bazasi serverida saqlangan ma'lumotlarga kirishingiz mumkin.

Oldingi bo'limda biz load balancer tizim mavjudligini yaxshilashga qanday yordam berishi haqida muhokama qildik. Bu yerda ham xuddi shu savolni beramiz: agar ma'lumotlar bazalaridan biri oflayn bo'lsa nima bo'ladi?

- Agar faqat bitta slave ma'lumotlar bazasi mavjud bo'lsa va u oflayn bo'lsa, o'qish amallari vaqtincha master ma'lumotlar bazasiga yo'naltiriladi. Muammo topilgandan so'ng, yangi slave ma'lumotlar bazasi eskisini almashtiradi. Agar bir nechta slave ma'lumotlar bazalari mavjud bo'lsa, o'qish amallari boshqa sog'lom slave ma'lumotlar bazalariga yo'naltiriladi. Yangi ma'lumotlar bazasi serveri eskisini almashtiradi. - Agar master ma'lumotlar bazasi oflayn bo'lsa, slave ma'lumotlar bazasi yangi master sifatida ko'tariladi. Barcha ma'lumotlar bazasi amallari vaqtincha yangi master ma'lumotlar bazasida bajariladi. Ma'lumotlarni replikatsiya qilish uchun yangi slave ma'lumotlar bazasi darhol eskisini almashtiradi. Ishlab chiqarish tizimlarida yangi masterni ko'tarish murakkabroq, chunki slave ma'lumotlar bazasidagi ma'lumotlar dolzarb bo'lmasligi mumkin. Etishmayotgan ma'lumotlar ma'lumotlarni tiklash skriptlarini ishga tushirish orqali yangilanishi kerak. Ba'zi boshqa replikatsiya usullari, masalan, multi-masters va circular replication yordam berishi mumkin bo'lsa-da, bu sozlamalar murakkabroq va ularning muhokamasi ushbu kursning doirasidan tashqarida. Qiziquvchi o'quvchilar ko'rsatilgan manba materiallarga murojaat qilishlari mumkin [4] [5].

6-rasmda load balancer va ma'lumotlar bazasini replikatsiya qilish qo'shilgandan keyingi tizim dizayni ko'rsatilgan.

Dizaynni ko'rib chiqaylik: - Foydalanuvchi DNS dan load balancer IP manzilini oladi. - Foydalanuvchi ushbu IP manzil orqali load balancerga ulanadi. - HTTP so'rovi 1-server yoki 2-serverga yo'naltiriladi. - Veb-server slave ma'lumotlar bazasidan foydalanuvchi ma'lumotlarini o'qiydi. - Veb-server ma'lumotlarni o'zgartiruvchi barcha amallarni master ma'lumotlar bazasiga yo'naltiradi. Bu yozish, yangilash va o'chirish amallarini o'z ichiga oladi.

Kesh

Kesh - bu xotirada qimmat javoblarning natijasi yoki tez-tez kiriladigan ma'lumotlarni saqlaydigan vaqtinchalik saqlash joyi bo'lib, keyingi so'rovlarga tezroq xizmat ko'rsatishga imkon beradi. 6-rasmda ko'rsatilganidek, har safar yangi veb-sahifa yuklanganida, ma'lumotlarni olish uchun bir yoki bir nechta ma'lumotlar bazasi chaqiruvlari amalga oshiriladi. Ilova ishlashi ma'lumotlar bazasini takroran chaqirish bilan sezilarli darajada ta'sirlanadi. Kesh bu muammoni yumshatishi mumkin.

Kesh qatlami

Kesh qatlami - ma'lumotlar bazasiga qaraganda ancha tezroq bo'lgan vaqtinchalik ma'lumotlar xotirasi qatlamidir. Alohida kesh qatlamiga ega bo'lishning afzalliklari: tizim ishlashini yaxshilash, ma'lumotlar bazasi yukini kamaytirish imkoniyati va kesh qatlamini mustaqil ravishda kengaytirish imkoniyati. 7-rasmda kesh serverining mumkin bo'lgan sozlamasi ko'rsatilgan.

So'rov qabul qilingandan so'ng, veb-server avval keshda mavjud javob borligini tekshiradi. Agar mavjud bo'lsa, ma'lumotlarni mijozga qaytaradi. Agar yo'q bo'lsa, u ma'lumotlar bazasini so'raydi, javobni keshda saqlaydi va uni mijozga yuboradi. Ushbu keshlash strategiyasi read-through cache deb ataladi. Ma'lumotlar turi, hajmi va kirish naqshlariga qarab boshqa keshlash strategiyalari ham mavjud. Oldingi tadqiqot turli keshlash strategiyalarining qanday ishlashini tushuntiradi [6].

Kesh serverlari bilan ishlash oddiy, chunki ko'pchilik kesh serverlari umumiy dasturlash tillari uchun API larni taqdim etadi. Quyidagi kod parchasi odatiy Memcached API larini ko'rsatadi:

``` SECONDS = 1 cache.set('myKey', 'hi there', 3600 * SECONDS) cache.get('myKey') ```

Keshdan foydalanishda e'tiborga olish kerak bo'lgan jihatlar

Kesh tizimidan foydalanishda e'tiborga olish kerak bo'lgan bir necha jihatlar:

- **Keshdan qachon foydalanishni aniqlash.** Ma'lumotlar tez-tez o'qilganda, lekin kamdan-kam o'zgartirilganda keshdan foydalanishni ko'rib chiqing. Keshlangan ma'lumotlar uchuvchi xotirada saqlanishi sababli, kesh server ma'lumotlarni doimiy saqlash uchun ideal emas. Masalan, agar kesh server qayta ishga tushirilsa, xotiradagi barcha ma'lumotlar yo'qoladi. Shuning uchun muhim ma'lumotlar doimiy ma'lumot xotiralarida saqlanishi kerak.

- **Muddati tugash siyosati.** Muddati tugash siyosatini amalga oshirish yaxshi amaliyotdir. Keshlangan ma'lumotlarning muddati tugagandan so'ng, u keshdan o'chiriladi. Muddati tugash siyosati bo'lmasa, keshlangan ma'lumotlar doimiy ravishda xotirada saqlanadi. Muddati tugash sanasini juda qisqa qilmaslik tavsiya etiladi, chunki bu tizimni ma'lumotlar bazasidan ma'lumotlarni juda tez-tez qayta yuklashiga olib keladi. Shu bilan birga, muddati tugash sanasini juda uzoq qilmaslik ham tavsiya etiladi, chunki ma'lumotlar eskirib qolishi mumkin.

- **Izchillik:** Bu ma'lumot xotirasi va keshni sinxronlashtirishni o'z ichiga oladi. Ma'lumot xotirasi va keshdagi ma'lumotlarni o'zgartiruvchi amallar bitta tranzaksiyada bo'lmaganligi sababli nomuvofiqlik yuzaga kelishi mumkin. Bir nechta mintaqalarda kengaytirishda ma'lumot xotirasi va kesh o'rtasida izchillikni saqlash murakkab. Batafsil ma'lumot uchun Facebook tomonidan nashr etilgan "Scaling Memcache at Facebook" nomli maqolaga murojaat qiling [7].

- **Muvaffaqiyatsizliklarni yumshatish:** Yagona kesh server potentsial yagona nosozlik nuqtasini (SPOF) ifodalaydi, Vikipediyada quyidagicha ta'riflanadi: "Yagona nosozlik nuqtasi (SPOF) — tizimning bir qismi bo'lib, agar u nosoz bo'lsa, butun tizimni to'xtatadi" [8]. Natijada, SPOF dan qochish uchun turli ma'lumotlar markazlarida bir nechta kesh serverlari tavsiya etiladi. Yana bir tavsiya etiladigan yondashuv - talab qilinadigan xotirani ma'lum foizlarga oshirib ta'minlashdir. Bu xotiradan foydalanish ortganda bufer vazifasini bajaradi.

- **Keshdan chiqarish siyosati:** Kesh to'lganda, keshdagi elementlarga yangi elementlar qo'shish so'rovlari mavjud elementlarning o'chirilishiga olib kelishi mumkin. Bu keshdan chiqarish deb ataladi. Eng kam so'nggi ishlatilgan (LRU) eng mashhur keshdan chiqarish siyosati hisoblanadi. Turli foydalanish holatlarini qondirish uchun Eng Kam Tez-Tez Ishlatilgan (LFU) yoki Birinchi Kirgan Birinchi Chiqadi (FIFO) kabi boshqa chiqarish siyosatlarini qabul qilish mumkin.

Kontent yetkazib berish tarmog'i (CDN)

CDN - statik kontentni yetkazib berish uchun ishlatiladigan geografik jihatdan tarqalgan serverlar tarmog'i. CDN serverlari rasmlar, videolar, CSS, JavaScript fayllari va boshqalar kabi statik kontentni keshlaydi.

Dinamik kontentni keshlash nisbatan yangi tushuncha bo'lib, ushbu kursning doirasidan tashqarida. U so'rov yo'li, so'rov satrlari, cookie-fayllar va so'rov sarlavhalariga asoslangan HTML sahifalarni keshlashni ta'minlaydi. Bu haqida ko'proq ma'lumot uchun manba materialidagi [9] maqolaga murojaat qiling. Ushbu kurs statik kontentni keshlash uchun CDN dan qanday foydalanishga qaratilgan.

CDN yuqori darajada qanday ishlashini ko'rib chiqaylik: foydalanuvchi veb-saytga tashrif buyurganida, foydalanuvchiga eng yaqin CDN server statik kontentni yetkazib beradi. Intuitiv ravishda, foydalanuvchilar CDN serverlaridan qancha uzoqda bo'lsa, veb-sayt shuncha sekin yuklanadi. Masalan, agar CDN serverlari San-Fransiskoda joylashgan bo'lsa, Los-Anjelesdagi foydalanuvchilar Evropadagi foydalanuvchilarga qaraganda kontentni tezroq oladi. 9-rasm CDN yuklash vaqtini qanday yaxshilashini ko'rsatadigan ajoyib misoldir.

10-rasm CDN ish oqimini namoyish etadi:

1. A foydalanuvchi rasm URL-dan foydalanib image.png olishga harakat qiladi. URL ning domeni CDN provayderidan berilgan. Quyidagi ikki rasm URL-i Amazon va Akamai CDN larida rasm URL-lari qanday ko'rinishini ko'rsatuvchi namunalardir: - `https://mysite.cloudfront.net/logo.jpg` - `https://mysite.akamai.com/image-manager/img/logo.jpg`

2. Agar CDN serverida keshda image.png bo'lmasa, CDN serveri faylni manba serverdan so'raydi, bu veb-server yoki Amazon S3 kabi onlayn xotira bo'lishi mumkin.

3. Manba server CDN serveriga image.png ni qaytaradi, bu ixtiyoriy HTTP sarlavhasi Yashash Vaqtini (TTL) o'z ichiga oladi, bu rasm qancha vaqt keshlanishini tavsiflaydi.

4. CDN rasmni keshlaydi va uni A foydalanuvchiga qaytaradi. Rasm TTL muddati tugamaguncha CDN da keshlanib qoladi.

5. B foydalanuvchi xuddi shu rasmni olish uchun so'rov yuboradi.

6. TTL muddati tugamagan bo'lsa, rasm keshdan qaytariladi.

CDN dan foydalanishda e'tiborga olish kerak bo'lgan jihatlar

- **Narx:** CDN lar uchinchi tomon provayderlari tomonidan boshqariladi va CDN dan kirish/chiqishda ma'lumotlarni uzatish uchun to'lov olasiz. Kamdan-kam ishlatiladigan resurslarni keshlash muhim foyda keltirmaydi, shuning uchun ularni CDN dan olib tashlashni ko'rib chiqishingiz kerak.

- **Kesh muddatini to'g'ri o'rnatish:** Vaqt sezgir kontent uchun kesh muddatini o'rnatish muhim. Kesh muddati na juda uzun, na juda qisqa bo'lishi kerak. Agar juda uzun bo'lsa, kontent yangi bo'lmasligi mumkin. Agar juda qisqa bo'lsa, bu manba serverlardan CDN ga kontentni qayta-qayta yuklashga olib kelishi mumkin.

- **CDN zahirasi:** Veb-sayt/ilovangiz CDN nosozligiga qanday moslashishini ko'rib chiqishingiz kerak. Agar vaqtinchalik CDN ishlamay qolsa, mijozlar muammoni aniqlashi va manba serverdan resurslarni so'rashi kerak.

- **Fayllarni bekor qilish:** Siz quyidagi amallardan birini bajarish orqali muddati tugashidan oldin CDN dan faylni olib tashlashingiz mumkin: - CDN sotuvchilari tomonidan taqdim etilgan API-lardan foydalanib CDN ob'ektini bekor qilish. - Ob'ektning boshqa versiyasiga xizmat ko'rsatish uchun ob'ekt versiyalashtirish. Ob'ektni versiyalash uchun URL-ga versiya raqami kabi parametr qo'shishingiz mumkin. Masalan, so'rov satriga 2-versiya raqami qo'shilgan: `image.png?v=2`.

11-rasm CDN va kesh qo'shilgandan keyingi dizaynni ko'rsatadi: 1. Statik resurslar (JS, CSS, rasmlar va h.k.) endi veb-serverlar tomonidan xizmat ko'rsatilmaydi. Ular yaxshilangan ishlash uchun CDN dan olinadi. 2. Ma'lumotlarni keshlash orqali ma'lumotlar bazasining yuki yengillashtirdi.

Holatsiz veb qatlami

Endi veb qatlamni gorizontal ravishda kengaytirishni ko'rib chiqish vaqti keldi. Buning uchun biz holatni (masalan, foydalanuvchi sessiya ma'lumotlari) veb qatlamidan chiqarishimiz kerak. Yaxshi amaliyot - sessiya ma'lumotlarini relyatsion ma'lumotlar bazasi yoki NoSQL kabi doimiy xotirada saqlashdir. Klasterdagi har bir veb-server ma'lumotlar bazasidan holat ma'lumotlariga kira oladi. Bu holatsiz veb qatlami deb ataladi.

Holatli arxitektura

Holatli server va holatsiz serverning ba'zi asosiy farqlari mavjud. Holatli server bir so'rovdan keyingisiga mijoz ma'lumotlarini (holatni) eslab qoladi. Holatsiz server holat ma'lumotlarini saqlamaydi.

12-rasm holatli arxitektura misolini ko'rsatadi.

12-rasmda A foydalanuvchining sessiya ma'lumotlari va profil rasmi 1-Serverda saqlanadi. A foydalanuvchini autentifikatsiya qilish uchun HTTP so'rovlari 1-Serverga yo'naltirilishi kerak. Agar so'rov 2-Server kabi boshqa serverlarga yuborilsa, autentifikatsiya muvaffaqiyatsiz bo'ladi, chunki 2-Server A foydalanuvchining sessiya ma'lumotlarini o'z ichiga olmaydi. Xuddi shunday, B foydalanuvchidan barcha HTTP so'rovlari 2-Serverga yo'naltirilishi kerak; C foydalanuvchidan barcha so'rovlar 3-Serverga yuborilishi kerak.

Muammo shundaki, bir xil mijozdan har bir so'rov bir xil serverga yo'naltirilishi kerak. Bu ko'pchilik load balancerlarda sticky sessions orqali amalga oshirilishi mumkin [10]; biroq bu qo'shimcha xarajat keltirib chiqaradi. Bu yondashuv bilan serverlarni qo'shish yoki olib tashlash ancha qiyin. Server nosozliklarini ham hal qilish qiyin.

Holatsiz arxitektura

13-rasm holatsiz arxitekturani ko'rsatadi.

Ushbu holatsiz arxitekturada foydalanuvchilardan HTTP so'rovlari umumiy ma'lumot xotirасidan holat ma'lumotlarini oladigan ixtiyoriy veb-serverlarga yuborilishi mumkin. Holat ma'lumotlari umumiy ma'lumot xotirasida saqlanadi va veb-serverlardan tashqarida ushlab turiladi. Holatsiz tizim soddaroq, mustahkamroq va kengaytiriladigan.

14-rasm holatsiz veb qatlam bilan yangilangan dizaynni ko'rsatadi.

14-rasmda biz sessiya ma'lumotlarini veb qatlamdan chiqaramiz va ularni doimiy ma'lumot xotirasida saqlaymiz. Umumiy ma'lumot xotirasi relyatsion ma'lumotlar bazasi, Memcached/Redis, NoSQL va boshqalar bo'lishi mumkin. NoSQL ma'lumot xotirasi kengaytirish oson bo'lganligi uchun tanlanadi. Avtomatik kengaytirish - trafik yukiga qarab veb-serverlarni avtomatik ravishda qo'shish yoki olib tashlashni anglatadi. Holat ma'lumotlari veb-serverlardan olib chiqilgandan so'ng, trafik yukiga qarab serverlarni qo'shish yoki olib tashlash orqali veb-qatlamni avtomatik kengaytirish osonlikcha amalga oshiriladi.

Veb-saytingiz tez o'sadi va xalqaro miqyosda ko'p sonli foydalanuvchilarni jalb qiladi. Mavjudlikni yaxshilash va keng geografik hududlarda yaxshilangan foydalanuvchi tajribasini ta'minlash uchun bir nechta ma'lumotlar markazlarini qo'llab-quvvatlash muhim.

Ma'lumotlar markazlari

15-rasm ikki ma'lumotlar markazi bo'lgan sozlama misolini ko'rsatadi. Odatdagi ishlashda foydalanuvchilar geoDNS orqali, geo-routing sifatida ham ma'lum, eng yaqin ma'lumotlar markaziga yo'naltiriladi, US-East da x% va US-West da (100 – x)% trafik bo'linishi bilan. geoDNS - foydalanuvchi joylashuviga qarab domen nomlarini IP manzillarga hal qilish imkonini beruvchi DNS xizmatidir.

Istalgan sezilarli ma'lumotlar markazi ishlamay qolishi hodisasida, biz barcha trafikni sog'lom ma'lumotlar markaziga yo'naltiramiz. 16-rasmda 2-ma'lumotlar markazi (US-West) oflayn va trafikning 100% si 1-ma'lumotlar markaziga (US-East) yo'naltirilgan.

Ko'p ma'lumotlar markazli sozlamaga erishish uchun bir nechta texnik muammolarni hal qilish kerak:

- **Trafikni yo'naltirish:** Trafikni to'g'ri ma'lumotlar markaziga yo'naltirish uchun samarali vositalar kerak. GeoDNS foydalanuvchi joylashuviga qarab trafikni eng yaqin ma'lumotlar markaziga yo'naltirish uchun ishlatilishi mumkin.

- **Ma'lumotlarni sinxronlashtirish:** Turli mintaqalardagi foydalanuvchilar turli lokal ma'lumotlar bazalari yoki keshlardan foydalanishi mumkin. Zaxira almashish holatlarida trafik ma'lumotlar mavjud bo'lmagan ma'lumotlar markaziga yo'naltirilishi mumkin. Keng tarqalgan strategiya - bir nechta ma'lumotlar markazlarida ma'lumotlarni replikatsiya qilish. Oldingi tadqiqot Netflix ning asinxron ko'p ma'lumotlar markazli replikatsiyani qanday amalga oshirishini ko'rsatadi [11].

- **Sinov va joylashtirish:** Ko'p ma'lumotlar markazli sozlamada veb-sayt/ilovangizni turli joylarda sinab ko'rish muhim. Avtomatlashtirilgan joylashtirish vositalari barcha ma'lumotlar markazlarida xizmatlarni izchil ushlab turish uchun muhim [11].

Tizimimizni yanada kengaytirish uchun tizimning turli komponentlarini ajratib, ularni mustaqil ravishda kengaytirish imkonini berish kerak. Xabar navbati - bu muammoni hal qilish uchun ko'plab haqiqiy tarqatilgan tizimlar tomonidan qo'llaniladigan asosiy strategiya.

Xabar navbati

Xabar navbati - xotirada saqlangan, asinxron aloqani qo'llab-quvvatlaydigan mustahkam komponent. U bufer vazifasini bajaradi va asinxron so'rovlarni taqsimlaydi. Xabar navbatining asosiy arxitekturasi oddiy. Produserlar/nashriyotchilar deb ataladigan kirish xizmatlari xabarlar yaratadi va ularni xabar navbatiga nashr qiladi. Konsyumerlar/obunachlar deb ataladigan boshqa xizmatlar yoki serverlar navbatga ulanadi va xabarlar bilan belgilangan amallarni bajaradi. Model 17-rasmda ko'rsatilgan.

Ajratish xabar navbatini kengaytiriladigan va ishonchli ilova qurish uchun afzal arxitektura qiladi. Xabar navbati bilan, konsyumer uni qayta ishlashga mavjud bo'lmaganida, produser navbatga xabar joylashtirishi mumkin. Konsyumer produser mavjud bo'lmaganida ham navbatdan xabarlarni o'qiy oladi.

Quyidagi foydalanish holatini ko'rib chiqing: ilovangiz foto moslashtirishni qo'llab-quvvatlaydi, shu jumladan kesish, o'tkirlashtirish, loyqalashtirish va boshqalar. Ushbu moslash vazifalari bajarilishi uchun vaqt talab etadi. 18-rasmda veb-serverlar foto qayta ishlash ishlarini xabar navbatiga nashr qiladi. Foto qayta ishlash ishchilari xabar navbatidan ishlarni olib, asinxron ravishda foto moslashtirish vazifalarini bajaradilar. Produser va konsyumer mustaqil ravishda kengaytirilishi mumkin. Navbat hajmi katta bo'lganda, qayta ishlash vaqtini qisqartirish uchun ko'proq ishchilar qo'shiladi. Biroq, agar navbat ko'pincha bo'sh bo'lsa, ishchilar soni kamaytirilishi mumkin.

Jurnal yuritish, metrikalar, avtomatlashtirish

Bir nechta serverlarda ishlaydigan kichik veb-sayt bilan ishlashda jurnal yuritish, metrikalar va avtomatlashtirilgan yordam yaxshi amaliyotlar, lekin zarurat emas. Biroq, veb-saytingiz katta biznesga xizmat ko'rsatish uchun o'sganligi sababli, bu vositalarga investitsiya qilish muhim.

- **Jurnal yuritish:** Xato jurnallarini monitoring qilish muhim, chunki u tizimda xatolar va muammolarni aniqlashga yordam beradi. Siz xato jurnallarini server darajasida monitoring qilishingiz yoki ularni oson qidirish va ko'rish uchun markazlashtirilgan xizmatda birlashtirish uchun vositalardan foydalanishingiz mumkin.

- **Metrikalar:** Turli metrikalarni to'plash biznes tushunchalarini olish va tizim holat statusini tushunishga yordam beradi. Quyidagi metrikalarning ba'zilari foydali: - Host darajasidagi metrikalar: CPU, xotira, disk I/O va h.k. - Yig'ilgan darajadagi metrikalar: masalan, butun ma'lumotlar bazasi qatlami, kesh qatlami va h.k. ishlashi. - Asosiy biznes metrikalar: kunlik faol foydalanuvchilar, saqlash, daromad va h.k.

- **Avtomatlashtirish:** Tizim katta va murakkab bo'lganda, unumdorlikni yaxshilash uchun avtomatlashtirish vositalarini yaratish yoki ulardan foydalanish kerak. Doimiy integratsiya yaxshi amaliyot bo'lib, unda har bir kod kiritilishi avtomatlashtirish orqali tekshiriladi, bu jamoalarga muammolarni erta aniqlash imkonini beradi. Bundan tashqari, qurilish, sinov, joylashtirish jarayonlarini avtomatlashtirish va boshqalar dasturchi unumdorligini sezilarli darajada yaxshilashi mumkin.

Xabar navbatlari va turli vositalar qo'shish

19-rasm yangilangan dizaynni ko'rsatadi. Joy cheklovlari sababli rasmda faqat bitta ma'lumotlar markazi ko'rsatilgan.

1. Dizayn xabar navbatini o'z ichiga oladi, bu tizimni yanada bo'shroq bog'langan va nosozliklarga chidamli qilishga yordam beradi. 2. Jurnal yuritish, monitoring, metrikalar va avtomatlashtirish vositalari kiritilgan.

Har kuni ma'lumotlar o'sib borishi bilan ma'lumotlar bazangiz ortiqcha yuklanadi. Ma'lumotlar qatlamini kengaytirish vaqti keldi.

Ma'lumotlar bazasini kengaytirish

Ma'lumotlar bazasini kengaytirishning ikki keng yondashuvi mavjud: vertikal kengaytirish va gorizontal kengaytirish.

Vertikal kengaytirish

Vertikal kengaytirish, yuqoriga kengaytirish sifatida ham ma'lum, mavjud mashinaga ko'proq quvvat (CPU, RAM, DISK va h.k.) qo'shish orqali kengaytirishdir. Kuchli ma'lumotlar bazasi serverlari mavjud. Amazon Relational Database Service (RDS) [12] ga ko'ra, siz 24 TB RAM li ma'lumotlar bazasi serverini olishingiz mumkin. Bunday kuchli ma'lumotlar bazasi serveri ko'p ma'lumotlarni saqlashi va boshqarishi mumkin. Masalan, 2013-yildagi stackoverflow.com da oyiga 10 milliondan ortiq noyob tashrif buyuruvchilari bor edi, lekin unda faqat 1 ta master ma'lumotlar bazasi bor edi [13]. Biroq, vertikal kengaytirish ba'zi jiddiy kamchiliklarga ega:

- Ma'lumotlar bazasi serveringizga ko'proq CPU, RAM va boshqalarni qo'shishingiz mumkin, lekin apparat chegaralari mavjud. Agar sizda katta foydalanuvchilar bazasi bo'lsa, yagona server yetarli emas. - Yagona nosozlik nuqtalarining yuqori xavfi. - Vertikal kengaytirishning umumiy narxi yuqori. Kuchli serverlar ancha qimmat.

Gorizontal kengaytirish

Gorizontal kengaytirish, sharding sifatida ham ma'lum, ko'proq serverlar qo'shish amaliyotidir. 20-rasm vertikal kengaytirishni gorizontal kengaytirish bilan solishtiradi.

Sharding katta ma'lumotlar bazalarini shardlar deb ataladigan kichikroq, osonroq boshqariladigan qismlarga bo'ladi. Har bir shard bir xil sxemani ulashadi, garchi har bir sharddagi haqiqiy ma'lumotlar shard uchun noyob bo'lsa ham.

21-rasm shardlangan ma'lumotlar bazalari misolini ko'rsatadi. Foydalanuvchi ma'lumotlari foydalanuvchi IDlariga asoslanib ma'lumotlar bazasi serveriga taqsimlanadi. Ma'lumotlarga kirishda, tegishli shardni topish uchun xesh funksiyasi ishlatiladi. Bizning misolimizda user_id % 4 xesh funksiyasi sifatida ishlatiladi. Agar natija 0 ga teng bo'lsa, ma'lumotlarni saqlash va olish uchun 0-shard ishlatiladi. Agar natija 1 ga teng bo'lsa, 1-shard ishlatiladi. Bir xil mantiq boshqa shardlarga ham qo'llaniladi.

22-rasm shardlangan ma'lumotlar bazalaridagi foydalanuvchi jadvalini ko'rsatadi.

Sharding strategiyasini amalga oshirishda ko'rib chiqiladigan eng muhim omil - sharding kalitini tanlash. Sharding kaliti (partitsiya kaliti sifatida ham ma'lum) ma'lumotlarning qanday taqsimlanishini belgilaydigan bir yoki bir nechta ustunlardan iborat. 22-rasmda ko'rsatilganidek, "user_id" sharding kalitidir. Sharding kaliti ma'lumotlar bazasi so'rovlarini to'g'ri ma'lumotlar bazasiga yo'naltirish orqali ma'lumotlarni samarali olish va o'zgartirish imkonini beradi. Sharding kalitini tanlashda eng muhim mezonlardan biri ma'lumotlarni bir tekis taqsimlashi mumkin bo'lgan kalitni tanlashdir.

Sharding ma'lumotlar bazasini kengaytirish uchun ajoyib usul, lekin u mukammal yechim emas. U tizimga murakkabliklar va yangi muammolarni kiritadi:

- **Ma'lumotlarni qayta shardlash:** Ma'lumotlarni qayta shardlash kerak bo'ladi, qachonki 1) tez o'sish tufayli yagona shard ko'proq ma'lumot uda qila olmasa. 2) Notekis ma'lumot taqsimoti tufayli ba'zi shardlar boshqalarga qaraganda tezroq shard tugashini boshdan kechirishi mumkin. Shard tugashi yuz berganda, sharding funksiyasini yangilash va ma'lumotlarni ko'chirish talab etiladi. Izchil xeshlash bu muammoni hal qilish uchun keng qo'llaniladigan usuldir.

- **Mashhurlik muammosi:** Bu hotspot kaliti muammosi deb ham ataladi. Ma'lum bir shardga haddan tashqari kirish server ortiqcha yuklanishiga olib kelishi mumkin. Katy Perry, Justin Bieber va Lady Gaga uchun ma'lumotlarning hammasi bir xil shardda tugashini tasavvur qiling. Ijtimoiy ilovalar uchun, ushbu shard o'qish amallari bilan to'lib toshadi. Bu muammoni hal qilish uchun har bir mashhur shaxs uchun shard ajratishimiz kerak bo'lishi mumkin. Har bir shard hatto yanada bo'linishni talab qilishi mumkin.

- **Birlashtirish va de-normalizatsiya:** Ma'lumotlar bazasi bir nechta serverlar bo'ylab shardlangandan so'ng, ma'lumotlar bazasi shardlari bo'ylab birlashtirish amallarini bajarish qiyin. Keng tarqalgan yechim - so'rovlarni bitta jadvalda bajarish imkonini berish uchun ma'lumotlar bazasini de-normalizatsiya qilishdir.

23-rasmda biz tez ortib borayotgan ma'lumotlar trafikini qo'llab-quvvatlash uchun ma'lumotlar bazalarini shardlaymiz. Shu bilan birga, relyatsion bo'lmagan funksionalliklarning bir qismi ma'lumotlar bazasi yukini kamaytirish uchun NoSQL ma'lumot xotirasiga ko'chiriladi. Bu yerda NoSQL ning ko'plab foydalanish holatlarini qamrab oluvchi maqola mavjud [14].

Millionlab foydalanuvchi va undan ko'p

Tizimni kengaytirish iterativ jarayondir. Ushbu bobda o'rganganlarimizga iteratsiya qilish bizni uzoqqa olib borishi mumkin. Millionlab foydalanuvchidan tashqari kengaytirish uchun yanada nozik sozlash va yangi strategiyalar kerak. Masalan, tizimni optimallashtirish va yanada kichikroq xizmatlarga bo'lish kerak bo'lishi mumkin. Ushbu bobda o'rganilgan barcha usullar yangi muammolarni hal qilish uchun yaxshi asos yaratishi kerak. Ushbu bobni xulosalash uchun tizimimizni millionlab foydalanuvchini qo'llab-quvvatlash uchun qanday kengaytirganimiz haqida qisqacha ma'lumot beramiz:

- Veb qatlamni holatsiz saqlash - Har bir qatlamda ortiqchalik yaratish - Ma'lumotlarni imkon qadar keshlash - Bir nechta ma'lumotlar markazlarini qo'llab-quvvatlash - Statik resurslarni CDN da joylashtirish - Ma'lumotlar qatlamini sharding orqali kengaytirish - Qatlamlarni alohida xizmatlarga bo'lish - Tizimingizni monitoring qilish va avtomatlashtirish vositalaridan foydalanish

Bu yerga yetib kelganingiz uchun tabriklaymiz! Endi o'zingizni maqtashingiz mumkin. Zo'r ish!

Tizim dizayni suhbatida, ba'zan sizdan taxminiy hisob-kitob usuli yordamida tizim sig'imi yoki ishlash talablarini baholash so'raladi. Google ning katta muhandisi Jeff Dean ning ta'rifiga ko'ra, "taxminiy hisob-kitoblar — bu fikr tajribalari va umumiy ishlash ko'rsatkichlari kombinatsiyasidan foydalanib, qaysi dizaynlar talablaringizni qondirishi haqida yaxshi tasavvurga ega bo'lish uchun yaratiladigan baholashlardir" [1].

Taxminiy hisob-kitobni samarali amalga oshirish uchun kengaytiriluvchanlik asoslarini yaxshi tushunish kerak. Quyidagi tushunchalar yaxshi o'zlashtirish kerak: ikki darajasi [2], har bir dasturchi bilishi kerak bo'lgan kechikish raqamlari va mavjudlik raqamlari.

Ikki darajasi

Ma'lumotlar hajmi tarqatilgan tizimlar bilan ishlashda ulkan bo'lishi mumkin bo'lsa-da, hisob-kitob oxir-oqibat asosiy narsalarga keladi. To'g'ri hisob-kitoblar olish uchun ikki darajasi yordamida ma'lumot hajmi birligini bilish muhim. Bayt — 8 bitdan iborat ketma-ketlik. ASCII belgisi bir bayt xotira (8 bit) ishlatadi. Quyida ma'lumot hajmi birligini tushuntiruvchi jadval keltirilgan.

| Daraja | Taxminiy qiymat | To'liq nomi | Qisqa nomi | |--------|-----------------|-------------|------------| | 10 | 1 Ming | 1 Kilobayt | 1 KB | | 20 | 1 Million | 1 Megabayt | 1 MB | | 30 | 1 Milliard | 1 Gigabayt | 1 GB | | 40 | 1 Trillion | 1 Terabayt | 1 TB | | 50 | 1 Kvadrillion | 1 Petabayt | 1 PB |

**1-jadval: Ma'lumot hajmi birliklari (ikki darajalari)**

Har bir dasturchi bilishi kerak bo'lgan kechikish raqamlari

Google dan Dr. Dean 2010-yildagi odatiy kompyuter operatsiyalarining davomiyligini ochib berdi [1]. Ba'zi raqamlar kompyuterlar tezroq va qudratli bo'lgani sababli eskirgan. Biroq, bu raqamlar hali ham turli kompyuter operatsiyalarining tez va sekin ekanligini tushunishimizga yordam berishi mumkin.

| Amal nomi | Vaqt | |-----------|------| | L1 kesh murojaat | 0.5 ns | | Noto'g'ri sho'ba bashorati | 5 ns | | L2 kesh murojaat | 7 ns | | Mutex qulflash/qulfdan chiqarish | 100 ns | | Asosiy xotiraga murojaat | 100 ns | | 1K baytni Zippy bilan siqish | 10,000 ns = 10 µs | | 1 Gbps tarmoq orqali 2K bayt yuborish | 20,000 ns = 20 µs | | Xotiradan 1 MB ni ketma-ket o'qish | 250,000 ns = 250 µs | | Bir xil ma'lumotlar markazi ichida to'liq yo'l | 500,000 ns = 500 µs | | Disk izlash | 10,000,000 ns = 10 ms | | Tarmoqdan 1 MB ni ketma-ket o'qish | 10,000,000 ns = 10 ms | | Diskdan 1 MB ni ketma-ket o'qish | 30,000,000 ns = 30 ms | | CA→Niderlandiya→CA paketini yuborish | 150,000,000 ns = 150 ms |

**2-jadval: Har bir dasturchi bilishi kerak bo'lgan kechikish raqamlari**

> **Eslatmalar:** ns = nanosekund, µs = mikrosekund, ms = millisekund > 1 ns = 10⁻⁹ sekund · 1 µs = 10⁻⁶ sekund = 1,000 ns · 1 ms = 10⁻³ sekund = 1,000 µs = 1,000,000 ns

Google ning dasturiy ta'minot muhandisi Dr. Dean raqamlarini vizualizatsiya qilish uchun vosita yaratdi. Vosita vaqt omilini ham hisobga oladi. 1-rasm 2020-yil holatiga ko'ra vizuallashtirilgan kechikish raqamlarini ko'rsatadi (rasmlar manbasi: manba material [3]).

Kechikish xulosalari

1-rasmdagi raqamlarni tahlil qilib, quyidagi xulosalarga kelamiz:

- Xotira tez, lekin disk sekin. - Imkon bo'lsa, disk izlashdan qoching. - Oddiy siqish algoritmlari tez. - Imkon bo'lsa, internetga yuborishdan oldin ma'lumotlarni siqing. - Ma'lumotlar markazlari odatda turli mintaqalarda joylashgan va ular o'rtasida ma'lumot yuborish vaqt talab etadi.

Mavjudlik raqamlari

Yuqori mavjudlik — tizimning uzoq vaqt davomida uzluksiz ishlash qobiliyati. Yuqori mavjudlik foiz ko'rinishida o'lchanadi, 100% esa 0 to'xtash vaqtiga ega xizmatni anglatadi. Ko'pchilik xizmatlar 99% va 100% oralig'ida bo'ladi.

Xizmat darajasi shartnomasi (SLA) xizmat ko'rsatuvchilar uchun keng qo'llaniladigan atama. Bu siz (xizmat ko'rsatuvchi) va mijozingiz o'rtasidagi kelishuv bo'lib, ushbu kelishuv rasman sizning xizmatingiz qancha vaqt ishlashini belgilaydi. Bulut provayderlari Amazon [4], Google [5] va Microsoft [6] o'zlarining SLA larini 99.9% yoki undan yuqori darajada belgilaydi. Ishlamay qolish vaqti an'anaviy ravishda to'qqizlar bilan o'lchanadi. Qancha ko'p to'qqiz bo'lsa, shuncha yaxshi. 3-jadvalda ko'rsatilganidek, to'qqizlar soni kutilayotgan tizim to'xtash vaqtiga mos keladi.

| Mavjudlik % | Kunlik to'xtash vaqti | Haftalik to'xtash vaqti | Oylik to'xtash vaqti | Yillik to'xtash vaqti | |-------------|----------------------|------------------------|---------------------|----------------------| | 99% | 14.40 daqiqa | 1.68 soat | 7.31 soat | 3.65 kun | | 99.9% | 1.44 daqiqa | 10.08 daqiqa | 43.83 daqiqa | 8.77 soat | | 99.99% | 8.64 sekund | 1.01 daqiqa | 4.38 daqiqa | 52.60 daqiqa | | 99.999% | 864.00 millisekund | 6.05 sekund | 26.30 sekund | 5.26 daqiqa | | 99.9999% | 86.40 millisekund | 604.80 millisekund | 2.63 sekund | 31.56 sekund |

**3-jadval: Mavjudlik raqamlari — "to'qqizlar"**

Misol: Twitter QPS va saqlash talablarini baholash

Quyidagi raqamlar faqat ushbu mashq uchun ekanligini va Twitter ning haqiqiy raqamlari emasligini esda tuting.

**Taxminlar:** - 300 million oylik faol foydalanuvchilar. - Foydalanuvchilarning 50% Twitter dan kunlik foydalanadi. - Foydalanuvchilar o'rtacha kuniga 2 tweet joylashtiradi. - Tweetlarning 10% media o'z ichiga oladi. - Ma'lumotlar 5 yil saqlanadi.

**Baholashlar:**

Sekundiga so'rovlar (QPS) baholash: - Kunlik faol foydalanuvchilar (DAU) = 300 million × 50% = 150 million - Tweetlar QPS = 150 million × 2 tweet / 24 soat / 3600 sekund = ~3500 - Cho'qqi QPS = 2 × QPS = ~7000

Biz bu yerda faqat media xotirasini baholaymiz.

O'rtacha tweet hajmi: - tweet_id: 64 bayt - matn: 140 bayt - media: 1 MB

Media xotirasi: 150 million × 2 × 10% × 1 MB = **kuniga 30 TB**

5 yillik media xotirasi: 30 TB × 365 × 5 = **~55 PB**

Maslahatlar

Taxminiy hisob-kitob jarayon haqida. Muammoni hal qilish natijaga erishishdan muhimroq. Suhbatchilar muammoni hal qilish ko'nikmangizni sinab ko'rishi mumkin. Amal qilish uchun bir necha maslahat:

- **Yaxlitlash va taxmin qilish.** Suhbat davomida murakkab matematik amallari bajarish qiyin. Masalan, "99987 / 9.1" ning natijasi nima? Murakkab matematik masalalarni hal qilish uchun qimmatli vaqt sarflashga hojat yo'q. Aniqlik talab etilmaydi. Yaxlit sonlar va taxmindan o'z manfaatingiz uchun foydalaning. Bo'lish savoli quyidagicha soddalashtirilishi mumkin: "100,000 / 10".

- **Taxminlaringizni yozing.** Keyinchalik murojaat qilish uchun taxminlaringizni yozib olish yaxshi g'oya.

- **Birliklaringizni belgilang.** Agar "5" yozsangiz, bu 5 KB yoki 5 MB ni anglatadimi? Bu o'zingizni chalkashtirib qo'yishi mumkin. Birliklarni yozing, chunki "5 MB" noaniqlikni bartaraf etishga yordam beradi.

- **Ko'pincha so'raladigan taxminiy hisob-kitoblar:** QPS, cho'qqi QPS, xotira, kesh, serverlar soni va h.k. Suhbatga tayyorlanishda ushbu hisob-kitoblarni mashq qilishingiz mumkin. Mashq kamolotga yetkazadi.

Siz hohlagan kompaniyangizda coveted joyida suhbatga erishdingiz. Yollash koordinatori o'sha kungi jadvalini yubordi. Ro'yxatni ko'zdan kechirishda, tizim dizayni suhbati degan bo'limga ko'zingiz tushguncha o'zingizni yaxshi his qilasiz.

Tizim dizayni suhbatlari ko'pincha qo'rqinchli ko'rinadi. Bu "taniqli X mahsulotini loyihalash" kabi noaniq bo'lishi mumkin. Savollar noaniq va asossiz keng ko'rinadi. Charchashingiz tushuniladi. Axir, kimdir minglab emas, yuzlab muhandislar quradigan mashxur mahsulotni bir soat ichida loyihalashi mumkinmi?

Yaxshi xabar shundaki, hech kim bunday kutmaydi. Haqiqiy hayotdagi tizim dizayni nihoyatda murakkab. Masalan, Google qidirish aldamchi tarzda oddiy ko'rinadi; biroq shu oddiylikning ostidagi texnologiyalar miqdori haqiqatan ham hayratlanarli. Agar hech kim sizdan bir soat ichida haqiqiy hayotdagi tizimni loyihalashingizni kutmasa, tizim dizayni suhbatining qanday foydasi bor?

Tizim dizayni suhbati — ikki hamkasb noaniq muammo ustida hamkorlik qilib, maqsadlarini qondiruvchi yechim topayotgan haqiqiy hayotdagi muammo hal qilishni taqlid qiladi. Muammo ochiq, va mukammal javob yo'q. Yakuniy dizayn dizayn jarayoniga sarflagan ishingizga qaraganda kamroq muhim. Bu sizga dizayn ko'nikmangizni ko'rsatish, dizayn tanlovlaringizni himoya qilish va fikr-mulohazalarga konstruktiv tarzda javob berish imkonini beradi.

Suhbatchi ning asosiy maqsadi — qobiliyatingizni to'g'ri baholash. Samarali tizim dizayni suhbati odamning hamkorlik qilish, bosim ostida ishlash va noaniqlikni konstruktiv hal qilish qobiliyati haqida kuchli signallar beradi. Yaxshi savollar bera olish ham muhim ko'nikma bo'lib, ko'plab suhbatchilar aynan ushbu ko'nikmani qidiradi.

Yaxshi suhbatchi qizil bayroqlarni ham qidiradi. Haddan tashqari muhandislik — ko'plab muhandislarning haqiqiy kasalligidir, chunki ular dizayn sofligi haqida quvonib, ortib ketish xarajatlarini e'tiborsiz qoldiradilar. Ular ko'pincha haddan tashqari muhandislik qilingan tizimlarning ortib borayotgan xarajatlaridan bexabar bo'ladi va ko'p kompaniyalar bu bexabarlik uchun katta to'laydi. Boshqa qizil bayroqlarga tor fikrlilik, qaysarlik va h.k. kiradi.

Ushbu bobda biz bir nechta foydali maslahatlarni ko'rib chiqamiz va tizim dizayni suhbati muammolarini hal qilish uchun oddiy va samarali asos doirani taqdim etamiz.

Samarali tizim dizayni suhbati uchun 4 bosqichli jarayon

Har bir tizim dizayni suhbati boshqacha. Ajoyib tizim dizayni suhbati ochiq bo'lib, bir xil yechim mavjud emas. Biroq, har bir tizim dizayni suhbatida bosqichlar va umumiy qoplanadigan asoslar mavjud.

1-bosqich - Muammoni tushunish va dizayn doirasini aniqlash

Savol to'liq tushunilmasdan javob berishga shoshiladigan talaba Jimmiga o'xshash bo'lmang.

Tizim dizayni suhbatida tezda javob berish o'ylashmasdan qo'shimcha ball bermaydi. Talablarni chuqur tushunmasdan javob berish katta qizil bayroqdir, chunki suhbat bilimlarni tekshirish musobaqasi emas. To'g'ri javob yo'q.

Shuning uchun darhol yechimga o'tmang. Sekinlashing. Chuqur o'ylang va talablar hamda taxminlarni aniqlashtirish uchun savollar bering. Bu nihoyatda muhim.

Muhandis sifatida, biz qiyin muammolarni hal qilishni yaxshi ko'ramiz va to'g'ridan-to'g'ri yakuniy dizaynni yaratishga shoshilamiz; biroq bu yondashuv sizni noto'g'ri tizim loyihalashga olib borishi ehtimoli katta. Muhandis sifatida eng muhim ko'nikmalardan biri — to'g'ri savollar berish, to'g'ri taxminlar qilish va tizim qurish uchun zarur bo'lgan barcha ma'lumotlarni to'plashdir. Shuning uchun savollar berishdan qo'rqmang.

Savolga javob berganingizda, suhbatchi yo savolingizga to'g'ridan-to'g'ri javob beradi yoki taxminlaringizni belgilashingizni so'raydi. Agar ikkinchisi yuz bersa, taxminlaringizni doska yoki qog'ozga yozing. Keyinchalik ular kerak bo'lishi mumkin.

**Qanday savollar berish kerak?** Aniq talablarni tushunish uchun savollar bering. Boshlashga yordam beradigan savollar ro'yxati:

- Qanday o'ziga xos xususiyatlarni yaratamiz? - Mahsulotning nechta foydalanuvchisi bor? - Kompaniya qanchalik tez kengayishni kutmoqda? 3 oy, 6 oy va bir yilda kutilayotgan ko'lamlar qanday? - Kompaniyaning texnologiya to'plami nima? Dizaynni soddalashtirish uchun qanday mavjud xizmatlardan foydalanishingiz mumkin?

**"Yangiliklar tasmasi tizimini loyihalash" uchun suhbat namunasi:**

> Nomzod: Bu mobil ilova mi? Yoki veb-ilova? Yoki ikkisi ham? > Suhbatchi: Ikkisi ham. > > Nomzod: Mahsulot uchun eng muhim xususiyatlar nima? > Suhbatchi: Post joylashtirish va do'stlarning yangiliklar tasmasini ko'rish imkoniyati. > > Nomzod: Yangiliklar tasmasi teskari xronologik tartibda yoki ma'lum bir tartibda saralanaganmi? > Suhbatchi: Soddaligi uchun, tesmani teskari xronologik tartibda saralangan deb qabul qilaylik. > > Nomzod: Foydalanuvchi nechta do'stga ega bo'lishi mumkin? > Suhbatchi: 5000 > > Nomzod: Trafik hajmi qancha? > Suhbatchi: 10 million kunlik faol foydalanuvchilar (DAU) > > Nomzod: Tasma rasmlar, videolar yoki faqat matn o'z ichiga olishi mumkinmi? > Suhbatchi: U media fayllarni, shu jumladan rasmlar va videolarni o'z ichiga olishi mumkin.

2-bosqich - Yuqori darajali dizaynni taklif qilish va rozilik olish

Ushbu bosqichda biz yuqori darajali dizayn ishlab chiqish va suhbatchi bilan dizayn haqida kelishuvga erishishga harakat qilamiz. Jarayon davomida suhbatchi bilan hamkorlik qilish ajoyib g'oya.

- Dizayn uchun dastlabki chizma yarating. Fikr-mulohaza so'rang. Suhbatchiingizni hamkasb sifatida ko'ring va birga ishlang. Ko'plab yaxshi suhbatchilar gapirish va jalb bo'lishni yaxshi ko'radi. - Doska yoki qog'ozda asosiy komponentlar bilan quticha diagrammalari chizing. Bunga mijozlar (mobil/veb), API lar, veb-serverlar, ma'lumot xotiralari, kesh, CDN, xabar navbati va h.k. kirishi mumkin. - Chizmangiz ko'lam cheklovlariga mos kelishini baholash uchun taxminiy hisob-kitoblarni bajaring. Ovoz chiqarib fikrlang. Shovqin hisob-kitobiga kirishishdan oldin zarur bo'lsa suhbatchi bilan muloqot qiling. - Imkon bo'lsa, bir nechta aniq foydalanish holatlari ustidan o'ting. Bu yuqori darajali dizaynni shakllantirish uchun yordam beradi. Shuningdek, foydalanish holatlari hali ko'rib chiqmagan chegaraviy holatlarni aniqlashga yordam berishi mumkin.

**Misol — "Yangiliklar tasmasi tizimini loyihalash":**

Yuqori darajada, dizayn ikki oqimga bo'linadi: tasma nashr qilish va yangiliklar tasmasini qurish.

- **Tasma nashr qilish:** Foydalanuvchi post joylashtirganida, tegishli ma'lumotlar kesh/ma'lumotlar bazasiga yoziladi va post do'stlarning yangiliklar tasmasiga qo'shiladi. - **Yangiliklar tasmasini qurish:** Yangiliklar tasmasi do'stlarning postlarini teskari xronologik tartibda birlashtirish orqali quriladi.

1-rasm va 2-rasm mos ravishda tasma nashr qilish va yangiliklar tasmasini qurish oqimlari uchun yuqori darajali dizaynlarni taqdim etadi.

3-bosqich - Chuqur dizayn

Ushbu bosqichda siz va suhbatchi allaqachon quyidagi maqsadlarga erishgan bo'lishingiz kerak:

- Umumiy maqsadlar va xususiyat doirasi bo'yicha kelishuv - Umumiy dizayn uchun yuqori darajali chizma - Yuqori darajali dizayn bo'yicha suhbatchi dan fikr-mulohaza - Uning fikr-mulohazasiga asosan chuqur o'rganishda e'tibor qaratish kerak bo'lgan sohalar haqida dastlabki g'oyalar

Siz arxitekturadagi komponentlarni aniqlash va ustuvorlashtirish uchun suhbatchi bilan ishlashingiz kerak. Har bir suhbat boshqacha ekanligini ta'kidlash kerak. Ba'zan suhbatchi yuqori darajali dizaynni ko'rib chiqishga e'tibor qaratishni yaxshi ko'rishini bildirishi mumkin. Ba'zan, katta nomzod suhbatida, muhokama tizim ishlash xususiyatlariga, ehtimol tortishmalar va resurs baholashlariga qaratilishi mumkin. Ko'pchilik hollarda, suhbatchi ba'zi tizim komponentlari tafsilotlarini chuqurroq o'rganishingizni xohlashi mumkin.

Vaqtni boshqarish muhim, chunki qobiliyatingizni namoyish etmaydigan kichik tafsilotlarga berilib ketish oson.

**Misol — yangiliklar tasmasi tizimi uchun chuqur o'rganish:**

3-rasm va 4-rasm tasma nashr qilish va yangiliklar tasmasini olish foydalanish holatlari uchun batafsil dizaynni ko'rsatadi, bu "Yangiliklar Tasmasi Tizimini Loyihalash" bobida batafsil tushuntiriladi.

4-bosqich - Yakunlash

Ushbu yakuniy bosqichda suhbatchi sizdan bir nechta qo'shimcha savollar so'rashi yoki boshqa qo'shimcha fikrlarni muhokama qilish uchun erkinlik berishi mumkin. Amal qilish uchun bir nechta yo'nalishlar:

- Suhbatchi tizim tortismalarini aniqlashingizni va potentsial yaxshilashlarni muhokama qilishingizni xohlashi mumkin. Hech qachon dizayningiz mukammal va yaxshilash mumkin emas demaslik kerak. Har doim yaxshilash uchun narsa bor. - Suhbatchi ga dizayningiz haqida umumiy ma'lumot berish foydali bo'lishi mumkin. Bu ayniqsa bir nechta yechim taklif qilgan bo'lsangiz muhim. - Xato holatlari (server nosozligi, tarmoq uzilishi va h.k.) haqida gapirish qiziqarli. - Ish amaliyoti masalalari eslatilishga arziydi. Metrikalar va xato jurnallarini qanday monitoring qilasiz? Tizimni qanday ishga tushirasiz? - Keyingi ko'lam egri chizig'ini qanday hal qilish ham qiziqarli mavzu. Masalan, joriy dizayningiz 1 million foydalanuvchini qo'llab-quvvatlasa, 10 million foydalanuvchini qo'llab-quvvatlash uchun qanday o'zgartirishlar qilish kerak? - Ko'proq vaqtingiz bo'lganda qiladigan boshqa takomillashtirishlarni taklif qiling.

Qilish va qilmaslik kerak bo'lgan narsalar

**Qilish kerak:** - Har doim aniqlashtirish so'rang. Taxminingiz to'g'ri deb faraz qilmang. - Muammoning talablarini tushunib oling. - Na to'g'ri, na eng yaxshi javob mavjud. Yosh startapning muammolarini hal qilish uchun mo'ljallangan yechim, millionlab foydalanuvchilarga ega yetuk kompaniyaning yechimidan farq qiladi. - Suhbatchi ga nima haqida o'ylayotganingizni bildiring. Suhbatchi bilan muloqotda bo'ling. - Imkon bo'lsa, bir nechta yondashuvlarni taklif qiling. - Suhbatchi bilan chizma bo'yicha kelishgach, har bir komponent tafsilotlariga o'ting. Avval eng muhim komponentlarni loyihalashtiring. - Suhbatchi bilan g'oyalar almashing. Yaxshi suhbatchi siz bilan hamkasb sifatida ishlaydi. - Hech qachon taslim bo'lmang.

**Qilmaslik kerak:** - Odatiy suhbat savollariga tayyorlanmaslik. - Talablar va taxminlarni aniqlashtirmasdan yechimga o'tib ketmaslik. - Dastlab bitta komponent tafsilotlariga haddan tashqari chuqur kirmaslik. Avval yuqori darajali dizaynni bering, keyin tafsilotlarga o'ting. - Qiysangiz, maslahat so'rashdan tortinmaslik. - Yana bir bor, muloqotda bo'ling. Jim o'tirib o'ylamang. - Dizaynni bergach suhbat tugadi deb o'ylamang. Suhbatchi tugadi deguncha tugamadi. Erta va tez-tez fikr-mulohaza so'rang.

Har bir bosqichga vaqt ajratish

Tizim dizayni suhbati savollari odatda juda keng ko'lamlida bo'ladi va 45 daqiqa yoki bir soat butun dizaynni qoplash uchun yetarli emas. Vaqtni boshqarish muhim. Quyidagi — 45 daqiqalik suhbat sessiyasida vaqtingizni taqsimlash bo'yicha juda taxminiy ko'rsatma:

- **1-bosqich** — Muammoni tushunish va dizayn doirasini aniqlash: **3–10 daqiqa** - **2-bosqich** — Yuqori darajali dizaynni taklif qilish va rozilik olish: **10–15 daqiqa** - **3-bosqich** — Chuqur dizayn: **10–25 daqiqa** - **4-bosqich** — Yakunlash: **3–5 daqiqa**

Tarmoq tizimida rate limiter mijoz yoki xizmat tomonidan yuborilayotgan trafik tezligini nazorat qilish uchun ishlatiladi. HTTP dunyosida rate limiter belgilangan vaqt oralig'ida yuborilishi mumkin bo'lgan mijoz so'rovlari sonini cheklaydi. Agar API so'rovlari soni rate limiter tomonidan belgilangan chegara qiymatidan oshsa, barcha ortiqcha so'rovlar bloklanadi. Bir necha misol:

- Foydalanuvchi sekundiga 2 tadan ko'p post yoza olmaydi. - Bir xil IP manzildan kuniga maksimal 10 ta hisob yaratish mumkin. - Bir xil qurilmadan haftada 5 martadan ko'p mukofot talab qilinmaydi.

**API rate limiterdan foydalanishning afzalliklari:**

- **DoS hujumi sabab bo'lgan resurs tanqisligining oldini olish [1].** Yirik texnologiya kompaniyalari nashr etgan deyarli barcha API'lar biror shakldagi rate limitingni talab qiladi. Masalan, Twitter har 3 soatda 300 ta tweet bilan cheklaydi [2]. Google Docs API'larida quyidagi standart cheklov mavjud: o'qish so'rovlari uchun 60 soniyada foydalanuvchi boshiga 300 ta [3]. Rate limiter ortiqcha so'rovlarni bloklash orqali qasddan yoki tasodifan sodir bo'ladigan DoS hujumlarining oldini oladi. - **Xarajatlarni kamaytirish.** Ortiqcha so'rovlarni cheklash kamroq server va yuqori ustuvorlikdagi API'larga ko'proq resurs ajratishni anglatadi. Rate limiting pullik uchinchi tomon API'lardan foydalanadigan kompaniyalar uchun juda muhim. - **Serverlarning haddan ortiq yuklanishining oldini olish.** Server yukini kamaytirish uchun rate limiter botlar yoki foydalanuvchilarning noto'g'ri xatti-harakati sabab bo'lgan ortiqcha so'rovlarni filtrlash uchun ishlatiladi.

1-qadam - Muammoni tushunish va dizayn doirasini belgilash

Rate limiting turli algoritmlar yordamida amalga oshirilishi mumkin, ularning har birining afzalliklari va kamchiliklari bor.

**Talablar xulosasi:**

- Ortiqcha so'rovlarni aniq cheklash. - Past kechikish. Rate limiter HTTP javob vaqtini sekinlashtirmasligi kerak. - Imkon qadar kam xotira ishlatish. - Taqsimlangan rate limiting. Rate limiter bir nechta server yoki jarayonlar o'rtasida bo'lishilishi mumkin. - Istisnolarni boshqarish. Foydalanuvchilarning so'rovlari cheklanganida ularga aniq istisnolar ko'rsatilsin. - Yuqori nosozlikka chidamlilik. Agar rate limiter bilan muammolar bo'lsa (masalan, kesh server o'chib qolsa), bu butun tizimga ta'sir qilmasin.

2-qadam - Yuqori darajali dizayn taklif qilish va kelishuv olish

Oddiy qilib yuboriladigan bo'lsak, muloqot uchun asosiy mijoz va server modelidan foydalanamiz.

Rate limiterni qayerga joylashtirish kerak?

Intuitiv ravishda, rate limiterni mijoz yoki server tomonida amalga oshirish mumkin.

- **Mijoz tomonida amalga oshirish.** Umuman olganda, mijoz rate limitingni qo'llash uchun ishonchsiz joy, chunki mijoz so'rovlari zararli shaxslar tomonidan oson soxtalashtirilishi mumkin. Bundan tashqari, biz mijoz implementatsiyasini boshqara olmaymiz.

- **Server tomonida amalga oshirish.** 1-rasmda server tomonida joylashtirilgan rate limiter ko'rsatilgan.

Mijoz va server tomoni implementatsiyalaridan tashqari, muqobil usul ham mavjud. API serverlariga rate limiter qo'yish o'rniga, biz rate limiter middleware yaratamiz, u 2-rasmda ko'rsatilganidek API'laringizga so'rovlarni cheklaydi.

3-rasmda rate limiting qanday ishlashi ko'rsatilgan: API'miz sekundiga 2 ta so'rovga ruxsat beradi deb faraz qilsak, mijoz bir soniya ichida serverga 3 ta so'rov yuboradi. Birinchi ikkita so'rov API serverlariga yo'naltiriladi. Ammo, rate limiter middleware uchinchi so'rovni cheklaydi va HTTP status kodi 429 qaytaradi.

Cloud microservices [4] keng tarqalgan va rate limiting odatda API gateway deb ataluvchi komponent ichida amalga oshiriladi. API gateway — rate limiting, SSL tugatish, autentifikatsiya, IP whitelisting, statik kontentga xizmat ko'rsatish va boshqalarni qo'llab-quvvatlaydigan to'liq boshqariladigan xizmat.

**Joylashtirish bo'yicha umumiy ko'rsatmalar:**

- Dasturlash tili, kesh xizmati kabi mavjud texnologiya stackini baholang. - Biznes ehtiyojlaringizga mos rate limiting algoritmini aniqlang. - Agar allaqachon microservice arxitekturasidan foydalanayotgan bo'lsangiz va API gateway qo'shgan bo'lsangiz, API gatewayga rate limiter qo'shishingiz mumkin. - O'z rate limiting xizmatini yaratish vaqt talab etadi. Agar yetarli muhandislik resurslari bo'lmasa, tijorat API gateway yaxshiroq variant.

Rate limiting algoritmlari

Rate limiting turli algoritmlar yordamida amalga oshirilishi mumkin, ularning har birining o'ziga xos afzalliklari va kamchiliklari bor. Mashhur algoritmlar ro'yxati:

- Token bucket - Leaking bucket - Fixed window counter - Sliding window log - Sliding window counter

Token bucket algoritmi

Token bucket algoritmi rate limiting uchun keng qo'llaniladi. U oddiy, yaxshi tushunarli va internet kompaniyalari tomonidan keng ishlatiladi. Hem Amazon [5], hem Stripe [6] API so'rovlarini cheklash uchun ushbu algoritmdan foydalanadi.

**Qanday ishlaydi:** - Token bucket — oldindan belgilangan sig'imga ega konteyner. Tokenlar vaqti-vaqti bilan belgilangan tezlikda chelakka solinadi. Chelak to'lsa, tokenlar qo'shilmaydi. 4-rasmda ko'rsatilganidek, token bucket sig'imi 4 ta. Qayta to'ldiruvchi har soniyada chelakka 2 ta token soladi. Chelak to'lgandan so'ng, qo'shimcha tokenlar to'kiladi. - Har bir so'rov bitta tokenni sarflaydi. So'rov kelganida, chelakda yetarli tokenlar bor-yo'qligini tekshiramiz (5-rasm). - Agar yetarli tokenlar bo'lsa, har bir so'rov uchun bitta token olinadi va so'rov o'tkazib yuboriladi. - Agar yetarli tokenlar bo'lmasa, so'rov rad etiladi. - 6-rasm token sarflanishi, qayta to'ldirish va rate limiting mantig'i qanday ishlashini ko'rsatadi. Ushbu misolda token bucket hajmi 4, qayta to'ldirish tezligi esa 1 daqiqada 4 ta.

**Parametrlar:** - **Bucket size (chelak hajmi):** chelakda ruxsat etilgan tokenlarning maksimal soni - **Refill rate (qayta to'ldirish tezligi):** har soniyada chelakka solinadigan tokenlar soni

**Afzalliklari:** - Algoritmni amalga oshirish oson. - Xotiradan samarali foydalanish. - Token bucket qisqa muddatlar uchun trafik portlashiga ruxsat beradi. Tokenlar bo'lsa, so'rov o'tishi mumkin.

**Kamchiliklari:** - Algoritmda ikkita parametr bor: chelak hajmi va token qayta to'ldirish tezligi. Ularni to'g'ri sozlash qiyin bo'lishi mumkin.

Leaking bucket algoritmi

Leaking bucket algoritmi token bucket ga o'xshash, faqat so'rovlar belgilangan tezlikda qayta ishlanadi. U odatda first-in-first-out (FIFO) navbat yordamida amalga oshiriladi.

**Qanday ishlaydi:** - So'rov kelganida, tizim navbat to'la-to'lamas ekanligini tekshiradi. Agar to'la bo'lmasa, so'rov navbatga qo'shiladi. - Aks holda, so'rov rad etiladi. - So'rovlar navbatdan olinadi va muntazam intervallarda qayta ishlanadi.

7-rasm algoritmning qanday ishlashini tushuntiradi.

**Parametrlar:** - **Bucket size (chelak hajmi):** navbat hajmiga teng. Navbat belgilangan tezlikda qayta ishlanishi kerak bo'lgan so'rovlarni saqlaydi. - **Outflow rate (chiqish tezligi):** belgilangan tezlikda (odatda soniyada) qayta ishlanishi mumkin bo'lgan so'rovlar sonini belgilaydi.

Shopify, elektron tijorat kompaniyasi, rate-limiting uchun leaky bucket dan foydalanadi [7].

**Afzalliklari:** - Cheklangan navbat hajmi tufayli xotiradan samarali foydalanish. - So'rovlar belgilangan tezlikda qayta ishlanadi, shuning uchun barqaror chiqish tezligi kerak bo'lgan holatlar uchun mos keladi.

**Kamchiliklari:** - Trafik portlashi navbatni eski so'rovlar bilan to'ldiradi, ular vaqtida qayta ishlanmasa, yangi so'rovlar cheklanadi. - Algoritmda ikkita parametr bor. Ularni to'g'ri sozlash qiyin bo'lishi mumkin.

Fixed window counter algoritmi

**Qanday ishlaydi:** - Algoritm vaqt o'qini belgilangan o'lchamdagi vaqt oynalariga bo'ladi va har bir oyna uchun hisoblagich tayinlaydi. - Har bir so'rov hisoblagichni bittaga oshiradi. - Hisoblagich oldindan belgilangan chegaraga yetganida, yangi vaqt oynasi boshlanmaguncha yangi so'rovlar rad etiladi.

8-rasmda vaqt birligi 1 soniya va tizim sekundiga maksimal 3 ta so'rovga ruxsat beradi.

Bu algoritmning asosiy muammosi shundaki, vaqt oynalari chegarasidagi trafik portlashi ruxsat etilgan kvotadan ko'proq so'rovlar o'tishiga olib kelishi mumkin. 9-rasmda ko'rsatilganidek, 2:00:00 dan 2:01:00 gacha beshta so'rov va 2:01:00 dan 2:02:00 gacha yana beshtasi bor. 2:00:30 dan 2:01:30 gacha bo'lgan bir daqiqalik oynada 10 ta so'rov o'tadi — ruxsat etilgandan ikki baravar ko'p.

**Afzalliklari:** - Xotiradan samarali foydalanish. - Tushunish oson. - Birligi vaqt oynasi oxirida mavjud kvotani tiklash ba'zi foydalanish holatlari uchun mos keladi.

**Kamchiliklari:** - Oyna chegarasidagi trafik portlashi ruxsat etilgan kvotadan ko'proq so'rovlar o'tishiga olib kelishi mumkin.

Sliding window log algoritmi

Sliding window log algoritmi fixed window counterning chegaradagi portlash muammosini hal qiladi.

**Qanday ishlaydi:** 1. Algoritm so'rov vaqt tamg'alarini kuzatib boradi. Vaqt tamg'a ma'lumotlari odatda keshda, masalan Redis [8] ning tartiblangan to'plamlarida saqlanadi. 2. Yangi so'rov kelganida, barcha eskirgan vaqt tamg'alarni o'chirish. Eskirgan vaqt tamg'alar joriy vaqt oynasining boshlanishidan oldingi deb belgilanadi. 3. Yangi so'rovning vaqt tamg'asini jurnalga qo'shish. 4. Agar jurnal hajmi ruxsat etilgan songa teng yoki undan kam bo'lsa, so'rov qabul qilinadi. Aks holda, rad etiladi.

10-rasm algoritmni misol bilan tushuntiradi (rate limit: daqiqada 2 ta so'rov): - **1:00:01** — Jurnal bo'sh, so'rovga ruxsat beriladi. - **1:00:30** — Vaqt tamg'a qo'shildi, jurnal hajmi = 2, so'rovga ruxsat beriladi. - **1:00:50** — Vaqt tamg'a qo'shildi, jurnal hajmi = 3 > 2, so'rov rad etiladi. - **1:01:40** — 1:00:01 va 1:00:30 eskirgan vaqt tamg'alari o'chirildi. Jurnal hajmi = 2, so'rov qabul qilinadi.

**Afzalliklari:** - Rate limiting juda aniq. Har qanday siljuvchi oynada so'rovlar rate limitni oshmaydi.

**Kamchiliklari:** - Algoritm ko'p xotira sarflaydi, chunki so'rov rad etilgan bo'lsa ham, uning vaqt tamg'asi xotirada saqlanishi mumkin.

Sliding window counter algoritmi

Sliding window counter algoritmi — fixed window counter va sliding window logni birlashtirgan gibrid yondashuv.

11-rasm bu algoritmning qanday ishlashini ko'rsatadi. Deylik, rate limiter daqiqada maksimal 7 ta so'rovga ruxsat beradi, oldingi daqiqada 5 ta so'rov va joriy daqiqada 3 ta so'rov bo'lgan. Joriy daqiqaning 30% pozitsiyasida yangi so'rov kelsa:

``` Joriy oyna so'rovlari + oldingi oyna so'rovlari × qoplanish foizi = 3 + 5 × 0.7 = 6.5 → pastga yaxlitlangan 6 ```

Rate limiter daqiqada maksimal 7 ta so'rovga ruxsat berganligi sababli, joriy so'rov o'tishi mumkin.

**Afzalliklari:** - Trafik portlashlarini tekislaydi, chunki tezlik oldingi oynaning o'rtacha tezligiga asoslanadi. - Xotiradan samarali foydalanish.

**Kamchiliklari:** - Faqat qat'iy bo'lmagan orqaga qarab ko'rish oynasi uchun ishlaydi. Bu haqiqiy tezlikning taxminiy hisobi. Biroq, Cloudflare [10] tomonidan 400 million so'rovda o'tkazilgan tajribalarga ko'ra, so'rovlarning atigi 0.003% noto'g'ri ruxsat berilgan yoki cheklangan.

Yuqori darajali arxitektura

Rate limiting algoritmlarining asosiy g'oyasi oddiy. Yuqori darajada, bir xil foydalanuvchi, IP manzil va boshqalardan yuborilgan so'rovlar sonini kuzatib borish uchun hisoblagich kerak. Agar hisoblagich chegaradan katta bo'lsa, so'rov rad etiladi.

**Hisoblagichlarni qayerda saqlash kerak?** Diskka kirish sekinligi sababli ma'lumotlar bazasidan foydalanish yaxshi emas. In-memory kesh tanlanadi, chunki u tez va vaqtga asoslangan muddati tugash strategiyasini qo'llab-quvvatlaydi. Redis [11] rate limitingni amalga oshirishda mashhur variant. U ikkita buyruqni taqdim etadigan in-memory do'kon:

- **INCR:** Saqlangan hisoblagichni 1 ga oshiradi. - **EXPIRE:** Hisoblagich uchun vaqt chegarasini o'rnatadi. Vaqt muddati o'tsa, hisoblagich avtomatik o'chiriladi.

12-rasm rate limitingning yuqori darajali arxitekturasini ko'rsatadi: 1. Mijoz rate limiting middlewareka so'rov yuboradi. 2. Rate limiting middleware Redisdagi tegishli chelakdan hisoblagichni oladi va chegaraga yetilganligini tekshiradi. 3. Agar chegara yetilgan bo'lsa, so'rov rad etiladi. 4. Agar chegara yetilmagan bo'lsa, so'rov API serverlariga yuboriladi. Bu vaqt ichida tizim hisoblagichni oshiradi va Redisga qaytib saqlaydi.

3-qadam - Chuqur dizayn

Rate limiting qoidalari

Lyft o'zlarining rate-limiting komponentini ochiq manbaga chiqargan [12]. Misol rate limiting qoidalari:

```yaml domain: messaging descriptors: - key: message_type value: marketing rate_limit: unit: day requests_per_unit: 5 ```

Bu kuniga maksimal 5 ta marketing xabariga ruxsat beradi.

```yaml domain: auth descriptors: - key: auth_type value: login rate_limit: unit: minute requests_per_unit: 5 ```

Bu qoida loginni daqiqada 5 martadan ko'p bo'lmaslikka cheklaydi. Qoidalar odatda konfiguratsiya fayllarida yoziladi va diskda saqlanadi.

Rate limitni oshib ketish

So'rov rate limited bo'lgan taqdirda, API'lar mijozga HTTP javob kodi **429 (juda ko'p so'rovlar)** qaytaradi. Foydalanish holatlarga qarab, cheklangan so'rovlarni keyinchalik qayta ishlash uchun navbatga qo'yishimiz mumkin.

**Rate limiter headerlari** — mijozlar cheklanayotganligini qanday biladi:

- `X-Ratelimit-Remaining` — Oyna ichida qolgan ruxsat etilgan so'rovlar soni. - `X-Ratelimit-Limit` — Mijoz vaqt oynasi uchun qancha qo'ng'iroq qila olishi. - `X-Ratelimit-Retry-After` — Cheklanmasdan yana so'rov yuborishdan oldin kutish kerak bo'lgan soniyalar soni.

Batafsil dizayn

13-rasm tizimning batafsil dizaynini ko'rsatadi.

- Qoidalar diskda saqlanadi. Worker'lar tez-tez diskdan qoidalarni tortib olib keshda saqlaydi. - Mijoz serverga so'rov yuborganida, so'rov avval rate limiter middlewareka yuboriladi. - Rate limiter middleware keshdan qoidalarni yuklaydi. Redis keshidan hisoblagichlar va so'nggi so'rov vaqt tamg'asini oladi. Javobga asoslanib, rate limiter qaror qiladi: - Agar so'rov rate limited bo'lmasa, u API serverlariga yo'naltiriladi. - Agar so'rov rate limited bo'lsa, rate limiter mijozga 429 juda ko'p so'rovlar xatosini qaytaradi. Bu vaqt ichida so'rov rad etiladi yoki navbatga yo'naltiriladi.

Taqsimlangan muhitda rate limiter

Bitta server muhitida ishlaydigan rate limiter yaratish qiyin emas. Biroq, tizimni bir nechta server va parallel oqimlarni qo'llab-quvvatlash uchun kengaytirish boshqa gap. Ikkita muammo mavjud:

**1. Poygali holat (Race condition)**

Rate limiter yuqori darajada quyidagicha ishlaydi: Redisdan hisoblagich qiymatini o'qing, (hisoblagich + 1) chegaradan oshmasligini tekshiring, oshmasа, Redisdagi hisoblagich qiymatini 1 ga oshiring.

14-rasmda ko'rsatilganidek, juda parallel muhitda poygali holat yuzaga kelishi mumkin. Agar ikkita so'rov hamkorlikda hisoblagich qiymatini (3) o'qisa, ular ikkisi ham 5 ning to'g'ri qiymati o'rniga 4 ga oshiradi.

Locklar poygali holatni hal qilishning eng aniq yechimi. Biroq, locklar tizimni sezilarli darajada sekinlashtiradi. Ikkita strategiya keng qo'llaniladi: Lua script [13] va Redisdagi tartiblangan to'plamlar ma'lumotlar tuzilmasi [8].

**2. Sinxronizatsiya muammosi**

Millionlab foydalanuvchilarga xizmat ko'rsatish uchun bitta rate limiter server trafikni boshqara olmasligi mumkin. Bir nechta rate limiter serverlar ishlatilganida, sinxronizatsiya talab etiladi.

15-rasmda ko'rsatilganidek, agar 1-mijoz 1-rate limiterga va 2-mijoz 2-rate limiterga so'rov yuborsa, 1-rate limiter 2-mijoz haqida hech qanday ma'lumotga ega emas.

Bir mumkin bo'lgan yechim sticky sessionlardan foydalanish. Biroq, 16-rasmda ko'rsatilganidek, Redis kabi markazlashtirilgan ma'lumotlar do'konlaridan foydalanish yaxshiroq yondashuv.

Ishlashni optimallashtirish

**Birinchi:** Ko'p ma'lumot markazi sozlamasi rate limiter uchun muhim, chunki ma'lumot markazidan uzoqda joylashgan foydalanuvchilar uchun kechikish yuqori. Ko'pgina cloud xizmat provayderlari dunyoning ko'plab joylarida edge server joylarini qurishadi. Kechikishni kamaytirish uchun trafik avtomatik ravishda eng yaqin edge serverga yo'naltiriladi.

**Ikkinchi:** Yakuniy izchillik (eventual consistency) modeli bilan ma'lumotlarni sinxronlashtirish.

Monitoring

Rate limiter o'rnatilgandan so'ng, rate limiterning samarali ishlayotganligini tekshirish uchun tahliliy ma'lumotlarni to'plash muhim. Birinchi navbatda, quyidagilarni ta'minlashni xohlaymiz:

- Rate limiting algoritmi samarali. - Rate limiting qoidalari samarali.

Masalan, agar rate limiting qoidalari juda qattiq bo'lsa, ko'p to'g'ri so'rovlar rad etiladi. Bunday holda, qoidalarni biroz yumshatishni xohlaymiz. Boshqa misolda, agar flash sale kabi trafik to'satdan oshganda rate limiter samarasiz bo'lib qolsa, portlash trafikni qo'llab-quvvatlash uchun algoritmni almashtirshimiz mumkin. Bu yerda Token bucket yaxshi mos keladi.

4-qadam - Yakunlash

Ushbu bobda rate limitingning turli algoritmlarini va ularning afzalliklari/kamchiliklarini muhokama qildik:

- **Token bucket** — portlashlarga ruxsat beradi, amalga oshirish oson - **Leaking bucket** — barqaror chiqish, oqim uchun yaxshi - **Fixed window** — oddiy, ammo chegaradagi portlash muammosi bor - **Sliding window log** — aniq, xotira talab qiladi - **Sliding window counter** — taxminiy, ammo xotiradan samarali foydalanish

**Qo'shimcha muhokama nuqtalari:**

- **Qattiq va yumshoq rate limiting:** - Qattiq: So'rovlar soni chegarani oshib ketolmaydi. - Yumshoq: So'rovlar qisqa muddat chegarani oshishi mumkin.

- **Turli darajalarda rate limiting.** Ushbu bobda biz faqat ilova darajasida rate limiting haqida gaplashdik (HTTP: 7-qatlam). Rate limitingni boshqa qatlamlarda ham qo'llash mumkin. Masalan, Iptables [15] yordamida IP manzillar bo'yicha rate limiting qo'llashingiz mumkin (IP: 3-qatlam).

- **Rate limited bo'lmaslik — mijoz eng yaxshi amaliyotlari:** - Tez-tez API chaqiruvlarini oldini olish uchun mijoz keshidan foydalaning. - Cheklovni tushuning va qisqa vaqt oralig'ida juda ko'p so'rov yubormaang. - Mijozingiz istisnolardan munosib tiklana olishi uchun istisnolar yoki xatolarni ushlash uchun kod qo'shing. - Qayta urinish mantig'iga yetarli kutish vaqtini qo'shing.

Gorizontal kengayishga erishish uchun so'rovlar/ma'lumotlarni serverlar o'rtasida samarali va bir xilda taqsimlash muhim. Izchil xeshlash (consistent hashing) bu maqsadga erishish uchun keng qo'llaniladigan usul.

Qayta xeshlash muammosi

Agar sizda n ta kesh server bo'lsa, yukni muvozanatlashtirishning keng tarqalgan usuli quyidagi xesh metodidan foydalanishdir:

``` serverIndex = hash(key) % N, bu yerda N server poolining hajmi. ```

4 ta server va 8 ta satr kaliti bilan (1-jadval), kalit qaysi serverda saqlanganligi uchun `f(key) % 4` modul operatsiyasini bajaramiz. 1-rasm 1-jadvalga asoslangan kalit taqsimotini ko'rsatadi.

| key | hash | hash % 4 | |-----|------|----------| | key0 | 18358617 | 1 | | key1 | 26143584 | 0 | | key2 | 18131146 | 2 | | key3 | 35863496 | 0 | | key4 | 34085809 | 1 | | key5 | 27581703 | 3 | | key6 | 38164978 | 2 | | key7 | 22530351 | 3 |

**1-jadval**

Bu yondashuv server pool hajmi doimiy va ma'lumotlar taqsimoti bir xil bo'lganda yaxshi ishlaydi. Biroq, yangi serverlar qo'shilganda yoki mavjud serverlar olib tashlanganda muammolar yuzaga keladi. Masalan, agar 1-server o'chib qolsa, server pool hajmi 3 ga aylanadi. Modul operatsiyasini qo'llasak, turli server indekslarini olamiz, chunki serverlar soni 1 ga kamaygan.

| key | hash | hash % 3 | |-----|------|----------| | key0 | 18358617 | 0 | | key1 | 26143584 | 0 | | key2 | 18131146 | 1 | | key3 | 35863496 | 2 | | key4 | 34085809 | 1 | | key5 | 27581703 | 0 | | key6 | 38164978 | 1 | | key7 | 22530351 | 0 |

**2-jadval**

2-rasmda ko'rsatilganidek, ko'pchilik kalitlar qayta taqsimlanadi, nafaqat o'chgan serverda saqlangan kalitlar. Bu shuni anglatadiki, 1-server o'chib qolganda, ko'pgina kesh mijozlar noto'g'ri serverlarga ma'lumot olish uchun ulanadi. Bu kesh o'tkazib yuborish to'fonini keltirib chiqaradi. Izchil xeshlash ushbu muammoni yumshatish uchun samarali usul.

Izchil xeshlash

Vikipediyadan iqtibos: "Izchil xeshlash — bu xesh jadvali qayta o'lchamga keltirilganda va izchil xeshlash qo'llanilganda, o'rtacha faqat k/n kalitlarni qayta xaritalash kerak bo'lgan maxsus xeshlash turi, bu yerda k — kalitlar soni, n — uyalar soni. Aksincha, ko'pgina an'anaviy xesh jadvallarda massiv uyalari sonining o'zgarishi deyarli barcha kalitlarning qayta xaritalanishiga olib keladi [1]".

Xesh maydoni va xesh halqasi

SHA-1 xesh funksiyasi f sifatida qo'llaniladi va xesh funksiyasining chiqish diapazoni: x0, x1, x2, x3, …, xn. Kriptografiyada SHA-1 ning xesh maydoni 0 dan 2^160 - 1 gacha. Bu shuni anglatadiki, x0 nolga, xn esa 2^160 – 1 ga to'g'ri keladi. 3-rasm xesh maydonini ko'rsatadi.

Ikkala uchini birlashtirish orqali 4-rasmda ko'rsatilganidek xesh halqasini olamiz.

Xesh serverlar

Bir xil f xesh funksiyasidan foydalanib, serverlarni server IP yoki nomi asosida halqaga xaritalashtiramiz. 5-rasm 4 ta server xesh halqasiga xaritalashtirilganini ko'rsatadi.

Xesh kalitlar

Bu yerda qo'llaniladigan xesh funksiyasi "qayta xeshlash muammosi"dagi funksiyadan farq qiladi va modul operatsiyasi yo'q. 6-rasmda ko'rsatilganidek, 4 ta kesh kaliti (key0, key1, key2 va key3) xesh halqasiga xaritalashtirilgan.

Server qidirish

Kalit qaysi serverda saqlanganligi aniqlash uchun halqadagi kalit pozitsiyasidan soat miliga qarab yursak, server topiladi. 7-rasm ushbu jarayonni tushuntiradi: soat miliga qarab, key0 — 0-serverda; key1 — 1-serverda; key2 — 2-serverda va key3 — 3-serverda saqlanadi.

Server qo'shish

Yuqorida tasvirlangan mantiqdan foydalanib, yangi server qo'shish faqat kalitlarning kichik bir qismini qayta taqsimlashni talab qiladi.

8-rasmda, yangi 4-server qo'shilgandan so'ng, faqat key0 qayta taqsimlanishi kerak. k1, k2 va k3 bir xil serverlarda qoladi. 4-server qo'shilishidan oldin, key0 0-serverda saqlangan edi. Endi, key0 4-serverda saqlanadi, chunki halqadagi key0 pozitsiyasidan soat miliga qarab birinchi uchraydigan server — 4-server.

Server olib tashlash

Server olib tashlanganda, izchil xeshlash bilan faqat kalitlarning kichik bir qismi qayta taqsimlanadi. 9-rasmda, 1-server olib tashlanganda, faqat key1 2-serverga qayta xaritalashtirilishi kerak. Qolgan kalitlar ta'sirlanmaydi.

Asosiy yondashuvdagi ikkita muammo

Izchil xeshlash algoritmi MIT dan Karger va boshqalar tomonidan taklif qilingan [1]. Asosiy qadamlar:

1. Bir xil taqsimlangan xesh funksiyasidan foydalanib serverlar va kalitlarni halqaga xaritalash. 2. Kalit qaysi serverga xaritalashtirilganini aniqlash uchun kalit pozitsiyasidan soat miliga qarab halqadagi birinchi server topilguncha yuring.

**1-muammo: Bir xil bo'lmagan bo'linmalar.** Server qo'shilishi yoki olib tashlanishi hisobga olinganda, halqadagi barcha serverlar uchun bo'linmalarning bir xil o'lchamini saqlash imkonsiz. 10-rasmda, agar s1 olib tashlansa, s2 ning bo'linmasi s0 va s3 ning bo'linmasidan ikki baravar katta bo'ladi.

**2-muammo: Bir xil bo'lmagan kalit taqsimoti.** Agar serverlar 11-rasmda ko'rsatilgan pozitsiyalarga xaritalashtirilsa, ko'pchilik kalitlar 2-serverda saqlanadi. Biroq, 1-server va 3-serverda hech qanday ma'lumot yo'q.

Bu muammolarni hal qilish uchun **virtual tugunlar** yoki replikalar deb ataluvchi usul qo'llaniladi.

Virtual tugunlar

Virtual tugun haqiqiy tugunga ishora qiladi va har bir server halqada bir nechta virtual tugunlar bilan ifodalanadi. 12-rasmda ham 0-server, ham 1-server 3 ta virtual tugundga ega. s0 o'rniga halqada 0-serverni ifodalash uchun s0_0, s0_1 va s0_2 dan foydalanamiz. Xuddi shunday, s1_0, s1_1 va s1_2 halqada 1-serverni ifodalaydi. Virtual tugunlar bilan, har bir server bir nechta bo'linmalar uchun javobgar.

Kalit qaysi serverda saqlangan ekanligini aniqlash uchun kalit joylashuvidan soat miliga qarab yursak, halqada birinchi uchraydigan virtual tugun topiladi. 13-rasmda, k0 qaysi serverda saqlanganligi aniqlash uchun k0 joylashuvidan soat miliga qarab yursak, 1-serverga ishora qiluvchi s1_1 virtual tugunini topamiz.

Virtual tugunlar soni oshishi bilan kalit taqsimoti ko'proq muvozanatlashadi, chunki standart og'ish kichrayadi. Onlayn tadqiqotga ko'ra [2], bir yoki ikki yuz virtual tugun bilan standart og'ish o'rtacha qiymatning 5% (200 virtual tugun) dan 10% (100 virtual tugun) gacha. Biroq, virtual tugunlar haqidagi ma'lumotlarni saqlash uchun ko'proq joy talab etiladi. Bu bir kelishuvdir.

Ta'sirlangan kalitlarni topish

Server qo'shilganda yoki olib tashlanganda, ma'lumotlarning bir qismi qayta taqsimlanishi kerak.

14-rasmda, 4-server halqaga qo'shiladi. Ta'sirlangan diapazon s4 dan (yangi qo'shilgan tugun) boshlanadi va halqada soat miliga teskari yo'nalishda server topilguncha yuradi (s3). Shunday qilib, s3 va s4 o'rtasida joylashgan kalitlar s4 ga qayta taqsimlanishi kerak.

15-rasmda ko'rsatilganidek, server (s1) olib tashlanganda, ta'sirlangan diapazon s1 dan (olib tashlangan tugun) boshlanadi va halqada soat miliga teskari yo'nalishda server topilguncha yuradi (s0). Shunday qilib, s0 va s1 o'rtasida joylashgan kalitlar s2 ga qayta taqsimlanishi kerak.

Yakunlash

Izchil xeshlashning afzalliklari:

- Serverlar qo'shilganda yoki olib tashlanganda **minimal qayta taqsimlash**. - Ma'lumotlar ko'proq bir xil taqsimlanganligi uchun **gorizontal kengayish osonroq**. - **Hotspot kalit muammosini yumshatish.** Muayyan shardga haddan ortiq kirish server yuklanishiga olib kelishi mumkin. Izchil xeshlash ma'lumotlarni yanada bir xil taqsimlash orqali muammoni yumshatishga yordam beradi.

Izchil xeshlash real tizimlarimda keng qo'llaniladi:

- Amazon ning Dynamo ma'lumotlar bazasining bo'limlash komponenti [3] - Apache Cassandra da klaster bo'ylab ma'lumotlarni bo'limlash [4] - Discord chat ilovasi [5] - Akamai kontent yetkazib berish tarmog'i [6] - Maglev tarmoq yukni muvozanatlashuvi [7]

Kalit-qiymat do'koni, shuningdek kalit-qiymat ma'lumotlar bazasi deb ham ataladi, relyatsion bo'lmagan ma'lumotlar bazasi. Har bir noyob identifikator o'z bog'liq qiymati bilan birga kalit sifatida saqlanadi. Bu ma'lumotlar juftligi "kalit-qiymat" jufti deb ataladi.

Kalit-qiymat juftida kalit noyob bo'lishi kerak va kalit bilan bog'liq qiymatga kalit orqali kirishish mumkin. Kalitlar oddiy matn yoki xeshlangan qiymatlar bo'lishi mumkin. Ishlash nuqtai nazaridan, qisqaroq kalit yaxshiroq ishlaydi.

- Oddiy matn kalit: `"last_logged_in_at"` - Xeshlangan kalit: `253DDEC4`

Kalit-qiymat juftidagi qiymat satrlar, ro'yxatlar, ob'ektlar va boshqalar bo'lishi mumkin. Qiymat odatda Amazon DynamoDB [1], Memcached [2], Redis [3] kabi kalit-qiymat do'konlarida noaniq ob'ekt sifatida ko'riladi.

Ushbu bobda sizdan quyidagi operatsiyalarni qo'llab-quvvatlaydigan kalit-qiymat do'konini loyihalash so'raladi:

- `put(key, value)` — "kalit" bilan bog'liq "qiymat"ni kiritish - `get(key)` — "kalit" bilan bog'liq "qiymat"ni olish

Muammoni tushunish va dizayn doirasini belgilash

Mukammal dizayn yo'q. Har bir dizayn o'qish, yozish va xotira foydalanishining kelishuvlari bo'yicha muayyan muvozanatga erishadi. Izchillik va mavjudlik o'rtasida yana bir kelishuv amalga oshirilishi kerak. Ushbu bobda quyidagi xususiyatlardan iborat kalit-qiymat do'konini loyihalashtiramiz:

- Kalit-qiymat juftining hajmi kichik: 10 KB dan kam. - Katta ma'lumotlarni saqlash qobiliyati. - Yuqori mavjudlik: Tizim nosozliklar paytida ham tez javob beradi. - Yuqori kengayuvchanlik: Tizim katta ma'lumotlar to'plamini qo'llab-quvvatlash uchun kengaytirilishi mumkin.

- Avtomatik kengayish: Serverlarni qo'shish/o'chirish trafikka qarab avtomatik bo'lishi kerak. - Sozlanuvchi izchillik. - Past kechikish.

Bitta server kalit-qiymat do'koni

Bitta serverda joylashgan kalit-qiymat do'konini yaratish oson. Intuitiv yondashuv — kalit-qiymat juftlarini hamma narsani xotirada saqlaydigan xesh jadvalida saqlash. Xotiraga kirish tez bo'lsa ham, joy cheklanishi sababli hamma narsani xotiraga joylashtirish imkonsiz bo'lishi mumkin. Bitta serverga ko'proq ma'lumot joylashtirish uchun ikkita optimallashtirish amalga oshirilishi mumkin:

- Ma'lumotlarni siqish - Faqat tez-tez ishlatiladigan ma'lumotlarni xotirada, qolganlarini diskda saqlash

Bu optimallashtirish bilan ham, bitta server juda tez to'lib qolishi mumkin. Katta ma'lumotlarni qo'llab-quvvatlash uchun taqsimlangan kalit-qiymat do'koni talab etiladi.

Taqsimlangan kalit-qiymat do'koni

Taqsimlangan kalit-qiymat do'koni, shuningdek taqsimlangan xesh jadval deb ham ataladi, u kalit-qiymat juftlarini ko'plab serverlar bo'ylab taqsimlaydi. Taqsimlangan tizimni loyihalashtirishda CAP (Izchillik, Mavjudlik, Bo'linish Tolerantligi) teoremini tushunish muhim.

CAP teoremasi

CAP teoremasi taqsimlangan tizim bu uchta kafolatdan bir vaqtning o'zida ikkitadan ko'prog'ini ta'minlash imkonsizligini bildiradi: izchillik, mavjudlik va bo'linish tolerantligi.

- **Izchillik:** barcha mijozlar qaysi tugunga ulanishidan qat'i nazar bir vaqtning o'zida bir xil ma'lumotlarni ko'radi. - **Mavjudlik:** ma'lumot so'ragan har qanday mijoz ba'zi tugunlar o'chib qolgan bo'lsa ham javob oladi. - **Bo'linish Tolerantligi:** tizim tarmoq bo'linishlari (tugunlar o'rtasidagi aloqa uzilishlari) bo'lsa ham ishlashda davom etadi.

CAP teoremasi 1-rasmda ko'rsatilganidek, 3 ta xususiyatdan 2 tasini qo'llab-quvvatlash uchun uchta xususiyatdan biri qurbon qilinishi kerakligini bildiradi.

Kalit-qiymat do'konlari ular qo'llab-quvvatlaydigan ikkita CAP xususiyati asosida tasniflanadi:

- **CP tizimlari:** mavjudlikni qurbon qilib izchillik va bo'linish tolerantligini qo'llab-quvvatlaydi. - **AP tizimlari:** izchillikni qurbon qilib mavjudlik va bo'linish tolerantligini qo'llab-quvvatlaydi. - **CA tizimlari:** bo'linish tolerantligini qurbon qilib izchillik va mavjudlikni qo'llab-quvvatlaydi. Tarmoq nosozligi muqarrar bo'lganligi sababli, taqsimlangan tizim tarmoq bo'linishiga chidamli bo'lishi kerak. Shuning uchun CA tizimi real dunyo ilovalarida mavjud bo'la olmaydi.

**Ideal holat (2-rasm):** Tarmoq bo'linishi hech qachon sodir bo'lmaydi. n1 ga yozilgan ma'lumot avtomatik ravishda n2 va n3 ga replikalanadi. Ham izchillik, ham mavjudlik ta'minlanadi.

**Haqiqiy dunyo (3-rasm):** n3 o'chib qoladi va n1 va n2 bilan muloqot qila olmaydi. Biz ikkita variantdan birini tanlashimiz kerak: - **CP tizimi:** ma'lumotlar izchilsizligining oldini olish uchun n1 va n2 da barcha yozish operatsiyalarini bloklash, tizimni vaqtincha mavjud bo'lmagan holga keltiradi. Bank tizimlari odatda buni talab qiladi. - **AP tizimi:** o'qishlarni (potensial eskirgan) va yozishlarni qabul qilishni davom ettirish, bo'linish hal qilinganda ma'lumotlarni n3 ga sinxronlashtirish.

Tizim komponentlari

Kalit-qiymat do'konini qurish uchun ishlatiladigan asosiy komponentlar va usullar:

- Ma'lumotlarni bo'limlash - Ma'lumotlarni replikalash - Izchillik - Izchilsizlikni hal qilish - Nosozliklarni boshqarish - Tizim arxitekturasi diagrammasi - Yozish yo'li - O'qish yo'li

Quyidagi kontent asosan uchta mashhur kalit-qiymat do'kon tizimiga asoslanadi: Dynamo [4], Cassandra [5] va BigTable [6].

Ma'lumotlarni bo'limlash

Katta ilovalar uchun ma'lumotlarning to'liq to'plamini bitta serverga joylashtirish mumkin emas. Izchil xeshlash ma'lumotlarni bo'limlash uchun ajoyib usul:

1. Serverlar xesh halqasiga joylashtiriladi. 4-rasmda sakkizta server (s0–s7) xesh halqasiga joylashtirilgan. 2. Kalit bir xil halqaga xeshlanadi va soat miliga qarab birinchi uchraydigan serverda saqlanadi. Masalan, key0 s1 da saqlanadi.

Afzalliklari: - **Avtomatik kengayish:** serverlar yukga qarab avtomatik ravishda qo'shilishi va olib tashlanishi mumkin. - **Geterojinlik:** server uchun virtual tugunlar soni server quvvatiga mutanosib.

Ma'lumotlarni replikalash

Yuqori mavjudlik va ishonchlilikka erishish uchun ma'lumotlar N ta server bo'ylab asenkron replikalanishi kerak (N sozlanuvchi parametr). Kalit xesh halqasidagi pozitsiyaga xaritalangandan so'ng, o'sha pozitsiyadan soat miliga qarab yuring va ma'lumotlar nusxalarini saqlash uchun halqadagi birinchi N ta serverni tanlang. 5-rasmda (N = 3), key0 s1, s2 va s3 da replikalangan.

Virtual tugunlar bilan, halqadagi birinchi N ta tugun N dan kam jismoniy serverga tegishli bo'lishi mumkin. Bu muammodan qochish uchun soat miliga qarab yurish mantig'ini bajarishda faqat noyob serverlarni tanlaymiz.

Yaxshiroq ishonchlilik uchun replikalar alohida ma'lumot markazlarida joylashtiriladi va ma'lumot markazlari yuqori tezlikdagi tarmoqlar orqali ulanadi.

Izchillik

Ma'lumotlar bir nechta tugunlarda replikalanganligi sababli, u replikalar bo'ylab sinxronlashtirilishi kerak. Kvorum kelishuvi o'qish va yozish operatsiyalari uchun izchillikni kafolatlashi mumkin.

**Ta'riflar:** - **N** = Replikalar soni - **W** = W o'lchamidagi yozish kvorum. Yozish operatsiyasi muvaffaqiyatli deb hisoblanishi uchun yozish operatsiyasi W ta replikadan tasdiqlash olishi kerak. - **R** = R o'lchamidagi o'qish kvorum. O'qish operatsiyasi muvaffaqiyatli deb hisoblanishi uchun o'qish operatsiyasi kamida R ta replikadan javob kutishi kerak.

6-rasm N = 3 li misol ko'rsatadi. W = 1 koordinator yozish operatsiyasi muvaffaqiyatli deb hisoblanishidan oldin kamida bitta tasdiqlash olishi kerakligini anglatadi. Koordinator mijoz va tugunlar o'rtasida vositachi vazifasini bajaradi.

**Konfiguratsiya kelishuvlari:** - R = 1 va W = N bo'lsa: tez o'qish uchun optimallashtirilgan. - W = 1 va R = N bo'lsa: tez yozish uchun optimallashtirilgan. - W + R > N bo'lsa: kuchli izchillik kafolatlanadi (Odatda N = 3, W = R = 2). - W + R ≤ N bo'lsa: kuchli izchillik kafolatlanmaydi.

Izchillik modellari

Izchillik modeli ma'lumotlar izchilligining darajasini belgilaydi:

- **Kuchli izchillik:** har qanday o'qish operatsiyasi eng yangi yozilgan ma'lumot elementiga mos qiymatni qaytaradi. Mijoz hech qachon eskirgan ma'lumotlarni ko'rmaydi. - **Zaif izchillik:** keyingi o'qish operatsiyalari eng yangi qiymatni ko'rmasligi mumkin. - **Yakuniy izchillik:** zaif izchillikning muayyan shakli. Yetarli vaqt berilganda, barcha yangilanishlar tarqaladi va barcha replikalar izchil bo'ladi.

Kuchli izchillik odatda har bir replika joriy yozishni qabul qilmaguncha replika yangi o'qish/yozishlarni qabul qilmasligi orqali erishiladi — yuqori mavjudlikli tizimlar uchun ideal emas. Dynamo va Cassandra **yakuniy izchillik**ni qabul qiladi, bu bizning tavsiya etilgan izchillik modelimiz.

Izchilsizlikni hal qilish: versiyalash

Replikalash yuqori mavjudlikni ta'minlaydi, lekin replikalar o'rtasida izchilsizliklarni keltirib chiqaradi. Versiyalash va vektor bloklari izchilsizlik muammolarini hal qilish uchun ishlatiladi.

7-rasmda ko'rsatilganidek, n1 va n2 ikkala replika tuguni bir xil qiymatga (asl qiymat) ega. 8-rasmda ko'rsatilganidek, 1-server nomni "johnSanFrancisco" ga va 2-server nomni "johnNewYork" ga bir vaqtda o'zgartiradi. Bu ziddiyatli v1 va v2 versiyalarini yaratadi.

**Vektor soat** ushbu muammoni hal qilishda keng qo'llaniladigan usul. Vektor soat — ma'lumot elementi bilan bog'liq [server, versiya] jufti. U bir versiya boshqasidan oldin kelishini, keyin kelishini yoki boshqasiulanishini tekshirish uchun ishlatilishi mumkin.

Vektor soat D([S1, v1], [S2, v2], …, [Sn, vn]) bilan ifodalanadi deylik. Agar D ma'lumot elementi Si serveriga yozilsa: - Agar [Si, vi] mavjud bo'lsa, vi ni oshirish. - Aks holda, yangi yozuv [Si, 1] yaratish.

9-rasm vektor soat jarayonini ko'rsatadi: 1. Mijoz Sx serveriga D1 yozadi → vektor soat D1[(Sx, 1)] 2. Boshqa mijoz D1 ni o'qiydi, D2 ga yangilaydi, Sx ga qaytib yozadi → D2([Sx, 2]) 3. Boshqa mijoz D2 ni o'qiydi, D3 ga yangilaydi, Sy ga yozadi → D3([Sx, 2], [Sy, 1]) 4. Boshqa mijoz D2 ni o'qiydi, D4 ga yangilaydi, Sz ga yozadi → D4([Sx, 2], [Sz, 1]) 5. Mijoz D3 va D4 ni o'qiydi, ziddiyat aniqlaydi (D2 ham Sy, ham Sz tomonidan o'zgartirilgan). Mijoz ziddiyatni hal qiladi va D5 yuboradi → D5([Sx, 3], [Sy, 1], [Sz, 1])

**X versiyasi Y ning ajdodi** (ziddiyat yo'q) agar X dagi barcha versiya hisoblagichlari Y dagi mos hisoblagichlardan ≤ bo'lsa. **X versiyasi Y ning aka-ukasi** (ziddiyat bor) agar Y ning vektor soatida X dagi mos hisoblagichidan kamroq hisoblagichga ega bo'lgan ishtirokchi bo'lsa.

**Vektor soatning kamchiliklari:** 1. Mijozga murakkablik qo'shadi (ziddiyat hal qilish mantig'i kerak). 2. [server: versiya] juftlari tez o'sishi mumkin — chegara belgilab, eng eski juftlarni o'chirish orqali hal qilinadi.

Nosozliklarni boshqarish

Katta ko'lamdagi har qanday tizimda bo'lgani kabi, nosozliklar nafaqat muqarrar, balki keng tarqalgan.

Nosozliklarni aniqlash

Taqsimlangan tizimda boshqa server serverning o'chib qolganligini aytgani bilan uni haqiqat deb qabul qilish yetarli emas. Odatda, serverni o'chgan deb belgilash uchun kamida ikkita mustaqil ma'lumot manbai talab etiladi.

10-rasmda ko'rsatilganidek, hammadan-hammaga multicast oddiy yechim. Biroq, tizimda ko'p server bo'lganida bu samarasiz.

Yaxshiroq yechim — **gossip protokoli** kabi markazlashmagan nosozliklarni aniqlash usullaridan foydalanish: - Har bir tugun tugun a'zolik ro'yxatini (a'zo ID'lari va yurak urishi hisoblagichlari) saqlaydi. - Har bir tugun vaqti-vaqti bilan yurak urishi hisoblagichini oshiradi. - Har bir tugun vaqti-vaqti bilan tasodifiy tugunlar to'plamiga yurak urish signallarini yuboradi, ular boshqa tugunlar to'plamiga tarqaladi. - Agar yurak urishi oldindan belgilangan muddatdan ko'proq oshgandi bo'lmasa, a'zo oflayn deb hisoblanadi.

11-rasm gossip protokolini amalda ko'rsatadi: s0 tuguni s2 ning yurak urishi hisoblagichi uzoq vaqt davomida oshmayotganini sezadi va bu ma'lumotni tarqatadi. Boshqa tugunlar tasdiqlashgandan so'ng, s2 o'chgan deb belgilanadi.

Vaqtinchalik nosozliklarni boshqarish

Mavjudlikni yaxshilash uchun **"sloppy quorum"** [4] deb ataluvchi usul qo'llaniladi. Kvorum talabini qo'llash o'rniga, tizim yozish uchun halqadagi birinchi W ta sog'lom serverni va o'qish uchun birinchi R ta sog'lom serverni tanlaydi. Oflayn serverlar e'tiborga olinmaydi.

Agar server mavjud bo'lmasa, boshqa server vaqtincha so'rovlarni qayta ishlaydi. O'chgan server yonganida, ma'lumotlar izchilligini ta'minlash uchun o'zgarishlar qaytarib yuboriladi. Bu jarayon **hinted handoff** deb ataladi. 12-rasmda s2 mavjud bo'lmaganligi sababli, o'qish va yozishlar vaqtincha s3 tomonidan boshqariladi. s2 yana onlayn bo'lganda, s3 ma'lumotlarni s2 ga qaytaradi.

Doimiy nosozliklarni boshqarish

**Anti-entropi protokoli** har bir replika ma'lumotlarni solishtirib, har bir replikani eng yangi versiyaga yangilab replikalarni sinxronlaydi. **Merkle daraxti** izchilsizliklarni aniqlash va uzatiladigan ma'lumotlarni minimallash uchun ishlatiladi.

Vikipediyadan iqtibos [7]: "Xesh daraxti yoki Merkle daraxti — bu har bir barg bo'lmagan tugun o'z bola tugunlarining yorliqlari yoki qiymatlari (barg holatlarda) xeshi bilan belgilangan daraxt."

Merkle daraxtini qurish (1–12 kalit maydoni deb faraz qilsak):

**1-qadam:** Kalit maydonini chelaklarga bo'lish (13-rasm). Chelak daraxtning chuqurligini cheklash uchun ildiz darajasidagi tugun sifatida ishlatiladi.

**2-qadam:** Chelakdagi har bir kalitni bir xil xeshlash usuli bilan xeshlash (14-rasm).

**3-qadam:** Chelak boshiga bitta xesh tuguni yaratish (15-rasm).

**4-qadam:** Bolalarning xeshlarini hisoblab, ildizgacha daraxtni yuqoriga qurishda davom etish (16-rasm).

Ikkita Merkle daraxtini solishtirishda, ildiz xeshlarini solishtirishdan boshlang. Agar ildiz xeshlari mos kelsa, ikki serverda bir xil ma'lumot bor. Agar ildiz xeshlari mos kelmasa, qaysi chelaklar sinxronlashmagan ekanligini aniqlash uchun daraxtni ko'rib chiqing va faqat shu chelaklarni sinxronlashtiring.

Merkle daraxtlaridan foydalanib, sinxronlash kerak bo'lgan ma'lumotlar hajmi ikkita replika o'rtasidagi **farqlarga** mutanosib, ular o'z ichiga olgan ma'lumotlar hajmiga emas.

Tizim arxitekturasi diagrammasi

17-rasm kalit-qiymat do'konining asosiy arxitekturasini ko'rsatadi.

Asosiy xususiyatlar: - Mijozlar kalit-qiymat do'koni bilan oddiy API'lar orqali muloqot qiladi: `get(key)` va `put(key, value)`. - Koordinator — mijoz va kalit-qiymat do'koni o'rtasida vositachi vazifasini bajaradigan tugun. - Tugunlar izchil xeshlash yordamida halqada taqsimlanadi. - Tizim to'liq markazlashmagan, shuning uchun tugunlarni qo'shish va ko'chirish avtomatik bo'lishi mumkin. - Ma'lumotlar bir nechta tugunlarda replikalanadi. - Har bir tugun bir xil mas'uliyat to'plamiga ega bo'lganligi sababli yakka nosozlik nuqtasi yo'q.

18-rasm har bir tugun tomonidan bajariladigan vazifalarni ko'rsatadi.

Yozish yo'li

19-rasm yozish so'rovi muayyan tugunga yo'naltirilgandan keyin nima sodir bo'lishini tushuntiradi (Cassandra arxitekturasi [8] asosida):

1. Yozish so'rovi commit log faylida saqlanadi. 2. Ma'lumotlar xotira keshiga saqlanadi. 3. Xotira keshi to'lganda yoki oldindan belgilangan chegaraga yetganda, ma'lumotlar diskdagi SSTable [9] ga ko'chiriladi.

O'qish yo'li

O'qish so'rovi muayyan tugunga yo'naltirilgandan so'ng, u avval ma'lumot xotira keshida bor-yo'qligini tekshiradi. Agar bor bo'lsa, 20-rasmda ko'rsatilganidek ma'lumot mijozga qaytariladi.

Agar ma'lumot xotirada bo'lmasa, u diskdan olinadi. **Bloom filter** [10] odatda qaysi SSTable kalitni o'z ichiga olishini aniqlash uchun ishlatiladi.

Ma'lumot xotirada bo'lmagandagi o'qish yo'li (21-rasm): 1. Ma'lumot xotirada bor-yo'qligini tekshiring. Yo'q bo'lsa, 2-qadamga o'ting. 2. Bloom filterni tekshiring. 3. Bloom filter qaysi SSTabllar kalitni o'z ichiga olishi mumkinligini aniqlaydi. 4. SSTabllar ma'lumotlar to'plamining natijasini qaytaradi. 5. Natija mijozga qaytariladi.

Xulosa

| Maqsad/Muammo | Usul | |---|---| | Katta ma'lumotlarni saqlash qobiliyati | Yukni serverlar bo'ylab taqsimlash uchun izchil xeshlashdan foydalanish | | Yuqori mavjudlikli o'qish | Ma'lumot replikasiyasi + Ko'p ma'lumot markazi sozlamasi | | Yuqori mavjudlikli yozish | Vektor soatlari bilan versiyalash va ziddiyat hal qilish | | Ma'lumotlar to'plamini bo'limlash | Izchil xeshlash | | Qadamma-qadam kengayuvchanlik | Izchil xeshlash | | Geterojinlik | Izchil xeshlash | | Sozlanuvchi izchillik | Kvorum kelishuvi | | Vaqtinchalik nosozliklarni boshqarish | Sloppy quorum va hinted handoff | | Doimiy nosozliklarni boshqarish | Merkle daraxti | | Ma'lumot markazi uzilishlarini boshqarish | Ma'lumot markazlari o'rtasida replikasiya |

Ushbu bobda sizdan taqsimlangan tizimlarda noyob ID generator loyihalash so'raladi. Birinchi fikringiz an'anaviy ma'lumotlar bazasida auto_increment atributi bilan birlamchi kalit ishlatish bo'lishi mumkin. Biroq, auto_increment taqsimlangan muhitda ishlamaydi, chunki bitta ma'lumotlar bazasi serveri yetarlicha katta emas va minimal kechikish bilan bir nechta ma'lumotlar bazalari bo'ylab noyob ID'lar yaratish qiyin.

Bu yerda noyob ID'larning bir necha misoli (1-rasm):

1-qadam - Muammoni tushunish va dizayn doirasini belgilash

**Talablar:**

- ID'lar noyob bo'lishi kerak. - ID'lar faqat raqamli qiymatlar. - ID'lar 64-bitga sig'ishi kerak. - ID'lar sana bo'yicha tartiblanadi. - Sekundiga 10,000 dan ortiq noyob ID yaratish qobiliyati.

2-qadam - Yuqori darajali dizayn taklif qilish va kelishuv olish

Taqsimlangan tizimlarda noyob ID'lar yaratish uchun bir nechta variantdan foydalanish mumkin:

- Ko'p masterli replikatsiya - Universally unique identifier (UUID) - Ticket server - Twitter snowflake yondashuvi

Ko'p masterli replikatsiya

2-rasmda ko'rsatilganidek, birinchi yondashuv ko'p masterli replikatsiya.

Bu yondashuv ma'lumotlar bazalarining auto_increment xususiyatidan foydalanadi. Keyingi ID ni 1 ga oshirish o'rniga, uni k ga oshiramiz, bu yerda k — ishlatilayotgan ma'lumotlar bazasi serverlar soni. Yaratiladigan keyingi ID bir xil serverdagi oldingi ID ga k ni qo'shishga teng. Bu ba'zi kengayuvchanlik muammolarini hal qiladi, chunki ID'lar ma'lumotlar bazasi serverlar soni bilan kengayishi mumkin.

**Kamchiliklari:** - Bir nechta ma'lumot markazlari bilan kengaytirish qiyin. - ID'lar bir nechta server bo'ylab vaqt o'tishi bilan oshmaydi. - Server qo'shilganda yoki olib tashlanganda yaxshi kengaytmaydi.

UUID

UUID noyob ID'lar olishning yana bir oddiy usuli. UUID — kompyuter tizimlarida ma'lumotlarni identifikatsiya qilish uchun ishlatiladigan 128-bitli son. UUID ning to'qnashuv ehtimoli juda past — "taxminan 100 yil davomida har soniyada 1 milliard UUID yaratilgandan so'ng bitta takrorlanma yaratish ehtimoli 50% ga yetadi" [1].

Misol UUID: `09c93e62-50b4-468d-bf8a-c07e1040bfb2`

UUID'larni serverlar o'rtasida muvofiqlashtirishsiz mustaqil ravishda yaratish mumkin. 3-rasmda, har bir veb-server o'zining ID generatoriga ega va ID'larni mustaqil ravishda yaratish uchun javobgar.

**Afzalliklari:** - UUID yaratish oddiy. Serverlar o'rtasida muvofiqlashtirishga hojat yo'q, shuning uchun sinxronizatsiya muammolari bo'lmaydi. - Har bir veb-server o'zi sarflaydigan ID'larni yaratish uchun javobgar bo'lganligi sababli tizimni kengaytirish oson.

**Kamchiliklari:** - ID'lar 128 bit uzunlikda, lekin bizning talabimiz 64 bit. - ID'lar vaqt o'tishi bilan oshmaydi. - ID'lar raqamli bo'lmasligi mumkin.

Ticket Server

Ticket serverlar noyob ID'lar yaratishning yana bir qiziqarli usuli. Flickr taqsimlangan birlamchi kalitlar yaratish uchun ticket serverlarni ishlab chiqdi [2]. G'oya — bitta ma'lumotlar bazasi serverida (Ticket Server) markazlashtirilgan auto_increment xususiyatidan foydalanish.

**Afzalliklari:** - Raqamli ID'lar. - Amalga oshirish oson va kichikdan o'rta ko'lamdagi ilovalar uchun ishlaydi.

**Kamchiliklari:** - Yakka nosozlik nuqtasi. Bitta ticket server — ticket server o'chib qolsa, unga bog'liq barcha tizimlar muammoga duch keladi. Yakka nosozlik nuqtasini oldini olish uchun bir nechta ticket server o'rnatishimiz mumkin. Biroq, bu ma'lumotlarni sinxronlashtirish kabi yangi muammolarni keltirib chiqaradi.

Twitter snowflake yondashuvi

Twitter ning "snowflake" [3] deb ataluvchi noyob ID yaratish tizimi ilhomlantiruvchi va talablarimizni qondira oladi. ID ni to'g'ridan-to'g'ri yaratish o'rniga, ID ni turli bo'limlarga bo'lamiz. 5-rasm 64-bitli ID ning tuzilishini ko'rsatadi.

**64-bitli Snowflake ID bo'limlari:**

- **Ishora biti:** 1 bit. Har doim 0. Kelajakdagi foydalanish uchun ajratilgan. Imzolangan va imzosiz sonlarni ajratish uchun ishlatilishi mumkin. - **Vaqt tamg'asi:** 41 bit. Epoch yoki maxsus epoch dan millisekundlar. Twitter snowflake standart epoch 1288834974657 dan foydalanadi, bu Nov 04, 2010, 01:42:54 UTC ga teng. - **Datacenter ID:** 5 bit → 2^5 = 32 ta datacenter. - **Mashina ID:** 5 bit → 2^5 = datacenter boshiga 32 ta mashina. - **Ketma-ketlik raqami:** 12 bit. O'sha mashina/jarayonda yaratiladigan har bir ID uchun ketma-ketlik raqami 1 ga oshiriladi. Raqam har millisekundda 0 ga qayta o'rnatiladi.

3-qadam - Chuqur dizayn

Twitter snowflake ID generatoriga asoslangan yondashuvni tanlaymiz (6-rasm).

Datacenter ID'lari va mashina ID'lari ishga tushirishda tanlanadi, tizim ishga tushgandan so'ng odatda doimiy bo'ladi. Har qanday o'zgarishlar ehtiyotkorlik bilan ko'rib chiqilishi kerak, chunki bu qiymatlardagi tasodifiy o'zgarish ID to'qnashuvlariga olib kelishi mumkin. Vaqt tamg'asi va ketma-ketlik raqamlari ID generator ishlayotganda yaratiladi.

Vaqt tamg'asi

Eng muhim 41 bit vaqt tamg'asi bo'limini tashkil qiladi. Vaqt tamg'alari vaqt o'tishi bilan oshganligi sababli, ID'larni vaqt bo'yicha saralash mumkin. 7-rasm ikkilik ifodasining UTC ga qanday aylantirilishini ko'rsatadi.

41 bitda ifodalanishi mumkin bo'lgan maksimal vaqt tamg'asi:

``` 2^41 - 1 = 2,199,023,255,551 ms ≈ 69 yil ```

Bu shuni anglatadiki, ID generator 69 yil ishlaydi va bugungi sanaga yaqin maxsus epoch vaqti to'lib ketish vaqtini kechiktiradi. 69 yildan so'ng yangi epoch vaqti kerak bo'ladi yoki ID'larni ko'chirish uchun boshqa usullardan foydalanish kerak.

Ketma-ketlik raqami

Ketma-ketlik raqami 12 bit, bu 2^12 = 4096 kombinatsiya beradi. Bir xil serverda millisekund ichida birdan ko'p ID yaratilmasa, bu maydon 0. Nazariy jihatdan mashina millisekundda maksimal 4096 ta yangi ID yaratishi mumkin.

4-qadam - Yakunlash

Noyob ID generator loyihalashning turli yondashuvlarini muhokama qildik: ko'p masterli replikatsiya, UUID, ticket server va Twitter snowflake ga o'xshash noyob ID generator. Snowflake ni tanlaymiz, chunki u barcha foydalanish holatlarimizni qo'llab-quvvatlaydi va taqsimlangan muhitda kengayuvchan.

**Qo'shimcha muhokama nuqtalari:**

- **Soat sinxronizatsiyasi.** ID yaratish serverlarining bir xil soatga ega ekanligini faraz qilamiz. Server bir nechta yadroda ishlayotganida bu faraz to'g'ri bo'lmasligi mumkin. Network Time Protocol bu muammoning eng mashhur yechimi [4].

- **Bo'lim uzunligini sozlash.** Masalan, kamroq ketma-ketlik raqamlari, lekin ko'proq vaqt tamg'asi bitlari past bir vaqtlilik va uzoq muddatli ilovalar uchun samarali.

- **Yuqori mavjudlik.** ID generator muhim vazifali tizim bo'lganligi sababli, u yuqori darajada mavjud bo'lishi kerak.

Ushbu bobda qiziqarli va klassik tizim dizayni intervyu savolini ko'rib chiqamiz: tinyurl kabi URL qisqartiruvchi xizmatni loyihalash.

1-qadam - Muammoni tushunish va dizayn doirasini belgilash

**Asosiy foydalanish holatlari:** - URL qisqartirish: uzun URL berilganda → ancha qisqaroq URL qaytarish - URL yo'naltirish: qisqa URL berilganda → asl URL ga yo'naltirish - Yuqori mavjudlik, kengayuvchanlik va nosozlikka chidamlilik mulohazalari

**Taxminiy hisob-kitob:** - Yozish operatsiyasi: kuniga 100 million URL → ~sekundiga 1160 ta yozish - O'qish operatsiyasi (10:1 nisbat): ~sekundiga 11,600 ta o'qish - 10 yillik saqlash: 100M × 365 × 10 = 365 milliard yozuv - O'rtacha URL uzunligi: 100 bayt - 10 yil davomida saqlash: 365 milliard × 100 bayt = **36.5 TB**

2-qadam - Yuqori darajali dizayn taklif qilish va kelishuv olish

API Endpointlari

URL qisqartiruvchi asosan ikkita API endpointiga muhtoj:

**URL qisqartirish** — asl uzun URL bilan POST so'rov: ``` POST api/v1/data/shorten so'rov parametri: {longUrl: longURLString} qaytaradi: shortURL ```

**URL yo'naltirish** — qisqa URL bilan GET so'rov: ``` GET api/v1/shortUrl qaytaradi: HTTP yo'naltirish uchun longURL ```

URL yo'naltirish

1-rasm brauzerga tinyurl kiritilganda nima sodir bo'lishini ko'rsatadi. Server tinyurl so'rovini olgandan so'ng, qisqa URL ni 301 yo'naltirish bilan uzun URL ga o'zgartiradi.

Mijozlar va serverlar o'rtasidagi batafsil muloqot 2-rasmda ko'rsatilgan.

**301 vs 302 yo'naltirish:**

- **301 yo'naltirish:** So'ralgan URL uzun URL ga "doimiy ravishda" ko'chirilgan. Brauzer javobni keshga oladi va bir xil URL uchun keyingi so'rovlar URL qisqartiruvchi xizmatga YUBORILMAYDI — so'rovlar to'g'ridan-to'g'ri uzun URL serveriga boradi. **Server yukini kamaytirish** ustuvor bo'lganda foydalaning.

- **302 yo'naltirish:** URL uzun URL ga "vaqtincha" ko'chirilgan. Bir xil URL uchun keyingi so'rovlar avval URL qisqartiruvchi xizmatga YUBORILADI, keyin yo'naltiriladi. **Tahlil** muhim bo'lganda foydalaning (bosish tezligi va manbani kuzatadi).

URL yo'naltirishni amalga oshirishning eng intuitiv usuli — `<shortURL, longURL>` juftlarini saqlaydigan xesh jadvallalaridan foydalanish.

URL qisqartirish

Qisqa URL shunday ko'rinadi deb faraz qilaylik: `www.tinyurl.com/{hashValue}`. URL qisqartirishni qo'llab-quvvatlash uchun 3-rasmda ko'rsatilganidek uzun URL ni hashValue ga xaritalash uchun fx xesh funksiyasini topishimiz kerak.

Xesh funksiyasi quyidagilarga javob berishi kerak: - Har bir longURL bitta hashValue ga xeshlanishi kerak. - Har bir hashValue longURL ga qayta xaritalanishi mumkin bo'lishi kerak.

3-qadam - Chuqur dizayn

Ma'lumotlar modeli

Yuqori darajali dizaynda hamma narsa xesh jadvalida saqlanadi. Bu yaxshi boshlang'ich nuqta; biroq, bu yondashuv xotira resurslari cheklangan va qimmat bo'lganligi sababli real dunyo tizimlari uchun amalga oshirib bo'lmaydi. Yaxshiroq variant — `<shortURL, longURL>` xaritasini relyatsion ma'lumotlar bazasida saqlash. 4-rasm uchta ustunli oddiy ma'lumotlar bazasi jadval dizaynini ko'rsatadi: id, shortURL, longURL.

Xesh funksiyasi

Xesh funksiyasi uzun URL ni qisqa URL ga (hashValue) xeshlash uchun ishlatiladi.

**Xesh qiymat uzunligi:**

hashValue [0-9, a-z, A-Z] = 62 ta mumkin bo'lgan belgilardan iborat. 62^n ≥ 365 milliard bo'ladigan n uzunligini topish:

| n | Maksimal URL'lar soni | |---|------------------------| | 1 | 62 | | 5 | 916,132,832 | | 6 | 56,800,235,584 | | **7** | **~3.5 trillion** | | 8 | ~218 trillion |

n = 7 da, 62^7 ≈ 3.5 trillion — 365 milliard URL uchun yetarlicha. Shunday qilib **hashValue uzunligi = 7**.

Xesh + to'qnashuv hal qilish

Oddiy yechim — CRC32, MD5 yoki SHA-1 kabi mashhur xesh funksiyalaridan foydalanish. Hatto eng qisqa xesh qiymati ham (CRC32 dan) juda uzun. Birinchi yondashuv — xesh qiymatning birinchi 7 ta belgisini olish; biroq bu usul xesh to'qnashuvlariga olib kelishi mumkin.

Xesh to'qnashuvlarini hal qilish uchun to'qnashuv topilmaguncha yangi oldindan belgilangan satrni rekursiv ravishda qo'shamiz. Bu jarayon 5-rasmda tushuntirilgan.

Bu usul to'qnashuvni bartaraf qilishi mumkin; biroq, har bir so'rov uchun shortURL mavjudligini tekshirish uchun ma'lumotlar bazasiga so'rov yuborish qimmat. **Bloom filter** [2] ishlashni yaxshilashi mumkin — element to'plamning a'zosi ekanligini tekshirish uchun joy tejamkor ehtimoliy usul.

Base 62 konvertatsiya

Base 62 konvertatsiya URL qisqartiruvchilar uchun keng qo'llaniladigan yana bir yondashuv. Base 62 kodlash uchun 62 ta belgi ishlatadi. Xaritalar: 0→0, ..., 9→9, 10→a, 11→b, ..., 35→z, 36→A, ..., 61→Z.

Misol: 11157 ni (base 10) base 62 ga aylantiramiz:

``` 11157 = 2 × 62² + 55 × 62¹ + 59 × 62⁰ = [2, 55, 59] = base 62 da [2, T, X] ```

6-rasm konvertatsiya jarayonini ko'rsatadi. Qisqa URL quyidagicha bo'ladi: `https://tinyurl.com/2TX`

**Ikkita yondashuvni taqqoslash:**

| | Xesh + to'qnashuv hal qilish | Base 62 konvertatsiya | |---|---|---| | URL uzunligi | Doimiy qisqa URL uzunligi | Doimiy emas — ID bilan o'sadi | | Noyob ID | Noyob ID generatorga muhtoj emas | Noyob ID generatorga bog'liq | | To'qnashuv | Mumkin, hal qilish kerak | Mumkin emas (ID noyob) | | Xavfsizlik | Keyingi mavjud qisqa URL ni aniqlab bo'lmaydi | Keyingi qisqa URL ni aniqlash oson (xavfsizlik muammosi) |

URL qisqartirish chuqur tahlili

Dizaynimizda base 62 konvertatsiyadan foydalanamiz. 7-rasm URL qisqartirish oqimini ko'rsatadi:

1. longURL — kirish. 2. longURL allaqachon ma'lumotlar bazasida bor-yo'qligini tekshiring. 3. Agar ha → ma'lumotlar bazasidan shortURL ni olib mijozga qaytaring. 4. Agar yo'q → noyob ID generator orqali yangi noyob ID (birlamchi kalit) yarating. 5. Base 62 konvertatsiya bilan ID ni shortURL ga aylantiring. 6. ID, shortURL va longURL bilan ma'lumotlar bazasida yangi qator yarating.

**Aniq misol:** - Kirish: `https://en.wikipedia.org/wiki/Systems_design` - Noyob ID generator qaytaradi: `2009215674938` - Base 62 konvertatsiya: `2009215674938` → `"zn9edcu"` - Ma'lumotlar bazasiga saqlash: `(2009215674938, "zn9edcu", longURL)`

URL yo'naltirish chuqur tahlili

8-rasm URL yo'naltirishning batafsil dizaynini ko'rsatadi. Yozishdan ko'ra ko'proq o'qish bo'lganligi sababli, ishlashni yaxshilash uchun `<shortURL, longURL>` xaritasi keshda saqlanadi.

**URL yo'naltirish oqimi:** 1. Foydalanuvchi qisqa URL havolasini bosadi: `https://tinyurl.com/zn9edcu` 2. Yukni muvozanatlashtirgich so'rovni veb-serverlarga yo'naltiradi. 3. Agar shortURL allaqachon keshda bo'lsa, longURL ni to'g'ridan-to'g'ri qaytaring. 4. Agar shortURL keshda bo'lmasa, ma'lumotlar bazasidan longURL ni oling. Agar ma'lumotlar bazasida ham bo'lmasa, foydalanuvchi noto'g'ri shortURL kiritgan bo'lishi mumkin. 5. longURL foydalanuvchiga qaytariladi.

4-qadam - Yakunlash

Ushbu bobda API dizayni, ma'lumotlar modeli, xesh funksiyasi, URL qisqartirish va URL yo'naltirish haqida gaplashdik.

**Qo'shimcha muhokama nuqtalari:**

- **Rate limiter:** Potensial xavfsizlik muammosi — zararli foydalanuvchilar juda ko'p miqdorda URL qisqartirish so'rovlari yuboradi. Rate limiter IP manzil yoki boshqa filtrlash qoidalari asosida so'rovlarni filtrlashga yordam beradi. - **Veb-server kengaytirish:** Veb qatlam holatsiz bo'lganligi sababli, veb-serverlarni qo'shish yoki olib tashlash orqali osonlik bilan kengaytirish mumkin. - **Ma'lumotlar bazasini kengaytirish:** Ma'lumotlar bazasini replikalash va sharding keng qo'llaniladigan usullar. - **Tahlil:** Savollarga javob berish uchun tahlil yechimini integratsiya qilish: nechta kishi havolani bosadi? Qachon bosishadi? - **Mavjudlik, izchillik va ishonchlilik:** Har qanday katta tizim muvaffaqiyatining asosi.

Veb krouler robot yoki o'rgimchak deb ham ataladi. U qidiruv tizimlari tomonidan internetdagi yangi yoki yangilangan kontentni aniqlash uchun keng ishlatiladi. Kontent veb-sahifa, rasm, video, PDF fayl va hokazo bo'lishi mumkin. Veb krouler bir nechta veb-sahifalarni to'plash bilan boshlanadi va yangi kontentni to'plash uchun o'sha sahifalar havolalarini kuzatadi. 1-rasm kroul jarayonining vizual misolini ko'rsatadi.

**Veb kroulerlarning foydalanish holatlari:** - **Qidiruv tizimi indeksatsiyasi:** Qidiruv tizimlari uchun mahalliy indeks yaratish maqsadida veb-sahifalarni to'plash. Masalan, Googlebot — Google qidiruv tizimi orqasidagi veb krouler. - **Veb arxivlash:** Kelajakdagi foydalanish uchun ma'lumotlarni saqlab qolish maqsadida internetdan ma'lumot to'plash. Misollar: AQSh Kongress kutubxonasi [1], Yevropa Ittifoqi veb arxivi [2]. - **Veb data qazib olish:** Internetdan foydali bilim kashf qilish. Yirik moliyaviy firmalar aksiyadorlar yig'ilishlari va yillik hisobotlarni yuklab olish uchun kroullerlardan foydalanadi. - **Veb monitoring:** Internetdagi mualliflik huquqi va tovar belgisi buzilishlarini monitoring qilish. Masalan, Digimarc [3] pirat asarlarni aniqlash uchun kroullerlardan foydalanadi.

1-qadam - Muammoni tushunish va dizayn doirasini belgilash

**Yaxshi veb kroulerning xususiyatlari:**

- **Kengayuvchanlik:** Veb kroul parallel bajarish yordamida juda samarali bo'lishi kerak. - **Mustahkamlik:** Krouler noto'g'ri HTML, javob bermaydigan serverlar, ishdan chiqish, zararli havolalar va hokazolarni boshqarishi kerak. - **Muloyimlik:** Krouler qisqa vaqt oralig'ida veb-saytga juda ko'p so'rov yubormasligi kerak. - **Kengaytiruvchanlik:** Tizim yangi kontent turlarini qo'llab-quvvatlash uchun minimal o'zgarishlar bilan moslashuvchan.

**Taxminiy hisob-kitob:** - Oyiga 1 milliard veb-sahifa yuklab olish - QPS: 1B / 30 / 24 / 3600 ≈ **sekundiga 400 sahifa** (Cho'qqi: 800) - O'rtacha veb-sahifa hajmi: 500 KB - Oyiga saqlash: 1B × 500 KB = **500 TB/oy** - 5 yillik saqlash: 500 TB × 12 × 5 = **30 PB**

2-qadam - Yuqori darajali dizayn taklif qilish va kelishuv olish

2-rasmda ko'rsatilganidek yuqori darajali dizayn taklif qilamiz.

Asosiy komponentlar

- **Urug' URL'lar (Seed URLs):** Kroul jarayonining boshlang'ich nuqtasi. Joylashuv yoki mavzu asosida tanlanishi mumkin. - **URL Frontier:** Yuklab olish kerak bo'lgan URL'larni saqlaydi (FIFO navbat). Muloyimlik, ustuvorlik va yangilikni ta'minlaydi. - **HTML Downloader:** HTTP orqali internetdan veb-sahifalarni yuklab oladi. - **DNS Resolver:** URL'larni IP manzillarga tarjima qiladi. - **Kontent Parser:** Yuklab olingan veb-sahifalarni tahlil qiladi va tekshiradi. Kroul serveridan alohida — kroulni sekinlashtirmaslik uchun. - **Kontent Ko'rilganmi?:** Hash taqqoslash orqali takroriy kontentni aniqlaydi [7]. Veb-sahifalarning ~29% takroriy [6]. - **Kontent Saqlash:** HTML kontentti saqlash tizimi. Mashhur kontent xotirada; qolganlar diskda. - **URL Extraktor:** HTML sahifalardan havolalarni tahlil qiladi va ajratadi. Nisbiy yo'llarni mutlaq URL'larga aylantiradi (3-rasm). - **URL Filtri:** Muayyan kontent turlari, fayl kengaytmalari, xato havolalar va qora ro'yxatdagi saytlarni chiqarib tashlaydi. - **URL Ko'rilganmi?:** Takrorlanishni oldini olish uchun tashrif buyurilgan URL'larni kuzatuvchi ma'lumotlar tuzilmasi (bloom filter + xesh jadval). - **URL Saqlash:** Allaqachon tashrif buyurilgan URL'larni saqlaydi.

Veb krouler ish jarayoni

4-rasm ish jarayonini bosqichma-bosqich ko'rsatadi:

1. URL Frontierga urug' URL'larni qo'shing. 2. HTML Downloader URL Frontierdan URL'lar ro'yxatini oladi. 3. HTML Downloader DNS resolverdan IP manzillarni oladi va yuklab olishni boshlaydi. 4. Kontent Parser HTML sahifalarni tahlil qiladi va sahifalar noto'g'ri emasligini tekshiradi. 5. Tahlil qilingan kontent "Kontent Ko'rilganmi?" komponentiga uzatiladi. 6. "Kontent Ko'rilgan" HTML sahifaning saqlashda mavjudligini tekshiradi: - Agar ha → e'tiborsiz qoldirish (turli URL da takroriy kontent). - Agar yo'q → Havola Extraktori ga uzatish. 7. Havola extraktori HTML sahifalardan havolalarni ajratadi. 8. Ajratilgan havolalar URL filtriga uzatiladi. 9. Filtrlangan havolalar "URL Ko'rilganmi?" komponentiga uzatiladi. 10. "URL Ko'rilgan" URL allaqachon saqlashda bor-yo'qligini tekshiradi; agar ha, hech narsa qilish shart emas. 11. Agar URL ilgari qayta ishlanmagan bo'lsa, uni URL Frontierga qo'shing.

3-qadam - Chuqur dizayn

Chuqur ko'rib chiqiladigan asosiy mavzular: DFS vs BFS, URL frontier, HTML Downloader, mustahkamlik, kengaytiruvchanlik va muammoli kontent.

DFS va BFS

Veb veb-sahifalar tugunlar, giperhavolalar esa qirralar bo'lib xizmat qiladigan yo'naltirilgan grafik deb o'ylash mumkin. DFS odatda yaxshi tanlov emas, chunki chuqurlik juda katta bo'lishi mumkin.

BFS keng qo'llaniladi va FIFO navbat orqali amalga oshiriladi. Biroq, u ikkita muammoga ega:

1. **Muloyimlik muammosi:** Bir xil veb-sahifadagi havolalarning ko'pi ichki havolalar bo'lib, krouler bir xil hostdagi URL'larni qayta ishlash bilan band bo'ladi. Bu host serverni haddan ortiq yuklaydi (5-rasm). 2. **Ustuvorlik muammosi:** Standart BFS URL ning ustuvorligini hisobga olmaydi. URL'larni sahifa reytingi, veb trafik, yangilanish chastotasi va hokazolar asosida ustunlashtirmoq bo'lishimiz mumkin.

URL frontier

URL frontier BFS muammolarini hal qiladi: muloyimlik, URL ustuvorligi va yangilik.

**Muloyimlik:** Bir vaqtda bir xil hostdan bitta sahifani yuklab olish. Ikkita yuklab olish vazifasi o'rtasida kechikish qo'shiladi.

6-rasm muloyimlik dizaynini ko'rsatadi: - **Navbat routeri:** Har bir navbat (b1, b2, …, bn) faqat bir xil hostdagi URL'larni o'z ichiga olishini ta'minlaydi. - **Xaritalash jadvali:** Har bir hostni navbatga xaritalaydi. - **FIFO navbatlar b1 dan bn gacha:** Har bir navbat bir xil hostdagi URL'larni o'z ichiga oladi. - **Navbat selektori:** Har bir ishchi oqimni FIFO navbatga xaritalaydi. - **Ishchi oqimlar 1 dan N gacha:** Bir xil hostdan kechikish bilan veb-sahifalarni birin-ketin yuklab oladi.

**Ustuvorlik:** URL'larni foydalilik asosida ustunlashtirish (PageRank [10], veb-sayt trafigi, yangilanish chastotasi).

7-rasm ustuvorlik dizaynini ko'rsatadi: - **Ustunlashtiruvchi:** URL'larni kirish sifatida qabul qiladi va ustuvorliklarni hisoblaydi. - **Navbatlar f1 dan fn gacha:** Har bir navbatning tayinlangan ustuvorligi bor. Yuqori ustuvorlikli navbatlar yuqori ehtimollik bilan tanlanadi. - **Navbat selektori:** Yuqori ustuvorlikka yo'naltirilgan holda tasodifiy navbat tanlaydi.

8-rasm old navbatlar (ustuvorlikni boshqaradi) va orqa navbatlar (muloyimlikni boshqaradi) bilan to'liq URL frontier dizaynini ko'rsatadi.

**Yangilik:** Veb-sahifalar vaqti-vaqti bilan qayta kroul qilinishi kerak: - Veb-sahifalarning yangilanish tarixi asosida qayta kroul qilish. - Muhim sahifalarni birinchi va ko'proq tez-tez ustunlashtirish va qayta kroul qilish.

**Saqlash:** Gibrid yondashuv — ko'pchiligi diskda saqlanadi, navbatga qo'yish/chiqarish uchun xotirada bufferlar, vaqti-vaqti bilan diskka yoziladi.

HTML Downloader

**Robots.txt (Robotlarni chiqarib tashlash protokoli):** Veb-saytlar tomonidan kroullerlar bilan muloqot qilish uchun ishlatiladigan standart. Kroullerlar qaysi sahifalarni yuklab olishiga ruxsat ekanligini belgilaydi. Robots.txt natijalari vaqti-vaqti bilan keshlanadi.

`https://www.amazon.com/robots.txt` dan misol: ``` User-agent: Googlebot Disallow: /creatorhub/* Disallow: /rss/people/*/reviews Disallow: /gp/pdp/rss/*/reviews Disallow: /gp/cdp/member-reviews/ Disallow: /gp/aw/cr/ ```

**Ishlash optimallashtirmalari:**

1. **Taqsimlangan kroul:** Kroul ishlari bir nechta serverga taqsimlanadi, har biri bir nechta oqimda ishlaydi. URL maydoni kichikroq bo'laklarga bo'linadi (9-rasm).

2. **DNS Resolver keshi:** DNS hal qilish 10ms–200ms vaqt olishi va boshqa oqimlarni bloklashi mumkin. Domen nomlarini IP manzillarga xaritalovchi DNS keshini saqlang, u cron joblar tomonidan vaqti-vaqti bilan yangilanadi.

3. **Joylashuv:** Kroul serverlarini geografik jihatdan taqsimlash. Veb-sayt hostlariga yaqinroq kroul serverlar tezroq yuklab olishni ta'minlaydi.

4. **Qisqa vaqt chegarasi:** Maksimal kutish vaqtini belgilash. Agar host oldindan belgilangan vaqt ichida javob bermasa, krouler ishni to'xtatadi va boshqa sahifalarni kroul qiladi.

Mustahkamlik

- **Izchil xeshlash:** Yukni yuklovchilar o'rtasida taqsimlash. Yangi yuklovchi serverlar qo'shilishi yoki olib tashlanishi mumkin. - **Kroul holatlarini va ma'lumotlarni saqlash:** Nosozliklardan himoya qilish. Uzilgan kroul saqlangan holatlarni yuklab osonlik bilan qayta boshlash mumkin. - **Istisno boshqaruvi:** Krouler ishdan chiqmasdan istisnolarni munosib boshqarishi kerak. - **Ma'lumotlarni tekshirish:** Noto'g'ri kiritilgan ma'lumotlardan tizim xatolarining oldini olish.

Kengaytiruvchanlik

Krouler 10-rasmda ko'rsatilganidek yangi modullarni ulash orqali kengaytirilishi mumkin:

- **PNG Downloader moduli:** PNG fayllarini yuklab olish uchun ulanadi. - **Veb Monitor moduli:** Veb ni monitoring qilish va mualliflik huquqi hamda tovar belgisi buzilishlarining oldini olish uchun qo'shiladi.

Muammoli kontentni aniqlash va oldini olish

1. **Takroriy kontent:** Veb-sahifalarning ~30% takroriy. Xeshlar yoki nazorat yig'indilari takrorlanishni aniqlaydi [11].

2. **O'rgimchak tuzoqlari (Spider traps):** Kroulerni cheksiz tsiklga tushiradigan veb-sahifalar (masalan, cheksiz chuqur katalog tuzilmalari). Maksimal URL uzunligi belgilash orqali oldini olinadi. O'rgimchak tuzoqlari bo'lgan veb-saytlar g'ayriodatiy ko'p miqdorda kashf etilgan veb-sahifalar bilan aniqlanishi mumkin.

3. **Ma'lumot shovqini:** Reklamalar, kod parchalar, spam URL'lar va hokazolar imkon bo'lsa chiqarib tashlanishi kerak.

4-qadam - Yakunlash

Yaxshi kroulerning xususiyatlarini muhokama qildik: kengayuvchanlik, muloyimlik, kengaytiruvchanlik va mustahkamlik.

**Qo'shimcha muhokama nuqtalari:**

- **Server tomonida rendering:** JavaScript/AJAX ishlatadigan veb-saytlar havolalarni dinamik ravishda yaratadi. Tahlil qilishdan oldin avval server tomonida rendering (dinamik rendering) bajarish [12]. - **Keraksiz sahifalarni filtrlash:** Past sifatli va spam sahifalarni filtrlash uchun anti-spam komponenti [13] [14]. - **Ma'lumotlar bazasini replikalash va sharding:** Ma'lumotlar qatlami mavjudligi, kengayuvchanligi va ishonchliligini yaxshilash. - **Gorizontal kengayish:** Katta ko'lamdagi kroul uchun yuzlab yoki minglab serverlar kerak. Serverlarni holatsiz saqlash. - **Mavjudlik, izchillik va ishonchlilik:** Har qanday katta tizim muvaffaqiyatining asosi. - **Tahlil:** Ma'lumotlarni to'plash va tahlil qilish nozik sozlash uchun muhim.

Bildirishnomalar tizimi ko'plab ilovalarning eng mashhur xususiyatlaridan biridir. U foydalanuvchilarni muhim ma'lumotlar: yangiliklar, mahsulot yangilanishlari, tadbirlar, takliflar va shu kabilar haqida xabardor qiladi. Bu kundalik hayotimizning ajralmas qismiga aylangan. Ushbu bobda biz bildirishnomalar tizimini loyihalashtiramiz.

Bildirishnoma faqat mobil push-bildirishnomadan iborat emas. Bildirishnomalarning uch turi mavjud: mobil push-bildirishnoma, SMS xabar va elektron pochta. 1-rasmda har birining namunalari ko'rsatilgan.

1-qadam — Muammoni tushunish va loyiha doirasini belgilash

**Talablar:**

- Push-bildirishnomalar, SMS xabarlar va elektron pochta qo'llab-quvvatlanadi. - Yumshoq real-vaqt tizimi. Bildirishnomalar imkon qadar tezroq yetkazilishi kerak; yuqori yuklanishda kichik kechikish qabul qilinadi. - Qo'llab-quvvatlanadigan qurilmalar: iOS qurilmalari, Android qurilmalari, noutbuk/kompyuter. - Bildirishnomalar mijoz ilovalar tomonidan ishga tushirilishi yoki server tomonda rejalashtirilishi mumkin. - Foydalanuvchilar bildirishnomalardan voz kechishlari mumkin. - Kuniga 10 million mobil push-bildirishnoma, 1 million SMS xabar, 5 million elektron pochta.

2-qadam — Yuqori darajali dizayn taklif qilish va kelishuv olish

Ushbu bo'lim turli bildirishnoma turlarini qo'llab-quvvatlaydigan yuqori darajali dizaynlarni taqdim etadi: iOS push-bildirishnoma, Android push-bildirishnoma, SMS xabar va elektron pochta.

Bildirishnomalarning turli xillari

**iOS push-bildirishnomasi:**

2-rasmda iOS push-bildirishnomasi qanday ishlashi ko'rsatilgan.

iOS push-bildirishnomasi yuborish uchun uchta komponent kerak: - **Provider (Ta'minlovchi):** Apple Push Notification Service (APNs) ga bildirishnoma so'rovlarini yaratadi va yuboradi. Bildirishnoma so'roviga qurilma tokeni va yuklanma kiradi. Qurilma tokeni — push-bildirishnomalar yuborish uchun ishlatiladigan noyob identifikator. Yuklanma — bildirishnoma tafsilotlari bilan JSON lug'ati. - **APNs:** Apple tomonidan iOS qurilmalariga push-bildirishnomalarni tarqatish uchun taqdim etilgan masofaviy xizmat. - **iOS qurilmasi:** Push-bildirishnomalarni qabul qiladigan oxirgi mijoz.

**Android push-bildirishnomasi:**

Android o'xshash bildirishnoma oqimini qo'llaydi. APNs o'rniga Android qurilmalariga push-bildirishnomalar yuborish uchun Firebase Cloud Messaging (FCM) keng qo'llaniladi (3-rasm).

**SMS xabar:**

SMS xabarlari uchun Twilio [1], Nexmo [2] va boshqalar kabi uchinchi tomon SMS xizmatlari ishlatiladi (4-rasm).

**Elektron pochta:**

Kompaniyalar o'zlarining elektron pochta serverlarini o'rnatishlari mumkin bo'lsa-da, ko'pchiligi tijorat elektron pochta xizmatlaridan foydalanadi. 5-rasm elektron pochta bildirishnomasi oqimini ko'rsatadi. Sendgrid [3] va Mailchimp [4] eng mashhur elektron pochta xizmatlari qatoriga kiradi — ular yaxshiroq yetkazib berish darajasi va analitikani taklif etadi.

Aloqa ma'lumotlarini yig'ish oqimi

Bildirishnomalar yuborish uchun mobil qurilma tokenlarini, telefon raqamlarini yoki elektron pochta manzillarini yig'ish kerak. 6-rasmda ko'rsatilganidek, foydalanuvchi ilovamizni o'rnatganda yoki birinchi marta ro'yxatdan o'tganda, API serverlar foydalanuvchining aloqa ma'lumotlarini yig'ib, ma'lumotlar bazasida saqlaydi.

7-rasm aloqa ma'lumotlarini saqlash uchun soddalashtirilgan ma'lumotlar bazasi jadvallarini ko'rsatadi. Elektron pochta manzili va telefon raqami foydalanuvchi jadvalida saqlanadi. Qurilma tokenlari qurilma jadvalida saqlanadi. Foydalanuvchida bir nechta qurilma bo'lishi mumkin, bu push-bildirishnomalarni barcha qurilmalarga yuborish imkoniyatini bildiradi.

Bildirishnomalarni yuborish/qabul qilish oqimi

8-rasm bildirishnomalar tizimining ma'lumotlar bazasi jadvallarini ko'rsatadi: foydalanuvchi, qurilma, bildirishnoma jadvallari.

**Yuqori darajali dizayn (9-rasm):**

- **1-dan N-gacha xizmatlar:** Xizmat — bu bildirishnoma yuborish voqealarini ishga tushiradigan mikro-xizmat, cron-ish yoki taqsimlangan tizim bo'lishi mumkin. - **Bildirishnomalar tizimi:** Bildirishnomalar tizimi bildirishnomalar yuborish/qabul qilishning markaziy qismidir. Oddiy narsadan boshlash uchun faqat bitta bildirishnoma serveri ishlatiladi. U 1-dan N-gacha xizmatlarga API taqdim etadi va uchinchi tomon xizmatlari uchun bildirishnoma yuklamalarini yaratadi. - **Uchinchi tomon xizmatlari:** Foydalanuvchilarga bildirishnomalar yetkazish uchun javobgar. Uchinchi tomon xizmatlari bilan integratsiya diqqatli ko'rib chiqishni talab qiladi. Yaxshi kengaytirish imkoniyati muhim, chunki keyinchalik xizmatlarni almashtirishni xohlashimiz mumkin. - **iOS, Android, SMS, Elektron pochta:** Foydalanuvchilar qurilmalarida bildirishnomalar oladi.

**Dastlabki dizayndagi muammolar:** - Yagona nosozlik nuqtasi (SPOF): Bitta bildirishnoma serveri mavjudligi shuni anglatadiki, har qanday muammo butun tizimning ishdan chiqishiga olib keladi. - Kengaytirishning qiyinligi: Bildirishnomalar tizimi push-bildirishnomalar bilan bog'liq hamma narsani bitta serverda boshqaradi. - Ishlash tiqilishi: Bildirishnomalarni qayta ishlash va yuborish resurs talab qiluvchi bo'lishi mumkin. Hamma narsani bitta tizimda bajarish tizim ortiqcha yuklanishiga olib kelishi mumkin.

Yuqori darajali dizayn (takomillashtirilgan)

10-rasm takomillashtirilgan yuqori darajali dizaynni ko'rsatadi.

- **Ma'lumotlar bazasi va keshni bildirishnoma serveridan chiqarish.** - **Ko'proq bildirishnoma serverlari qo'shish va avtomatik gorizontal kengayishni sozlash.** - **Tizim komponentlarini ajratish uchun xabar navbatlarini joriy qilish.**

Komponentlar: - **1-dan N-gacha xizmatlar:** Bildirishnoma serverlari taqdim etgan API lar orqali bildirishnomalar yuboradigan turli xizmatlarni ifodalaydi. - **Bildirishnoma serverlari:** Quyidagi funksiyalarni ta'minlaydi: - Xizmatlarga bildirishnomalar yuborish uchun API lar taqdim etish. - Elektron pochta manzillari, telefon raqamlari va boshqalarni tekshirish uchun asosiy validatsiya. - Bildirishnomalarni ko'rsatish uchun zarur ma'lumotlarni olish maqsadida ma'lumotlar bazasi yoki keshni so'rash. - Parallel qayta ishlash uchun bildirishnoma ma'lumotlarini xabar navbatlariga qo'yish. - **Kesh:** Foydalanuvchi ma'lumotlari, qurilma ma'lumotlari, bildirishnoma shablonlari keshlandi. - **MB:** Foydalanuvchi, bildirishnoma, sozlamalar va boshqalar haqida ma'lumotlarni saqlash. - **Xabar navbatlari:** Ko'p sonli bildirishnomalar yuborilishi kerak bo'lganda bufer vazifasini bajaradi. Har bir bildirishnoma turiga alohida xabar navbati ajratiladi. - **Ishchilar:** Xabar navbatlaridan bildirishnoma hodisalarini oladi va tegishli uchinchi tomon xizmatlariga yuboradi. - **Uchinchi tomon xizmatlari, iOS, Android, SMS, Elektron pochta:** Dastlabki dizayndagi kabi.

3-qadam — Dizaynni chuqur tahlil qilish

Asosiy mavzular: ishonchlilik, qo'shimcha komponentlar va mulohazalar, yangilangan dizayn.

Ishonchlilik

**Ma'lumotlar yo'qolishini qanday oldini olish mumkin?**

Bildirishnomalar odatda yo'qolmasligi kerak. Ma'lumotlar doimiyligi uchun bildirishnoma jurnali ma'lumotlar bazasi ishlatiladi (11-rasm). Bildirishnoma jurnalida bildirishnoma ID si, turi, foydalanuvchi ID si, kanal, holat va boshqalar kabi ma'lumotlar maydonlari mavjud.

**Qabul qiluvchilar bildirishnomani aynan bir marta oladimi?**

Qisqa javob — yo'q. Bildirishnoma ko'pincha aynan bir marta yetkazilsa-da, taqsimlangan tizim xarakteri takroriy bildirishnomalar paydo bo'lishiga olib kelishi mumkin. Takrorlanishni kamaytirishga, biz dedup mexanizmini joriy qilamiz va har bir nosozlik holatini diqqat bilan ko'rib chiqamiz: - Bildirishnoma hodisasi birinchi marta kelganda, hodisa ID sini tekshirib, avval ko'rilganligini aniqlaymiz. - Agar avval ko'rilgan bo'lsa, u bekor qilinadi. Aks holda, bildirishnomani yuboramiz.

Qo'shimcha komponentlar va mulohazalar

**Bildirishnoma shabloni:** Katta bildirishnomalar tizimi kuniga millionlab bildirishnomalar yuboradi va ko'plab bildirishnomalar o'xshash formatga ega. Har bir bildirishnomani noldan yaratishdan qochish uchun bildirishnoma shablonlari joriy qilinadi. Bildirishnoma shabloni — parametrlarni, uslubni, kuzatib borish havolalarini va boshqalarni moslashtirish orqali o'zingizning noyob bildirishnomangizni yaratish uchun oldindan formatlangan bildirishnoma.

**Bildirishnoma sozlamalari:** Foydalanuvchilarga odatda bildirishnoma sozlamalari ustidan aniq nazorat beriladi. Har qanday bildirishnoma foydalanuvchiga yuborilishidan oldin, avval foydalanuvchi ushbu turdagi bildirishnomani olishga rozi bo'lganligini tekshiramiz.

**Tezlikni cheklash:** Foydalanuvchilarni juda ko'p bildirishnomalar bilan to'ldirib qo'ymaslik uchun foydalanuvchi qabul qila oladigan bildirishnomalar sonini cheklashimiz mumkin. Bu muhim, chunki agar biz juda tez-tez yuborsak, qabul qiluvchilar bildirishnomalarni umuman o'chirib qo'yishlari mumkin.

**Qayta urinish mexanizmi:** Uchinchi tomon xizmati bildirishnomani yuborishda muvaffaqiyatsiz bo'lganda, bildirishnoma qayta urinish uchun xabar navbatiga qo'shiladi. Muammo davom etsa, dasturchilarga ogohlantirish yuboriladi.

**Push-bildirishnomalarning xavfsizligi:** iOS yoki Android ilovalar uchun push-bildirishnoma API larini himoya qilish uchun appKey va appSecret ishlatiladi. Faqat autentifikatsiya qilingan yoki tasdiqlangan mijozlarga bizning API larimiz orqali push-bildirishnomalar yuborishga ruxsat beriladi.

**Navbatdagi bildirishnomalarni kuzatib borish:** Kuzatish uchun asosiy ko'rsatkich — navbatdagi bildirishnomalarning umumiy soni. Agar son katta bo'lsa, bildirishnoma hodisalari ishchilar tomonidan etarlicha tez qayta ishlanmayapti. Vaziyatni hal qilish uchun ko'proq ishchilar qo'shiladi (12-rasm).

**Hodisalarni kuzatib borish:** Ochish darajasi, bosish darajasi va faollik kabi bildirishnoma ko'rsatkichlari mijoz xatti-harakatlarini tushunish uchun muhim. Analitika xizmati hodisalarni kuzatib borishni amalga oshiradi. Bildirishnomalar tizimi va analitika xizmati o'rtasida integratsiya odatda talab qilinadi (13-rasm).

Yangilangan dizayn

Hammasini birlashtirgan holda, 14-rasm yangilangan bildirishnomalar tizimi dizaynini ko'rsatadi: bildirishnoma jurnali, bildirishnoma sozlamalari, tezlikni cheklash, qayta urinish mexanizmi, xavfsizlik, monitoring va hodisalarni kuzatib borish.

4-qadam — Yakunlash

Bildirishnomalar muhim ma'lumotlar bilan xabardor qilib turishgani uchun ajralmasdir. Biz push-bildirishnoma, SMS va elektron pochtani qo'llab-quvvatlaydigan bildirishnomalar tizimining dizaynini tavsifladik.

Tizim komponentlarini ajratish uchun xabar navbatlarini qo'lladik.

Muhokama qilishga arziydi boshqa mavzular:

- **Ishonchlilik:** Muvaffaqiyatsizlik darajasini minimallashtirish uchun mustahkam qayta urinish mexanizmi. - **Xavfsizlik:** Faqat tasdiqlangan mijozlar bildirishnomalar yuborishini ta'minlash uchun AppKey/appSecret juft. - **Kuzatib borish va monitoring:** Tizim sog'lig'ini ta'minlash uchun hodisalarni kuzatib borish va monitoringni amalga oshirish. - **Foydalanuvchi sozlamalarini hurmat qilish:** Foydalanuvchilar bildirishnomalardan voz kechishlari mumkin. Tizimimiz foydalanuvchi sozlamalarini hurmat qiladi. - **Tezlikni cheklash:** Foydalanuvchilar qabul qila oladigan bildirishnomalar chastotasini cheklash.

Ushbu bobda sizdan yangiliklar tasmasi tizimini loyihalash so'raladi. Yangiliklar tasmasi nima? Facebook yordam sahifasiga ko'ra, "Yangiliklar tasmasi bosh sahifangizning o'rtasida doimo yangilanib turadigan hikoyalar ro'yxatidir. Yangiliklar tasmasi Facebook'da kuzatadigan odamlar, sahifalar va guruhlarning holat yangilanishlari, suratlar, videolar, havolalar, ilova faolligi va yoqtirishlarini o'z ichiga oladi" [1]. Bu mashhur intervyu savoli. O'xshash savollar odatda: Facebook yangiliklar tasmasi, Instagram tasmasi, Twitter vaqt chizig'ini loyihalash bo'lib so'raladi.

1-qadam — Muammoni tushunish va loyiha doirasini belgilash

**Talablar:**

- Ham mobil ilova, ham veb-ilova. - Foydalanuvchi post e'lon qilishi va yangiliklar tasmasi sahifasida do'stlarining postlarini ko'rishi mumkin. - Yangiliklar tasmasi teskari xronologik tartibda saralanadi. - Foydalanuvchida 5000 tagacha do'st bo'lishi mumkin. - 10 million kunlik faol foydalanuvchi (DAU). - Tasma rasm va video kabi media fayllarni o'z ichiga olishi mumkin.

2-qadam — Yuqori darajali dizayn taklif qilish va kelishuv olish

Dizayn ikki oqimga bo'linadi: tasmani nashr qilish va yangiliklar tasmasini yaratish.

- **Tasmani nashr qilish:** Foydalanuvchi post e'lon qilganda, tegishli ma'lumotlar kesh va ma'lumotlar bazasiga yoziladi. Post do'stlarining yangiliklar tasmasiga tarqatiladi. - **Yangiliklar tasmasini yaratish:** Soddaligi uchun yangiliklar tasmasi do'stlar postlarini teskari xronologik tartibda birlashtirish orqali yaratiladi.

**Yangiliklar tasmasi API lari:**

Yangiliklar tasmasi API lari HTTP asosida. Ikki eng muhim API:

**Tasmani nashr qilish API si:** ``` POST /v1/me/feed Parametrlar: content: post matni auth_token: API so'rovlarini autentifikatsiya qilish ```

**Yangiliklar tasmasini olish API si:** ``` GET /v1/me/feed Parametrlar: auth_token: API so'rovlarini autentifikatsiya qilish ```

Tasmani nashr qilish

2-rasm tasmani nashr qilish oqimining yuqori darajali dizaynini ko'rsatadi.

- **Foydalanuvchi:** `/v1/me/feed?content=Salom&auth_token={auth_token}` API orqali post qiladi - **Yukni teng taqsimlovchi:** Trafikni veb-serverlarga taqsimlaydi. - **Veb-serverlar:** Trafikni turli ichki xizmatlarga yo'naltiradi. - **Post xizmati:** Postni ma'lumotlar bazasi va keshda saqlaydi. - **Fanout xizmati:** Yangi kontentni do'stlarning yangiliklar tasmasiga suradi. Tez olish uchun yangiliklar tasmasi ma'lumotlari keshda saqlanadi. - **Bildirishnoma xizmati:** Do'stlarga yangi kontent mavjudligi haqida xabar beradi va push-bildirishnomalar yuboradi.

Yangiliklar tasmasini yaratish

3-rasm yangiliklar tasmasini yaratish oqimining yuqori darajali dizaynini ko'rsatadi.

- **Foydalanuvchi:** Yangiliklar tasmasini olish uchun so'rov yuboradi: `/v1/me/feed` - **Yukni teng taqsimlovchi:** Trafikni veb-serverlarga yo'naltiradi. - **Veb-serverlar:** So'rovlarni yangiliklar tasmasi xizmatiga yo'naltiradi. - **Yangiliklar tasmasi xizmati:** Keshdan yangiliklar tasmasini oladi. - **Yangiliklar tasmasi keshi:** Yangiliklar tasmasini ko'rsatish uchun zarur yangiliklar tasmasi ID larini saqlaydi.

3-qadam — Dizaynni chuqur tahlil qilish

Yuqori darajali dizayn ikki oqimni qisqacha ko'rib chiqdi: tasmani nashr qilish va yangiliklar tasmasini yaratish. Bu yerda biz ushbu mavzularni chuqurroq muhokama qilamiz.

Tasmani nashr qilishni chuqur tahlil qilish

4-rasm tasmani nashr qilish uchun batafsil dizaynni ko'rsatadi. Ikkita komponentga e'tibor qaratamiz: veb-serverlar va fanout xizmati.

**Veb-serverlar:** Mijozlar bilan muloqot qilishdan tashqari, veb-serverlar autentifikatsiya va tezlikni cheklashni amalga oshiradi. Faqat to'g'ri auth_token bilan tizimga kirgan foydalanuvchilarga post qilishga ruxsat beriladi. Tizim foydalanuvchi ma'lum muddat ichida qila oladigan postlar sonini cheklaydi — bu spam va zararli kontentning oldini olish uchun muhim.

**Fanout xizmati:** Fanout — postni barcha do'stlarga yetkazish jarayoni. Ikkita fanout modeli turi:

**Yozishda fanout (push modeli):** Yangiliklar tasmasi yozish vaqtida oldindan hisoblanadi. Yangi post nashr etilgandan so'ng darhol do'stlarning keshiga yetkaziladi. - *Afzalliklari:* Yangiliklar tasmasi real vaqtda yaratiladi; oldindan hisoblanganligidan tez olish. - *Kamchiliklari:* Ko'p do'stlari bo'lgan foydalanuvchilar uchun sekin (hotkey muammosi); faolsiz foydalanuvchilar uchun resurslarni behuda sarflaydi.

**O'qishda fanout (pull modeli):** Yangiliklar tasmasi o'qish vaqtida yaratiladi. Foydalanuvchi bosh sahifasini yuklayotganda so'nggi postlar olinadi. - *Afzalliklari:* Faolsiz foydalanuvchilar uchun resurslarni behuda sarflamaydi; hotkey muammosi yo'q. - *Kamchiliklari:* Yangiliklar tasmasini olish sekin (oldindan hisoblanmagan).

**Gibrid yondashuv:** Ko'pchilik foydalanuvchilar uchun push modelidan foydalaning. Mashhurlar yoki ko'p do'stlari/kuzatuvchilari bo'lgan foydalanuvchilar uchun kuzatuvchilarga yangilik kontentini talab bo'yicha tortib olishga imkon bering. Konsistent xeshlash hotkey muammosini yengillashtiradi.

Fanout xizmati

5-rasm batafsil fanout xizmati oqimini ko'rsatadi:

1. Do'st ID larini graf ma'lumotlar bazasidan olish. Graf ma'lumotlar bazalari do'stlik munosabatlari va do'stlik tavsiyalarini boshqarish uchun mos keladi. 2. Foydalanuvchi keshidan do'stlar ma'lumotlarini olish. Foydalanuvchi sozlamalariga asoslanib do'stlarni filtrlash (o'chirilgan foydalanuvchilar, cheklangan postlar). 3. Do'stlar ro'yxati va yangi post ID sini xabar navbatiga yuborish. 4. Fanout ishchilar xabar navbatidan ma'lumotlarni oladi va yangiliklar tasmasi ma'lumotlarini yangiliklar tasmasi keshida `<post_id, user_id>` moslama jadvali sifatida saqlaydi. Xotira hajmini kichik ushlab turish uchun faqat ID lar saqlanadi. Konfiguratsiya qilinadigan chegara o'rnatiladi. 5. `<post_id, user_id>` ni yangiliklar tasmasi keshiga saqlash (6-rasm).

**6-rasm — Yangiliklar tasmasi kesh jadvali:**

| post_id | user_id | |---------|---------|

Yangiliklar tasmasini olishni chuqur tahlil qilish

7-rasm yangiliklar tasmasini olish uchun batafsil dizaynni ko'rsatadi. Media kontent (rasmlar, videolar) tez olish uchun CDN da saqlanadi.

1. Foydalanuvchi so'rov yuboradi: `/v1/me/feed` 2. Yukni teng taqsimlovchi so'rovlarni veb-serverlarga qayta taqsimlaydi. 3. Veb-serverlar yangiliklar tasmasi xizmatini yangiliklar tasmasini olish uchun chaqiradi. 4. Yangiliklar tasmasi xizmati yangiliklar tasmasi keshidan post ID lar ro'yxatini oladi. 5. Yangiliklar tasmasi xizmati to'liq gidratlantirilgan yangiliklar tasmasini yaratish uchun keshlardan (foydalanuvchi keshi va post keshi) to'liq foydalanuvchi va post ob'yektlarini oladi. 6. To'liq gidratlantirilgan yangiliklar tasmasi ko'rsatish uchun JSON formatida mijozga qaytariladi.

Kesh arxitekturasi

Kesh yangiliklar tasmasi tizimi uchun juda muhim. Kesh qatlami 5 qatlamga bo'linadi (8-rasm):

- **Yangiliklar tasmasi:** Yangiliklar tasmasi ID larini saqlaydi. - **Kontent:** Har bir post ma'lumotlarini saqlaydi. Mashhur kontent hot-keshda saqlanadi. - **Ijtimoiy graf:** Foydalanuvchi munosabatlari ma'lumotlarini saqlaydi. - **Harakat:** Foydalanuvchi postni yoqtirgani, javob bergani yoki boshqa harakatlar qilganligi haqida ma'lumot saqlaydi. - **Hisoblagichlar:** Yoqtirish, javob, kuzatuvchi, kuzatilayotgan va boshqalar uchun hisoblagichlarni saqlaydi.

4-qadam — Yakunlash

Biz ikki oqim bilan yangiliklar tasmasi tizimini loyihalashtiradik: tasmani nashr qilish va yangiliklar tasmasini olish.

**Ma'lumotlar bazasini kengaytirish:** - Vertikal kengaytirish vs Gorizontal kengaytirish - SQL vs NoSQL - Master-slave replikatsiya - O'qish replikalari - Konsistentlik modellari - Ma'lumotlar bazasini shardlash

**Boshqa muhokama nuqtalari:** - Veb qatlamini holatsiz ushlab turish - Ma'lumotlarni imkon qadar ko'proq keshlash - Bir nechta ma'lumotlar markazini qo'llab-quvvatlash - Xabar navbatlari bilan bo'shashgan komponentlar - Asosiy ko'rsatkichlarni kuzatib borish (cho'qqi soatlardagi QPS, foydalanuvchilar yangiliklar tasmasini yangilayotgandagi kechikish)

Ushbu bobda biz chat tizimining dizaynini o'rganamiz. Deyarli hamma chat ilovasidan foydalanadi. Chat ilovasi turli odamlar uchun turli funksiyalarni bajaradi — Facebook Messenger, WeChat, WhatsApp kabi bir-biriga chat ilovalar; Slack kabi ofis chat ilovalar; yoki Discord kabi o'yin chat ilovalar.

1-qadam — Muammoni tushunish va loyiha doirasini belgilash

**Talablar:**

- Ham 1 ta 1 ga, ham guruh chatini qo'llab-quvvatlash. - Ham mobil ilova, ham veb-ilova. - 50 million kunlik faol foydalanuvchi (DAU). - Guruh chatida maksimal 100 kishi. - Xususiyatlar: 1 ta 1 ga chat, guruh chati, onlayn ko'rsatgich. Faqat matnli xabarlar. - Xabar hajmi chegarasi: 100,000 belgidan kam. - Uchdan-uchga shifrlash: hozircha talab qilinmaydi. - Chat tarixi abadiy saqlanadi.

**Asosiy xususiyatlar:** - Kam kechikish bilan bir-biriga chat - Kichik guruh chati (maksimal 100 kishi) - Onlayn mavjudlik - Ko'p qurilmani qo'llab-quvvatlash (bitta hisob bir nechta qurilmada) - Push-bildirishnomalar

2-qadam — Yuqori darajali dizayn taklif qilish va kelishuv olish

Mijozlar bir-biri bilan to'g'ridan-to'g'ri muloqot qilmaydi. Har bir mijoz chat xizmatiga ulanadi. Chat xizmati quyidagilarni bajarishi kerak: - Boshqa mijozlardan xabarlarni qabul qilish. - Har bir xabar uchun to'g'ri qabul qiluvchilarni topish va xabarni uzatish. - Agar qabul qiluvchi onlayn bo'lmasa, u onlayn bo'lgunga qadar xabarlarni ushlab turish.

2-rasm mijozlar (jo'natuvchi va qabul qiluvchi) va chat xizmati o'rtasidagi munosabatlarni ko'rsatadi.

Polling

3-rasmda ko'rsatilganidek, polling — mijoz serverdan xabarlar mavjudligini davriy ravishda so'raydigan texnika. Polling chastotasiga qarab, polling qimmatga tushishi mumkin — u aksariyat hollarda "yo'q" degan javob beradigan savolga javob berish uchun qimmatli server resurslarini sarflaydi.

Uzun polling

Polling samarasiz bo'lganligi sababli, keyingi taraqqiyot uzun polling hisoblanadi (4-rasm). Uzun pollingda mijoz yangi xabarlar mavjud bo'lgunga yoki vaqt tugaguncha ulanishni ochiq ushlab turadi. Yangi xabarlar qabul qilingandan so'ng, darhol boshqa so'rov yuboradi.

**Kamchiliklari:** - Jo'natuvchi va qabul qiluvchi bir xil chat serveriga ulanmasligi mumkin (HTTP serverlari holatsiz). - Serverning mijoz uzilganligini aniqlashning yaxshi usuli yo'q. - Chat qilmaydigan foydalanuvchilar uchun samarasiz — uzun polling vaqt tugagandan keyin ham davriy ulanishlar qiladi.

WebSocket

WebSocket serverdan mijozga asinxron yangilanishlar yuborish uchun eng keng tarqalgan yechim hisoblanadi (5-rasm). WebSocket ulanishi mijoz tomonidan boshlanadi. U ikki tomonlama va doimiy. HTTP ulanishi sifatida boshlanadi va yaxshi belgilangan qo'l siqish orqali "yangilanadi". WebSocket ulanishlari 80 yoki 443 portdan foydalanishi sababli xavfsizlik devori mavjud bo'lsa ham ishlaydi.

6-rasm WebSocket (ws) dan ham jo'natuvchi, ham qabul qiluvchi tomonlarda foydalanishni ko'rsatadi. Har ikki tomonda ham WebSocket ishlatish orqali dizayn soddalashadi va amalga oshirish yanada to'g'riroq bo'ladi. WebSocket ulanishlari doimiy bo'lganligi sababli, server tomonida samarali ulanishlarni boshqarish muhim ahamiyatga ega.

Yuqori darajali dizayn

WebSocket ikki tomonlama muloqot uchun asosiy muloqot protokoli sifatida tanlandi. Biroq, boshqa xususiyatlarning aksariyati (ro'yxatdan o'tish, kirish, foydalanuvchi profili) an'anaviy so'rov/javob HTTP dan foydalanadi.

7-rasmda ko'rsatilganidek, chat tizimi uch asosiy toifaga bo'linadi: holatsiz xizmatlar, holatli xizmatlar va uchinchi tomon integratsiyasi.

- **Holatsiz xizmatlar:** Kirish, ro'yxatdan o'tish, foydalanuvchi profili va boshqalarni boshqaradi. Yukni teng taqsimlovchi orqasida joylashgan. Xizmatni kashf qilish mijozlarga chat serverlarining DNS xost nomlarini ro'yxatini beradi. - **Holatli xizmat:** Chat xizmati. Har bir mijoz chat serveriga doimiy WebSocket ulanishini saqlaydi. - **Uchinchi tomon integratsiyasi:** Push-bildirishnoma eng muhim integratsiya — ilova ishlamayotganda ham yangi xabarlar kelganda foydalanuvchilarga xabar beradi.

8-rasm moslashtirilgan yuqori darajali dizaynni ko'rsatadi: - Mijoz real vaqtda xabar almashish uchun chat serveriga doimiy WebSocket ulanishini saqlaydi. - Chat serverlari xabar yuborish/qabul qilishni osonlashtiradi. - Mavjudlik serverlari onlayn/offlayn holatini boshqaradi. - API serverlar foydalanuvchi kirishi, ro'yxatdan o'tishi, profil o'zgartirishini va boshqalarni boshqaradi. - Bildirishnoma serverlari push-bildirishnomalar yuboradi. - Kalit-qiymat do'koni chat tarixini saqlaydi.

Saqlash

Chat tizimida ikki turdagi ma'lumotlar mavjud:

1. **Umumiy ma'lumotlar** (foydalanuvchi profili, sozlamalar, do'stlar ro'yxati): Relyatsion ma'lumotlar bazalarida saqlanadi. Mavjudlik va kengayish uchun replikatsiya va shardlash.

2. **Chat tarixi ma'lumotlari**: Asosiy xususiyatlar: - Juda katta hajmdagi ma'lumotlar (Facebook Messenger va WhatsApp kuniga 60 milliard xabar qayta ishlaydi [2]). - Faqat so'nggi chatlar tez-tez ko'riladi. - Qidirish, eslatmalar, ma'lum xabarlarga o'tish uchun tasodifiy kirish kerak. - 1 ta 1 ga chat uchun o'qish/yozish nisbati taxminan 1:1.

**Kalit-qiymat do'konlari tavsiya etiladi, chunki:** - Oson gorizontal kengayishga imkon beradi. - Ma'lumotlarga kirish uchun juda kichik kechikish ta'minlaydi. - Relyatsion ma'lumotlar bazalari uzoq quyruqli ma'lumotlarni yaxshi boshqara olmaydi. - Ishlab chiqarishda isbotlangan: Facebook Messenger HBase [4] ishlatadi, Discord Cassandra [5] ishlatadi.

Ma'lumotlar modellari

**1 ta 1 ga chat uchun xabar jadvali (9-rasm):** Asosiy kalit `message_id` bo'lib, xabar ketma-ketligini aniqlashga yordam beradi. `created_at` ga tayanib bo'lmaydi, chunki ikki xabar bir vaqtda yaratilishi mumkin.

**Guruh chati uchun xabar jadvali (10-rasm):** Kompozit asosiy kalit `(channel_id, message_id)`. `channel_id` bo'linish kaliti, chunki guruh chatidagi barcha so'rovlar kanal ichida amalga oshiriladi.

**Xabar ID yaratish:** Quyidagilarga mos kelishi kerak: - ID lar noyob bo'lishi kerak. - ID lar vaqt bo'yicha saralanishi kerak (yangi satrlar yuqori ID larga ega).

Yondashuvlar: - MySQL dagi `auto_increment` — NoSQL da mavjud emas. - Snowflake kabi global 64-bitli ketma-ket raqam generatori (8-bobga qarang). - Mahalliy ketma-ket raqam generatori — ID lar faqat guruh/kanal ichida noyob.

3-qadam — Dizaynni chuqur tahlil qilish

Asosiy chuqur tahlil mavzulari: xizmatni kashf qilish, xabar almashish oqimlari va onlayn/offlayn ko'rsatgichlar.

Xizmatni kashf qilish

Xizmatni kashf qilish geografik joylashuv, server quvvati va boshqalarga asoslanib mijoz uchun eng yaxshi chat serverini tavsiya etadi. Apache Zookeeper [7] mashhur ochiq manbali yechim.

11-rasm Zookeeper qanday ishlashini ko'rsatadi: 1. A foydalanuvchi tizimga kirishga urinadi. 2. Yukni teng taqsimlovchi kirish so'rovini API serverlarga yuboradi. 3. Autentifikatsiyadan so'ng, xizmatni kashf qilish A foydalanuvchi uchun eng yaxshi chat serverni topadi (server 2 tanlanadi). 4. A foydalanuvchi WebSocket orqali chat serveri 2 ga ulanadi.

1 ta 1 ga chat oqimi

12-rasm A foydalanuvchi B foydalanuvchiga xabar yuborganda nima sodir bo'lishini tushuntiradi:

1. A foydalanuvchi Chat serveri 1 ga chat xabarini yuboradi. 2. Chat serveri 1 ID generatordan xabar ID sini oladi. 3. Chat serveri 1 xabarni xabar sinxronlash navbatiga yuboradi. 4. Xabar kalit-qiymat do'konida saqlanadi. 5a. B foydalanuvchi onlayn bo'lsa, xabar B foydalanuvchi ulangan Chat serveri 2 ga uzatiladi. 5b. B foydalanuvchi offlayn bo'lsa, push-bildirishnoma (PN) serverlaridan push-bildirishnoma yuboriladi. 6. Chat serveri 2 xabarni doimiy WebSocket ulanishi orqali B foydalanuvchiga uzatadi.

Bir nechta qurilmalar bo'yicha xabarlarni sinxronlash

13-rasm qurilmalar bo'yicha xabarlarni sinxronlashni ko'rsatadi. Har bir qurilma qurilmadagi so'nggi xabar ID sini kuzatib boradigan `cur_max_message_id` o'zgaruvchisini saqlaydi.

Xabarlar yangi deb hisoblanadi, qachonki: - Qabul qiluvchi ID hozir tizimga kirgan foydalanuvchi ID si ga teng bo'lganda. - Kalit-qiymat do'konidagi xabar ID `cur_max_message_id` dan katta bo'lganda.

Har bir qurilmada alohida `cur_max_message_id` bilan, har bir qurilma KV do'konidan yangi xabarlarni mustaqil ravishda olishi mumkin.

Kichik guruh chati oqimi

14-rasm A foydalanuvchi guruh chatida xabar yuborganda (3 a'zo: A, B, C) nima sodir bo'lishini ko'rsatadi. A foydalanuvchidan kelgan xabar har bir guruh a'zosining xabar sinxronlash navbatiga ko'chiriladi — biri B foydalanuvchi uchun, biri C foydalanuvchi uchun. Xabar sinxronlash navbatini qabul qiluvchining kiruv qutisi sifatida tasavvur qiling.

Bu dizayn kichik guruh chati uchun yaxshi, chunki: - Xabar sinxronlash oqimini soddalashtiradi — har bir mijoz faqat o'zining kiruv qutisini tekshirishi kerak. - Kichik guruhlar uchun har bir qabul qiluvchining kiruv qutisida nusxa saqlash juda qimmat emas.

WeChat guruhlarni 500 a'zo bilan cheklaydi [8]. Yirik guruhlar uchun har bir a'zo uchun xabar nusxasini saqlash qabul qilinmaydi.

15-rasm qabul qiluvchi tomonini ko'rsatadi: har bir qabul qiluvchida turli jo'natuvchilardan kelgan xabarlarni o'z ichiga olgan kiruv qutisi (xabar sinxronlash navbati) mavjud.

Onlayn mavjudlik

Mavjudlik serverlari onlayn holatni boshqaradi va WebSocket orqali mijozlar bilan muloqot qiladi.

**Foydalanuvchi kirishi (16-rasm):** WebSocket ulanishi o'rnatilgandan so'ng, A foydalanuvchining onlayn holati va `last_active_at` vaqt tamg'asi KV do'koniga saqlanadi.

**Foydalanuvchi chiqishi (17-rasm):** KV do'konida onlayn holat offlaynга o'zgartiriladi.

**Foydalanuvchi uzilishi:** Sodda yondashuv (uzilganda offlayn belgilash, qayta ulaganda onlayn) foydalanuvchilar tez-tez qisqa muddat uzilib/qayta ulanishi sababli yomon foydalanuvchi tajribasiga olib keladi (masalan, tunneldan o'tish).

**Yurak urishi mexanizmi (18-rasm):** Onlayn mijozlar mavjudlik serverlariga davriy ravishda yurak urishi hodisasini yuboradi. Agar mavjudlik serverlari x soniya ichida yurak urishini qabul qilsa, foydalanuvchi onlayn hisoblanadi. Aks holda, offlayn. Misol: mijoz har 5 soniyada yurak urishi yuboradi; agar 30 soniya davomida yurak urishi bo'lmasa, holat offlaynга o'zgaradi.

**Onlayn holat tarqatish (19-rasm):** Mavjudlik serverlari nashr-obuna modelidan foydalanadi. Har bir do'stlik juftligi kanal saqlaydi. A foydalanuvchining holati o'zgarganda, u A-B, A-C, A-D kanallariga nashr qiladi. Bu kanallar mos ravishda B, C, D foydalanuvchilar tomonidan obuna qilinadi.

Yirik guruhlar (100,000 a'zo) uchun holat o'zgarishini nashr qilish 100,000 ta hodisa yaratadi — bu juda qimmat. Yechim: foydalanuvchi guruhga kirganda yoki do'stlar ro'yxatini qo'lda yangilaganda onlayn holatni olish.

4-qadam — Yakunlash

Biz ham 1 ta 1 ga, ham kichik guruh chatini qo'llab-quvvatlaydigan chat tizimini taqdim etdik. Real vaqtda muloqot uchun WebSocket ishlatildi. Komponentlar: chat serverlar, mavjudlik serverlari, push-bildirishnoma serverlari, kalit-qiymat do'konlari, API serverlar.

**Qo'shimcha muhokama nuqtalari:**

- **Media fayllar:** Rasm va videolar uchun siqish, bulutli saqlash va miniatyuralar. - **Uchdan-uchga shifrlash:** Faqat jo'natuvchi va qabul qiluvchi xabarlarni o'qiy oladi (WhatsApp kabi [9]). - **Mijoz tomonda keshlash:** Mijoz va server o'rtasidagi ma'lumot uzatishni kamaytiradi. - **Geografik jihatdan taqsimlangan tarmoq:** Slack ning yaxshiroq yuklanish vaqti uchun foydalanuvchilar ma'lumotlarini keshlash yondashuvi [10]. - **Xatolarni boshqarish:** - Chat serveri xatosi: Xizmatni kashf qilish (Zookeeper) qayta ulanish uchun yangi chat serverni taqdim etadi. - Xabarni qayta yuborish mexanizmi: Muvaffaqiyatsiz xabar yetkazib berish uchun qayta urinish va navbat.

Google da qidirayotganda yoki Amazon da xarid qilayotganda, qidiruv maydoniga yozish bilan birga qidiruv atamasi uchun bir yoki bir nechta mos natijalar taqdim etiladi. Bu xususiyat avtoto'ldirish, typeahead, yozayotganda qidirish yoki bosqichma-bosqich qidirish deb ataladi. Bu bizni intervyu savoliga olib keladi: qidiruv avtoto'ldirish tizimini loyihalash, shuningdek "top k ni loyihalash" yoki "top k eng ko'p qidiriladigan so'rovlarni loyihalash" deb ham ataladi.

1-qadam — Muammoni tushunish va loyiha doirasini belgilash

**Talablar:**

- Moslashish faqat qidiruv so'rovining boshida qo'llab-quvvatlanadi. - 5 ta avtoto'ldirish taklifi qaytarish. - Takliflar mashhurligi (tarixiy so'rov chastotasi) bilan belgilanadi. - Imlo tekshiruvi yoki avtoto'g'rilash yo'q. - Faqat inglizcha so'rovlar (kichik harf alifbo belgilari). - 10 million DAU.

**Asosiy funksional bo'lmagan talablar:** - Tez javob vaqti: natijalarni 100 millisekund ichida qaytarishi kerak [1]. - Tegishlilik: takliflar qidiruv atamasiga tegishli bo'lsin. - Saralangan: natijalar mashhurligi yoki reytingli modellar bo'yicha saralangan. - Kengaytiriladigan va yuqori mavjudlikka ega.

**Taxminiy hisob-kitob:** - 10M DAU × kuniga 10 qidiruv × 20 belgi/so'rov = ~24,000 QPS (cho'qqi: ~48,000) - Kuniga 20% yangi so'rovlar: 10M × 10 × 20 bayt × 20% = **kuniga 0.4 GB yangi ma'lumot**

2-qadam — Yuqori darajali dizayn taklif qilish va kelishuv olish

Tizim ikki komponentga bo'linadi:

- **Ma'lumot yig'ish xizmati:** Foydalanuvchi kiritgan so'rovlarni yig'adi va ularni real vaqtda birlashtiradi (boshlang'ich nuqta; chuqur tahlilda optimallashtiriladi). - **So'rov xizmati:** Qidiruv so'rovi yoki prefiksi berilganda, eng ko'p qidiriladigan 5 ta atamani qaytaradi.

Ma'lumot yig'ish xizmati

Soddalashtirilgan chastota jadvali so'rov satrlarini va ularning chastotalarini saqlaydi. 2-rasm foydalanuvchilar ketma-ket "twitch", "twitter", "twitter" va "twillo" so'rovlarini kiritishi bilan chastota jadvali qanday yangilanishini ko'rsatadi.

So'rov xizmati

So'rov va chastota maydonlariga ega chastota jadvali berilganda, foydalanuvchi "tw" yozganda eng ko'p qidiriladigan 5 ta so'rov ko'rsatiladi (3-rasm).

**Namunaviy chastota jadvali (1-jadval):**

| So'rov | Chastota | |-------|----------| | twitter | 35 | | twitch | 29 | | twilight | 25 | | twin peak | 21 | | twitch prime | 18 | | twitter search | 14 | | twillo | 10 | | twin peak sf | 8 |

Top 5 ni olish uchun SQL so'rovi 4-rasmda ko'rsatilgan. Ma'lumotlar to'plami kichik bo'lganda bu qabul qilinadi; katta ma'lumotlar to'plami uchun ma'lumotlar bazasiga kirish tiqilishga olib keladi.

3-qadam — Dizaynni chuqur tahlil qilish

Chuqur tahlil mavzulari: trie ma'lumotlar tuzilmasi, ma'lumot yig'ish xizmati, so'rov xizmati, saqlashni kengaytirish, trie operatsiyalari.

Trie ma'lumotlar tuzilmasi

Relyatsion ma'lumotlar bazasidan top 5 so'rovni olish samarasiz. **Trie (prefiks daraxti)** ma'lumotlar tuzilmasi buni bartaraf etadi.

**Asosiy trie:** Satrlarni ixcham saqlaydi. Ildiz bo'sh satrni ifodalaydi. Har bir tugun bitta belgi saqlaydi va 26 ta bolasi bor (har bir mumkin bo'lgan belgi uchun bittadan). Har bir daraxt tuguni bitta so'z yoki prefiksni ifodalaydi.

5-rasm "tree", "try", "true", "toy", "wish", "win" so'rovlari bilan trie ni ko'rsatadi.

Chastota bo'yicha saralashni qo'llab-quvvatlash uchun tugunlarga chastota ma'lumotlari kiritiladi (6-rasm).

**Eng ko'p qidiriladigan top k so'rovlarni olish algoritmi:**

Aniqlang: p = prefiks uzunligi, n = triidagi tugunlar soni, c = tugunning bolalari.

1. Prefiksni toping. Vaqt: O(p) 2. Prefiks tugunidan barcha to'g'ri bolalarni olish uchun kichik daraxtni aylanib chiqing. Vaqt: O(c) 3. Bolalarni saraling va top k ni oling. Vaqt: O(c log c)

7-rasm k=2 va "tr" prefiksi uchun algoritmni ko'rsatadi: - 1-qadam: "tr" prefiks tugunini toping. - 2-qadam: Kichik daraxtni aylanib chiqing: [tree: 10], [true: 35], [try: 29]. - 3-qadam: Saraling va top 2 ni oling: [true: 35] va [try: 29].

Umumiy vaqt murakkabligi: O(p) + O(c) + O(c log c) — eng yomon holat uchun juda sekin.

**Ikki optimizatsiya:**

1. **Maksimal prefiks uzunligini cheklash:** Foydalanuvchilar kamdan-kam uzun so'rovlar yozadi, shuning uchun p ni ~50 bilan cheklang. "Prefiksni topish" ni O(p) dan O(1) ga kamaytiradi.

2. **Har bir tugunда top qidiruv so'rovlarini keshlash (8-rasm):** Har bir tugunда top k so'rovlarni saqlang. Masalan, "be" tuguni [best: 35, bet: 29, bee: 20, be: 15, beer: 10] ni saqlaydi. Ikkala optimizatsiya bilan algorithm jami O(1) vaqt oladi.

Ma'lumot yig'ish xizmati

Har bir so'rovda trieni yangilash amaliy emas (kuniga milliardlab so'rovlar; top takliflar ko'p o'zgarmaydi). 9-rasm qayta loyihalangan ma'lumot yig'ish xizmatini ko'rsatadi.

**Komponentlar:** - **Analitika jurnallari:** Qidiruv so'rovlari haqida faqat qo'shimcha xom ma'lumotlar. - **Birlashtiruvchilar:** Qayta ishlash uchun xom ma'lumotlarni birlashtiradi. Ko'pgina foydalanish holatlari uchun trie haftalik qayta quriladi. - **Birlashtirilgan ma'lumotlar:** Haftalik birlashtirilgan so'rov + chastota jadvali. - **Ishchilar:** Trieni yaratadigan va Trie MB da saqlaydigan asinxron serverlar. - **Trie keshi:** Tezkor o'qish uchun trieni xotirada ushlab turadigan taqsimlangan kesh (MB ning haftalik surati). - **Trie MB:** Doimiy saqlash. Ikki variant: 1. Hujjat do'koni (MongoDB) — haftalik trie suratini serializatsiya qilish. 2. Kalit-qiymat do'koni — har bir trie prefiksini kalitga, trie tugun ma'lumotlarini qiymatga moslashtirish (10-rasm).

So'rov xizmati

11-rasm takomillashtirilgan so'rov xizmati dizaynini ko'rsatadi:

1. Qidiruv so'rovi yukni teng taqsimlovchiga yuboriladi. 2. Yukni teng taqsimlovchi API serverlarga yo'naltiradi. 3. API serverlar Trie keshidan trie ma'lumotlarini oladi va avtoto'ldirish takliflarini yaratadi. 4. Kesh xatosi → Trie MB dan keshga ma'lumotlarni to'ldiradi.

**Optimizatsiyalar:** - **AJAX so'rovi:** Brauzer asinxron so'rovlar yuboradi; butun sahifani yangilamaydi. - **Brauzer keshlash (12-rasm):** Avtoto'ldirish takliflari brauzerda keshlanadi (masalan, Google 1 soat uchun `cache-control: private, max-age=3600` orqali keshlaydi). - **Ma'lumotlarni namunaviy olish:** Saqlash va qayta ishlash yukini kamaytirish uchun N so'rovdan faqat 1 tasi jurnallanadi.

Trie operatsiyalari

**Yaratish:** Trie Analitika jurnali/MB dan birlashtirilgan ma'lumotlar yordamida ishchilar tomonidan quriladi.

**Yangilash — ikki variant:** 1. Har hafta yangi qurilgan trie bilan butun trieni almashtirish. 2. Alohida tugunlarni to'g'ridan-to'g'ri yangilash (sekin; tugunni yangilashda ildizga qadar barcha ajdodlarni yangilash kerak). 13-rasm "beer" ni 10 dan 30 ga yangilashni ko'rsatadi — barcha ajdodlar yangilanadi.

**O'chirish:** Zararli, zo'ravonlik yoki xavfli avtoto'ldirish takliflarini olib tashlash. Trie keshi oldiga filtr qatlami qo'shiladi (14-rasm) nomaqbul takliflarni filtrlash uchun. MB dan jismoniy o'chirish keyingi yangilanish sikli uchun asinxron tarzda amalga oshiriladi.

Saqlashni kengaytirish

Trie bitta server uchun juda katta bo'lib qolganda, birinchi belgi asosida shardlang (26 ta serverga qadar). Ko'proq serverlar uchun ikkinchi yoki uchinchi belgi darajasida shardlang.

Sodda birinchi belgi asosidagi shardlash notekis taqsimotga olib keladi ('c' bilan boshlanadigan so'zlar 'x' ga nisbatan ko'proq). Nomutanosiblikni kamaytirish uchun tarixiy ma'lumotlar taqsimotini tahlil qiling va shard xaritasi menejeri orqali aqlliroq shardlashni qo'llang (15-rasm). Shard xaritasi satrlar qayerda saqlanishi kerakligini aniqlaydigan qidiruv MB ni saqlaydi.

4-qadam — Yakunlash

**Qo'shimcha muhokama nuqtalari:**

- **Ko'p tilli qo'llab-quvvatlash:** Trie tugunlarida Unicode belgilarini saqlash. - **Mamlakat bo'yicha top so'rovlar:** Har bir mamlakat uchun alohida trielar yaratish; tezroq javob uchun CDN da saqlash. - **Trendli (real vaqt) qidiruv so'rovlari:** Yanada murakkab — talab qiladi: - Shardlash orqali ishchi ma'lumotlar to'plamini kamaytirish. - So'nggi so'rovlarga ko'proq og'irlik beradigan o'zgartirilgan reyting modeli. - Oqimli qayta ishlash tizimlari: Apache Hadoop MapReduce [6], Spark Streaming [7], Apache Storm [8], Apache Kafka [9].

Ushbu bobda sizdan YouTube loyihalash so'raladi. Yechim Netflix va Hulu kabi boshqa video almashish platformalariga ham qo'llanilishi mumkin.

**YouTube statistikasi (2020):** - Oylik 2 milliard faol foydalanuvchi. - Kuniga 5 milliard video ko'rilishi. - AQSh kattalarining 73% YouTube dan foydalanadi. - 50 million kontent yaratuvchi. - 2019 yilda $15.1 milliard reklama daromadi (2018 yildan 36% o'sish). - Barcha mobil internet trafikining 37% ga javobgar. - 80 tilda mavjud.

1-qadam - Muammoni tushunish va dizayn doirasini belgilash

**Talablar:** - Xususiyatlar: video yuklash va video ko'rish qobiliyati. - Mijozlar: mobil ilovalar, veb-brauzerlar, smart TV. - 5 million DAU. - Mahsulotda o'rtacha kuniga 30 daqiqa. - Xalqaro foydalanuvchilar qo'llab-quvvatlanadi. - Ko'pchilik video rezolyutsiyalari va formatlari qabul qilinadi. - Shifrlash talab etiladi. - Maksimal video hajmi: 1 GB. - Mavjud cloud infratuzilmasidan foydalanish mumkin (Amazon, Google, Microsoft).

**Asosiy xususiyatlar:** - Tez video yuklash - Silliq video oqimi - Video sifatini o'zgartirish qobiliyati - Past infratuzilma xarajati - Yuqori mavjudlik, kengayuvchanlik va ishonchlilik

**Taxminiy hisob-kitob:** - Kunlik umumiy saqlash: 5M × 10% yuklash × 300 MB = **kuniga 150 TB** - CDN xarajati (CloudFront): 5M × 5 video × 0.3 GB × $0.02/GB = **kuniga $150,000**

2-qadam - Yuqori darajali dizayn taklif qilish va kelishuv olish

Hamma narsani noldan qurish o'rniga mavjud cloud xizmatlaridan (CDN va blob storage) foydalanamiz — kengayuvchan blob storage yoki CDN qurish juda murakkab (Netflix AWS dan foydalanadi [4], Facebook Akamai CDN dan foydalanadi [5]).

Tizim uchta komponentdan iborat (3-rasm): - **Mijoz:** Kompyuter, mobil telefon, smartTV. - **CDN:** Videolar CDN da saqlanadi; ijro paytida CDN dan oqimlandi. - **API serverlar:** Video oqimidan tashqari hamma narsa (feed tavsiyalari, yuklash URL yaratish, metadata MB/keshi, foydalanuvchi ro'yxatdan o'tish va hokazo).

Video yuklash oqimi

4-rasm quyidagi komponentlar bilan yuqori darajali video yuklash oqimini ko'rsatadi: - **Foydalanuvchi, Yukni muvozanatlashtirgich, API serverlar** - **Metadata MB:** Ishlash va yuqori mavjudlik uchun sharded va replikalangan. - **Metadata keshi:** Video metadata va foydalanuvchi ob'ektlarini keshlaydi. - **Asl saqlash:** Asl videolar uchun blob storage. - **Transkoding serverlari:** Turli qurilmalar/o'tkazuvchanlik uchun videoni boshqa formatlarga (MPEG, HLS va hokazo) aylantiradi. - **Transkodlangan saqlash:** Transkodlangan videolar uchun blob storage. - **CDN:** Videolar CDN da keshlanadi; bu yerdan oqimlandi. - **Yakunlanish navbati:** Video transkodlash yakunlanish hodisalari uchun xabar navbati. - **Yakunlanish boshqaruvchisi:** Hodisalarni tortib oladigan va metadata keshi va ma'lumotlar bazasini yangilaydigan workerlar.

Oqim ikkita parallel jarayonni bajaradi:

**Oqim a — Haqiqiy videoni yuklash (5-rasm):** 1. Video asl saqlashga yuklanadi. 2. Transkoding serverlari videoni olib va transkodlaydi. 3. Parallel ravishda: - 3a. Transkodlangan videolar → transkodlangan saqlash → CDN. - 3b. Transkodlash yakunlanish hodisalari → yakunlanish navbati → yakunlanish boshqaruvchisi → metadata MB/keshi. 4. API serverlar mijozga video oqim uchun tayyor ekanligini bildiradi.

**Oqim b — Video metadata ni yangilash (6-rasm):** Yuklash paytida, mijoz metadata ni yangilash uchun parallel so'rov yuboradi (fayl nomi, hajmi, formati). API serverlar metadata keshi va ma'lumotlar bazasini yangilaydi.

Video oqim tarqatish jarayoni

Oqimlash — kichik bo'laklarni uzluksiz qabul qilish degani — foydalanuvchilar butun videoni yuklab olmay darhol tomosha qila oladi.

**Mashhur oqim tarqatish protokollari:** - MPEG-DASH (Moving Picture Experts Group — Dynamic Adaptive Streaming over HTTP) - Apple HLS (HTTP Live Streaming) - Microsoft Smooth Streaming - Adobe HTTP Dynamic Streaming (HDS)

Videolar to'g'ridan-to'g'ri CDN dan oqimlandi; foydalanuvchiga eng yaqin edge server minimal kechikish bilan videoni yetkazib beradi (7-rasm).

3-qadam - Chuqur dizayn

Optimallashtirish va xatolarni boshqarish mexanizmlari bilan ikkala oqimni takomillashtiramiz.

Video transkodlash

**Transkodlash nima uchun muhim:** - Xom video juda katta (60fps HD bir soatlik video = yuzlab GB). - Ko'plab qurilmalar/brauzerlar faqat muayyan video formatlarni qo'llab-quvvatlaydi. - Yuqori o'tkazuvchanlikli foydalanuvchilar uchun yuqori rezolyutsiya, sekin ulanishlar uchun past rezolyutsiya yetkazib berish. - Tarmoq sharoitlari o'zgaradi, ayniqsa mobil qurilmalarda — moslashuvchan sifat muhim.

**Kodlash formatlari ikki qismdan iborat:** - **Konteyner:** Video, audio, metadata uchun savat (`.avi`, `.mov`, `.mp4`). - **Kodeklar:** Siqish/siqishni ochish algoritmlari (H.264, VP9, HEVC).

Yo'naltirilgan asiklik grafik (DAG) modeli

Transkodlash qimmat va turli yaratuvchilarning turli talablari bor (suv tamg'alari, eskizlar, HD). Yuqori parallellik bilan turli video qayta ishlash quvurlarini qo'llab-quvvatlash uchun Facebook ning video oqimlash tizimi [8] dan ilhomlangan DAG modelini qabul qilamiz.

8-rasm video transkodlash uchun DAG ni ko'rsatadi. Asl video video, audio va metadata ga bo'linadi. Qo'llanilishi mumkin bo'lgan vazifalar: - **Tekshirish:** Video yaxshi sifatda va noto'g'ri emasligini ta'minlash. - **Video kodlash:** Turli rezolyutsiya, kodek, bitreytlarga aylantirish (9-rasm). - **Eskiz:** Foydalanuvchi tomonidan yuklanadi yoki avtomatik yaratiladi. - **Suv tamg'asi:** Identifikatsiya ma'lumotlari bilan rasm qatlami.

Video transkodlash arxitekturasi

10-rasm oltita asosiy komponent bilan transkodlash arxitekturasini ko'rsatadi:

**Preprocessor (11-rasm):** To'rtta mas'uliyat: 1. Videoni GOP (Rasmlar Guruhi) ga hizalangan bo'laklarga bo'lish — mustaqil o'ynatiladigan birliklar, odatda bir necha soniya. 2. Mijoz tomonida bo'lishni qo'llab-quvvatlamaydigan eski qurilmalarni boshqarish. 3. Konfiguratsiya fayllaridan DAG yaratish (12-rasm, 13-rasm). 4. Nosozlik bo'lganda qayta urinish uchun vaqtinchalik saqlashda segmentlangan videolarni keshlash (GOP + metadata).

**DAG rejalashtiruvchi (14-rasm):** DAG grafini vazifa bosqichlariga bo'ladi va ularni resurs menejerining vazifa navbatiga qo'yadi. 15-rasm bosqichlarni ko'rsatadi: 1-bosqich (video/audio/metadata), 2-bosqich (video kodlash + eskiz, audio kodlash).

**Resurs menejeri (16-rasm):** 3 ta navbat va vazifa rejalashtiruvchisi bilan resurs taqsimlash samaradorligini boshqaradi (17-rasm): - **Vazifa navbati:** Bajarish uchun vazifalarning ustuvorlik navbati. - **Worker navbati:** Worker ish yuklanishi ma'lumotlarining ustuvorlik navbati. - **Ishlayotgan navbat:** Hozir ishlaydigan vazifalar va workerlar. - **Vazifa rejalashtiruvchisi:** Optimal vazifa/worker tanlaydi, workerni ishni bajarishga yo'naltiradi, ishlayotgan navbatni boshqaradi.

**Vazifa workerlari (18-rasm):** DAG da belgilangan vazifalarni bajaradi. Turli workerlar turli vazifalarni bajaradi (19-rasm).

**Vaqtinchalik saqlash (20-rasm):** Bir nechta saqlash tizimlari — metadata xotirada keshlanadi, video/audio blob storage da. Video qayta ishlash tugagandan so'ng bo'shatiladi.

**Kodlangan video (21-rasm):** Yakuniy chiqish (masalan, `funny_720p.mp4`).

Tizim optimallashtirmalari

**Tezlik — video yuklashni parallel bajarish (22-rasm):** Videoni GOP ga hizalangan bo'laklarga bo'lish. Nosozlik bo'lganda tez qayta boshlanadigan yuklashni ta'minlaydi. Mijoz bo'lishni boshqaradi (23-rasm).

**Tezlik — foydalanuvchilarga yaqin yuklash markazlari (24-rasm):** Yuklash markazlari sifatida CDN dan foydalanib global ko'plab yuklash markazlari (Shimoliy Amerika, Osiyo va hokazo).

**Tezlik — hamma joyda parallellik (25-rasm, 26-rasm):** Ketma-ket oqim (25-rasm) parallellikni qiyinlashtiradi. Xabar navbatlari kiritilgandan so'ng (26-rasm), kodlash moduli yuklab olish modulini kutmaydi — navbatdagi hodisalar mustaqil ravishda qayta ishlanishi mumkin.

**Xavfsizlik — oldindan imzolangan yuklash URL (27-rasm):** Oqim: 1. Mijoz API serverlardan oldindan imzolangan URL so'raydi. 2. API serverlar oldindan imzolangan URL qaytaradi. 3. Mijoz oldindan imzolangan URL yordamida videoni yuklaydi. (AWS buni pre-signed URL deb ataydi; Azure esa "Shared Access Signature" [10] deb ataydi)

**Xavfsizlik — video himoya variantlari:** - Raqamli huquqlarni boshqarish (DRM): Apple FairPlay, Google Widevine, Microsoft PlayReady. - Vakolat siyosati bilan AES shifrlash. - Vizual suv tamg'asi.

**Xarajat tejamlari (28-rasm):** YouTube uzun dumba taqsimotiga amal qiladi [11][12] — ozgina mashhur videolar ko'pchilik ko'rishni oladi. 1. Faqat eng mashhur videolarni CDN dan xizmat qilish; boshqalarni yuqori quvvatli saqlash serverlaridan. 2. Kam mashhur kontent talabga binoan kodlanadi (kamroq versiyalar saqlanadi). 3. Mintaqaviy mashhur videolar global taqsimlanmaydi. 4. Netflix kabi o'z CDN sini qurish va internet-provayderlar bilan hamkorlik qilish.

Xatolarni boshqarish

**Tiklanishi mumkin bo'lgan xatolar** (masalan, segment transkodlashda muvaffaqiyatsiz): bir necha marta qayta urinib ko'ring, keyin xato kodini qaytaring. **Tiklanishi mumkin bo'lmagan xatolar** (masalan, noto'g'ri video): vazifalarni to'xtatib xato kodini qaytaring.

**Komponent bo'yicha xatolar yo'riqnomasi:** - Yuklash xatosi: qayta urinib ko'ring. - Video bo'lish xatosi: eski mijoz bo'lshni qo'llab-quvvatlamasa, server bo'lishni boshqaradi. - Transkodlash xatosi: qayta urinib ko'ring. - Preprocessor xatosi: DAG ni qayta yarating. - DAG rejalashtiruvchi xatosi: vazifani qayta rejalashtiring. - Resurs menejeri navbati o'chib qolsa: replikadan foydalaning. - Vazifa workeri o'chib qolsa: yangi workerda qayta urinib ko'ring. - API server o'chib qolsa: boshqa holatsiz API serverga yo'naltiring. - Metadata keshi o'chib qolsa: replikalardan o'qing; yangi kesh server yoqing. - Metadata MB master o'chib qolsa: slave ni mastergа aylantiring. - Metadata MB slave o'chib qolsa: boshqa slavdan foydalaning; almashtirishni yoqing.

4-qadam - Yakunlash

**Qo'shimcha muhokama nuqtalari:** - **API qatlamini kengaytirish:** Holatsiz API serverlar gorizontal ravishda kengayadi. - **Ma'lumotlar bazasini kengaytirish:** Replikatsiya va sharding. - **Jonli oqim:** Yuqori kechikish talablari, farqli oqim protokoli, kamroq parallellik (real vaqtda kichik bo'laklar), farqli xatolarni boshqarish. - **Video olib tashlash:** Mualliflik huquqi buzilishlari, pornografiya, noqonuniy kontentni olib tashlash — yuklash paytida yoki foydalanuvchi shikoyatlari orqali aniqlanadi.

Ushbu bobda sizdan Google Drive — hujjatlar, fotosuratlar, videolar va boshqa fayllarni bulutda saqlab, har qanday kompyuter, smartfon va planshetdan kirish imkonini beradigan fayl saqlash va sinxronizatsiya xizmatini loyihalash so'raladi.

1-qadam - Muammoni tushunish va dizayn doirasini belgilash

**Doiradagi xususiyatlar:** - Fayl qo'shish (sudrab tashlash). - Fayllarni yuklab olish. - Bir nechta qurilmada fayllarni sinxronlashtirish. - Fayl versiyalarini ko'rish. - Do'stlar, oila va hamkasblar bilan fayl ulashish. - Fayl tahrirlanganda, o'chirilganda yoki ulashilganda bildirishnomalar yuborish.

**Doiradan tashqari:** Google Docs tahrirlash va hamkorlik.

**Talablar:** - Har qanday fayl turi; fayllar shifrlanishi kerak. - Maksimal fayl hajmi: 10 GB. - 10M DAU.

**Funksional bo'lmagan talablar:** - Ishonchlilik: ma'lumot yo'qolishi qabul qilinmaydi. - Tez sinxronlash tezligi. - Minimal o'tkazuvchanlik foydalanishi. - Kengayuvchan va yuqori mavjudlikli.

**Taxminiy hisob-kitob:** - 50M foydalanuvchi × 10 GB bepul = **jami 500 PB saqlash** - Yuklash QPS: 10M × 2 yuklash / 86400 ≈ **240 QPS** (cho'qqi: 480)

2-qadam - Yuqori darajali dizayn taklif qilish va kelishuv olish

Bitta server sozlamasidan boshlash va keyin kengaytirish: - Fayllarni yuklash/yuklab olish uchun veb-server. - Metadata uchun MySQL ma'lumotlar bazasi (foydalanuvchi ma'lumotlari, login, fayllar). - Ildiz saqlash sifatida `drive/` katalogi (1 TB).

`drive/` ostida kataloglar (nomlar maydoni) ro'yxati — har bir nomlar maydoni foydalanuvchining barcha yuklangan fayllarini o'z ichiga oladi. Fayllar nomlar maydoni va nisbiy yo'lni birlashtirish orqali noyob tarzda aniqlanadi.

3-rasm `drive/` katalog tuzilishini ko'rsatadi.

API'lar

Uchta asosiy API:

**1. Fayl yuklash:** - Oddiy yuklash: kichik fayllar. - Qayta boshlanadigan yuklash: katta fayllar yoki ishonchsiz tarmoqlar. ``` POST https://api.example.com/files/upload?uploadType=resumable Parametrlar: uploadType=resumable, data: mahalliy fayl ``` Qayta boshlanadigan yuklash qadamlari: dastlabki so'rovni yuborish → qayta boshlanadigan URL ni olish → ma'lumotlarni yuklash va monitoring qilish → buzilganda davom ettirish.

**2. Fayl yuklab olish:** ``` GET https://api.example.com/files/download Parametrlar: path: yuklab olish fayl yo'li ```

**3. Fayl versiyalarini olish:** ``` GET https://api.example.com/files/list_revisions Parametrlar: path, limit ```

Barcha API'lar foydalanuvchi autentifikatsiyasini talab qiladi va HTTPS/SSL ishlatadi.

Bitta serverdan uzoqlashish

Ko'proq fayl yuklanishi bilan saqlash to'ladi (4-rasm). Yechim: ma'lumotlarni bir nechta saqlash serverlarga shardlash (5-rasm — user_id bo'yicha shardlash).

Ma'lumot yo'qolishidan himoya qilish uchun Amazon S3 dan foydalanish — bir xil mintaqa va mintaqalararo replikatsiyani qo'llab-quvvatlaydi (6-rasm). Bir nechta mintaqada replikalangan ma'lumotlar mavjudlik va barqarorlikni ta'minlaydi.

Qo'shimcha yaxshilanishlar: - **Yukni muvozanatlashtirgich:** Trafikni taqsimlash; veb-server o'chib qolganda qayta taqsimlash. - **Ko'proq veb-serverlar:** Yukni muvozanatlashtirgich qo'shilgandan so'ng oson kengaytirish. - **Metadata ma'lumotlar bazasi:** Bitta serverdan chiqarish; replikatsiya va shardingi sozlash. - **Fayl saqlash:** Ikkita geografik mintaqada replikatsiya bilan S3.

7-rasm ajratilgan veb-serverlar, metadata ma'lumotlar bazasi va fayl saqlash bilan yangilangan dizaynni ko'rsatadi.

Sinxronlash ziddiyatlari

Ikkita foydalanuvchi bir vaqtda bir xil faylni o'zgartirganda ziddiyat yuzaga keladi. **Strategiya: avval qayta ishlangan versiya g'alaba qiladi; keyingi versiya ziddiyat oladi (8-rasm).**

2-foydalanuvchi sinxronlash ziddiyatini oladi. Tizim ikkala nusxani ko'rsatadi — 2-foydalanuvchining mahalliy nusxasi va so'nggi server versiyasi (9-rasm). 2-foydalanuvchi ikkala faylni birlashtirishi yoki bitta versiyani boshqasiga almashtirishi mumkin.

Yuqori darajali dizayn

10-rasm komponentlar bilan taklif qilingan yuqori darajali dizaynni ko'rsatadi:

- **Foydalanuvchi:** Brauzer yoki mobil ilovadan foydalanadi. - **Blok serverlar:** Bulut saqlashga bloklar yuklaydi. Fayllar bloklarga bo'linadi (Dropbox [6] kabi maksimal 4 MB har biri), har birining noyob xesh qiymati bor. Faylni qayta tiklash uchun bloklar tartibda birlashtiriladi. - **Bulut saqlash:** Fayl bloklari S3 da saqlanadi. - **Sovuq saqlash:** Faol bo'lmagan ma'lumotlar uchun (oylar/yillar davomida kirilmagan fayllar). - **Yukni muvozanatlashtirgich:** So'rovlarni API serverlar o'rtasida taqsimlaydi. - **API serverlar:** Foydalanuvchi autentifikatsiyasi, profil boshqarish, metadata yangilash. - **Metadata ma'lumotlar bazasi:** Foydalanuvchilar, fayllar, bloklar, versiyalarning metadata ni saqlaydi. - **Metadata keshi:** Tez-tez kiriladigan metadata ni keshlaydi. - **Bildirishnoma xizmati:** Nashriyot/obuna tizimi — fayl boshqa joyda qo'shilganda/tahrirlanganda/olib tashlanganda mijozlarni xabardor qiladi. - **Oflayn zahira navbati:** Oflayn mijozlar uchun kutilayotgan o'zgarishlarni saqlaydi; mijoz onlayn bo'lganda sinxronlanadi.

3-qadam - Chuqur dizayn

Chuqur tahlil: blok serverlar, metadata ma'lumotlar bazasi, yuklash oqimi, yuklab olish oqimi, bildirishnoma xizmati, saqlashni tejash, nosozliklarni boshqarish.

Blok serverlar

O'tkazuvchanlikni minimallashtirish uchun ikkita optimallashtirish:

1. **Delta sinx:** Butun fayl o'rniga faqat o'zgartirilgan bloklar sinxronlanadi [7][8]. 2. **Siqish:** Faylga qarab turli algoritmlar bilan bloklar siqiladi (matn uchun gzip/bzip2; rasmlar/videolar uchun turli algoritmlar).

Yangi fayl uchun blok server ish jarayoni (11-rasm): 1. Fayl kichikroq bloklarga bo'linadi. 2. Har bir blok siqiladi. 3. Bulut saqlashga yuborishdan oldin har bir blok shifrlanadi. 4. Bloklar bulut saqlashga yuklanadi.

Delta sinx uchun (12-rasm): faqat o'zgartirilgan bloklar ("block 2" va "block 5") bulut saqlashga yuklanadi.

Yuqori izchillik talabi

Kuchli izchillik talab etiladi — fayl turli mijozlar tomonidan bir vaqtda farqli ko'rsatilmasligi kerak.

- Xotira keshlari sukut bo'yicha yakuniy izchillikni qabul qiladi — kesh replikalari va masterning izchil ekanligini ta'minlash kerak. - Ma'lumotlar bazasiga yozishda keshlarni bekor qilish. - ACID xossalari (Atomiklik, Izchillik, Izolyatsiya, Barqarorlik) mahalliy qo'llab-quvvatlanadi [9] sababli **relyatsion ma'lumotlar bazalarini** tanlaymiz. NoSQL ma'lumotlar bazalari sukut bo'yicha ACID ni qo'llab-quvvatlamaydi.

Metadata ma'lumotlar bazasi

13-rasm ma'lumotlar bazasi sxemasini ko'rsatadi (soddalashtirilgan):

- **Foydalanuvchi:** foydalanuvchi nomi, elektron pochta, profil foto. - **Qurilma:** qurilma ma'lumoti, mobil push bildirishnomalar uchun push_id. Bir foydalanuvchida bir nechta qurilma bo'lishi mumkin. - **Nomlar maydoni:** Foydalanuvchining ildiz katalogi. - **Fayl:** So'nggi fayl ma'lumoti. - **Fayl_versiyasi:** Versiya tarixi. Yaxlitlikni saqlash uchun mavjud satrlar faqat o'qish uchun. - **Blok:** Fayl bloki haqida hamma narsa. Har qanday versiya bloklarni to'g'ri tartibda birlashtirish orqali qayta tiklanadi.

Yuklash oqimi

14-rasm fayl yuklash uchun ketma-ketlik diagrammasini ko'rsatadi. 1-mijozdan ikkita parallel so'rov:

**Fayl metadata qo'shish:** 1. 1-mijoz metadata qo'shish uchun so'rov yuboradi. 2. Metadata MB da holatini "kutilmoqda" sifatida saqlash. 3. Yangi fayl haqida bildirishnoma xizmatini xabardor qilish. 4. Bildirishnoma xizmati 2-mijozni xabardor qiladi.

**Faylni bulut saqlashga yuklash:** 2.1 1-mijoz kontentni blok serverlariga yuklaydi. 2.2 Blok serverlar bloklar va siqib, shifrlab, bulut saqlashga yuklaydi. 2.3 Bulut saqlash API serverlarga yuklash yakunlanishi qo'ng'irog'ini yuboradi. 2.4 Metadata MB da fayl holati "yuklandi" ga o'zgartiriladi. 2.5-2.6 Bildirishnoma xizmati 2-mijozni fayl to'liq yuklanganligini xabardor qiladi.

Yuklab olish oqimi

Mijoz fayl o'zgarganligini quyidagi orqali biladi: - **Onlayn:** Bildirishnoma xizmati mijozni o'zgarishlar haqida xabardor qiladi. - **Oflayn:** Ma'lumotlar keshga saqlanadi; mijoz yana onlayn bo'lganda tortib olinadi.

15-rasm yuklab olish oqimini ko'rsatadi: 1. Bildirishnoma xizmati 2-mijozni o'zgarish haqida xabardor qiladi. 2. 2-mijoz API serverlardan metadata so'raydi. 3-4. API serverlar metadata MB dan metadata olib keladi. 5. 2-mijoz metadata qabul qiladi. 6. 2-mijoz blok serverlardan bloklar so'raydi. 7-8. Blok serverlar bulut saqlashdan bloklar yuklab oladi. 9. 2-mijoz bloklarni yuklab olib faylni qayta tiklaydi.

Bildirishnoma xizmati

Variantlar: **Uzun polling** (Dropbox tomonidan ishlatiladi [10]) vs **WebSocket**.

Quyidagi sabablar bilan **uzun polling** tanlaymiz: - Muloqot bir yo'nalishli (server → fayl o'zgarishlari uchun mijoz). - Google Drive bildirisinomalari chat kabi real vaqtli oqimlarga qaraganda kamdan-kam, doimiy emas.

Uzun polling bilan, har bir mijoz uzun polling ulanishini o'rnatadi. Fayl o'zgarishi aniqlanganda, mijoz ulanishni yopadi, metadata serverdan so'nggi o'zgarishlarni olib keladi, keyin darhol ulanishni qaytadan ochadi.

Saqlash joyini tejash

Saqlash xarajatlarini kamaytirish uchun uchta usul:

1. **Ma'lumotlar bloklarini dublikatdan chiqarish:** Ikkita blok bir xil xesh qiymatiga ega bo'lsa bir xil — hisob darajasida ortiqcha bloklarni yo'qotish. 2. **Aqlli zahira strategiyasi:** - Saqlash uchun versiyalar soniga chegara o'rnatish. - Faqat qimmatli versiyalarni saqlash (ko'p o'zgartirilgan fayllarni cheklash). 3. **Kam kiriladigan ma'lumotlar uchun sovuq saqlash:** Amazon S3 Glacier [11] S3 ga qaraganda ancha arzon.

Nosozliklarni boshqarish

- **Yukni muvozanatlashtirgich nosozligi:** Ikkilamchi faol bo'ladi; yukni muvozanatlashtirgichlar o'rtasida yurak urishi monitoring. - **Blok server nosozligi:** Boshqa serverlar tugallanmagan/kutilayotgan ishlarni oladi. - **Bulut saqlash nosozligi:** S3 chelaklar turli mintaqalarda replikalangan; boshqa mintaqadan olib kelish. - **API server nosozligi:** Holatsiz; trafik yukni muvozanatlashtirgich tomonidan qayta yo'naltiriladi. - **Metadata keshi nosozligi:** Replikalangan; muvaffaqiyatsiz uni almashtirish uchun yangi server yoqish. - **Metadata MB nosozligi:** - Master o'chsa: slave ni mastergа aylantirish, yangi slave yoqish. - Slave o'chsa: boshqa slavdan foydalanish; almashtirish yoqish. - **Bildirishnoma xizmati nosozligi:** Mashinada 1M dan ortiq ulanish (Dropbox 2012 bo'yicha [6]). Nosozlik bo'lganda, barcha uzun polling ulanishlari yo'qoladi; mijozlar sekin qayta ulanishi kerak. - **Oflayn zahira navbati nosozligi:** Navbatlar replikalangan; iste'molchilar zahira navbatiga qayta obuna bo'ladi.

4-qadam - Yakunlash

Google Drive ni ikkita oqim bilan loyihalashtirildi: fayl metadata boshqaruvi va fayl sinxi. Bildirishnoma xizmati mijozlarni yangilangan holda saqlash uchun uzun polling dan foydalanadi.

**Muqobil dizayn muhokamasi:** - Fayllarni to'g'ridan-to'g'ri mijozdan bulut saqlashga yuklash (blok serverlarni chetlab o'tish): tezroq, lekin har bir mijoz platformasida bo'laklash/siqish/shifrlash mantig'ini talab qiladi (xatoga moyil, qo'llab-quvvatlash qiyinroq), va mijoz tomonida shifrlash xavfsizlik xavfi. - **Mavjudlik xizmati:** Onlayn/oflayn mantig'ini alohida xizmatga ko'chirish — yaxshiroq modulyarlik va boshqa xizmatlar tomonidan qayta foydalanish uchun.

Yaqinlik xizmati restoranlar, mehmonxonalar, kinoteatrlar, muzeylar va boshqalar kabi yaqin atrofdagi joylarni topish uchun ishlatiladi. U Yelp da eng yaqin restoranlarni topish yoki Google Maps da k-ta eng yaqin yoqilg'i stantsiyasini topish kabi xususiyatlarni quvvatlaydi.

1-qadam - Muammoni Tushunish va Dizayn Doirasini Belgilash

**Funksional talablar:** - Foydalanuvchi joylashuvi (kenglik/uzunlik) va radius asosida barcha bizneslarni qaytarish. - Biznes egalari biznes qo'shishi, o'chirishi yoki yangilashi mumkin (real vaqtda emas; keyingi kun kuchga kiradi). - Mijozlar biznes haqida batafsil ma'lumotni ko'rishi mumkin.

**Funksional bo'lmagan talablar:** - Past kechikish: foydalanuvchilar yaqin biznesllarni tezda ko'rishi kerak. - Ma'lumotlar maxfiyligi: GDPR [4] va CCPA [5] ga muvofiq. - Yuqori mavjudlik va kengayuvchanlik: gavjum hududlarda cho'qqi soatlarida trafik portlashlarini boshqarish.

**Taxminiy hisob-kitob:** - 100 million DAU, 200 million biznes. - Qidiruv QPS = 100M × kuniga 5 qidiruv ÷ 10^5 soniya = **5,000 QPS**

2-qadam - Yuqori Darajali Dizayn Taklif Qilish va Kelishuv Olish

API Dizayni

**Yaqin biznesllarni qidirish:** ``` GET /v1/search/nearby Parametrlar: latitude, longitude, radius (standart 5000m) Javob: { total: 10, businesses: [{biznes ob'ekti}] } ```

**Biznes CRUD API'lari:**

| API | Batafsil | |-----|--------| | GET /v1/businesses/{:id} | Biznes haqida batafsil ma'lumotni qaytarish | | POST /v1/businesses | Biznes qo'shish | | PUT /v1/businesses/{:id} | Biznes tafsilotlarini yangilash | | DELETE /v1/businesses/{:id} | Bizneni o'chirish |

Ma'lumotlar modeli

Past yozish hajmli ko'p o'qiladigan tizim (qidiruv + ko'rish). Relyatsion ma'lumotlar bazasi (MySQL) yaxshi mos keladi.

**Biznes jadvali (3-jadval):** `business_id` birlamchi kalit sifatida batafsil biznes ma'lumotlarini o'z ichiga oladi.

Yuqori darajali dizayn

2-rasm ikkita qismli tizimni ko'rsatadi: Joylashuvga Asoslangan Xizmat (LBS) va biznes xizmati.

- **Yukni muvozanatlashtirgich:** Trafikni taqsimlaydi; URL yo'llariga asosan API qo'ng'iroqlarini yo'naltiradi. - **LBS (Joylashuvga Asoslangan Xizmat):** Yaqin biznesllarni topuvchi asosiy komponent. Ko'p o'qiladigan, yuqori QPS, holatsiz (gorizontal kengayish oson). - **Biznes xizmati:** Yozish operatsiyalarini (qo'shish/yangilash/o'chirish) va batafsil biznes ma'lumotlarini o'qishni boshqaradi. - **Ma'lumotlar bazasi klasteri:** Primary-secondary sozlama. Primary yozishlarni boshqaradi; replikalar o'qishlarni boshqaradi. Kichik replikatsiya kechikishi qabul qilinadi (biznes ma'lumoti real vaqtda emas).

Yaqin biznesllarni olish algoritmlari

**1-variant: Ikki o'lchovli qidiruv (3-rasm):** Oldindan belgilangan radius bilan doira chizish, undagi barcha biznesllarni topish. Kenglik/uzunlik BETWEEN ishlatadigan SQL — to'liq jadval skanini talab qiladi. Ikkala ustunda indekslar bo'lsa ham (4-rasm), ikkita katta ma'lumotlar to'plamini kesish samarasiz.

**Geofazoviy indekslash turlari (5-rasm):** - Xesh: bir xil to'r, geohash, dekart qatlamlari. - Daraxt: kvadro-daraxt, Google S2, R-daraxt.

**2-variant: Bir xil bo'lingan to'r (6-rasm):** Dunyoni teng to'rlarga bo'lish. Muammo: notekis biznes taqsimoti — Nyu-York markazi vs cho'l/okeanlar.

**3-variant: Geohash** 2D koordinatalarni 1D satrga kamaytiradi. Har qo'shimcha bit bilan dunyoni rekursiv ravishda kichikroq to'rlarga bo'ladi.

Geohash bo'linishi: - Sayyorani to'rt qismga bo'lish (7-rasm). - Har bir to'r rekursiv ravishda 4 ga bo'linadi (8-rasm). - Base32 ifodalanishidan foydalanadi.

Geohash uzunligi va to'r hajmi (4-jadval): uzunlik 4 = 39.1×19.5km, uzunlik 5 = 4.9×4.9km, uzunlik 6 = 1.2km×609m.

Radius va geohash uzunligi (5-jadval): 0.5km→6, 1km→5, 2km→5, 5km→4, 20km→4.

**Chegara muammolari:** - 1-muammo (9-rasm, 10-rasm): Ikki yaqin joylashuv UMUMIY prefiks bo'lmasligi mumkin (masalan, ekvatorning qarama-qarshi tomonlari). Oddiy prefiks so'rovi muvaffaqiyatsiz bo'ladi. - 2-muammo (11-rasm): Ikki pozitsiya uzun umumiy prefiksga ega, lekin turli geohash larga tegishli. - Yechim: joriy to'r va barcha 8 qo'shnilardan biznesllarni olish.

**Yetarli biznes yo'q (12-rasm):** Kattaroq to'rga kengaytirish uchun geohashning oxirgi raqamini olib tashlash; yetarli natijalar bo'lguncha takrorlash.

**4-variant: Kvadro-daraxt (13-rasm):** To'rda ≤100 biznes bo'lguncha 2D maydonni rekursiv ravishda 4 kvadrantga bo'lish. Server ishga tushirishda quriladigan xotiradagi tuzilma.

Qurish jarayoni (14-rasm): - Umumiy xotira: 200M biznes uchun ~1.71 GB. - Qurilish vaqti: ishga tushirishda bir necha daqiqa; xizmat uzilishini oldini olish uchun bosqichma-bosqich joylashtirish.

Denver yaqinidagi haqiqiy dunyo kvadro-daraxti misoli (15-rasm): gavjum hududlar uchun kichikroq to'rlar, siyrak uchun kattaroq.

**5-variant: Google S2 (16-rasm):** Hilbert egri chizig'i orqali sferani 1D indeksga xaritalaydi. Hilbert egri chizig'ida yaqin ikkita nuqta 1D da ham yaqin. Geofencing ni qo'llab-quvvatlaydi (17-rasm) — perimetrlar belgilab, tashqaridagi foydalanuvchilarga bildirishnomalar yuborish.

**Tavsiya:**

| Geo Indeks | Kompaniyalar | |-----------|----------| | Geohash | Bing map, Redis, MongoDB, Lyft | | Kvadro-daraxt | Yext | | Ikkalasi | Elasticsearch | | S2 | Google Maps, Tinder |

Interv'yular uchun geohash yoki kvadro-daraxtni tanlang (S2 tushuntirish uchun juda murakkab).

**Geohash va Kvadro-daraxt:** - Geohash: foydalanish/amalga oshirish oson; radius qidiruvini qo'llab-quvvatlaydi; doimiy to'r hajmi; indeksni yangilash oson (18-rasm). - Kvadro-daraxt: k-ta eng yaqin qidiruvni qo'llab-quvvatlaydi; zichlikka asoslan to'r hajmini dinamik sozlaydi; amalga oshirish va yangilash murakkabroq (O(log n) kesib o'tish, 19-rasm).

3-qadam - Chuqur Dizayn

Ma'lumotlar bazasini kengaytirish

**Biznes jadvali:** Teng yuk taqsimoti uchun business_id bo'yicha shardlash.

**Geofazoviy indeks jadvali (geohash):** Ikki xil saqlash varianti: - 1-variant: `geohash → business_id lar JSON massivi` (geohash boshiga bitta satr). - 2-variant: `(geohash, business_id)` birlashtirilgan kalit — biznes boshiga bitta satr (9-jadval, 10-jadval).

**Tavsiya: 2-variant** — qulflamasdan oddiy qo'shish/o'chirish, takroriy skanerlashga hojat yo'q.

**Geofazoviy indeksni kengaytirish:** To'liq ma'lumotlar to'plami kichik (~kvadro-daraxt uchun 1.71 GB). Shardlash o'rniga o'qish replikalaridan foydalanish (ishlab chiqish va qo'llab-quvvatlash oddiyroq).

Keshlash

Kesh mulohazalari: ish yuki ko'p o'qish, lekin ma'lumotlar to'plami nisbatan kichik — MB ishchi to'plamiga allaqachon sig'ishi mumkin. Avval o'qish replikalarini qo'shing; benchmarking kerakligini ko'rsatsa kesh qo'shing.

**Kesh kaliti:** Joylashuv koordinatalari ishonchli emas (GPS aniqligi pastligi, kichik harakat). Geohash ni kesh kaliti sifatida ishlating — kichik joylashuv o'zgarishlari bir xil geohash ga xaritalanadi.

**Ikki turdagi kesh qilingan ma'lumotlar (12-jadval):** 1. `geohash → biznes ID lari ro'yxati` — har bir geohash aniqligi uchun oldindan hisoblanadi (4, 5, 6). Jami: ~5 GB (8 bayt × 200M biznes × 3 aniqlik). 2. `business_id → biznes ob'ekti` — ko'rsatish uchun to'ldirilgan biznes ma'lumotlari.

Past kechikish uchun Redis keshini global miqyosda joylashtiring (bir xil nusxa).

Mintaqa va mavjudlik zonalari

LBS ni bir nechta mintaqa va mavjudlik zonalariga joylashtiring (20-rasm): - Foydalanuvchilarni tizimga jismonan yaqinlashtiradi. - Moslashuvchan yuk taqsimoti (Yaponiya/Koreya yuqori aholi zichligiga ega). - Maxfiylik qonunlariga muvofiqlik (ba'zi mamlakatlar ma'lumotlarni mahalliy saqlashni talab qiladi).

Yakuniy dizayn diagrammasi

21-rasm yakuniy dizaynni ko'rsatadi.

**Yaqin biznesllarni olish oqimi:** 1. Mijoz yukni muvozanatlashtirgichga joylashuv (kenglik/uzunlik) va radius (masalan, 500m) yuboradi. 2. Yukni muvozanatlashtirgich LBS ga yo'naltiradi. 3. LBS 500m radius uchun geohash uzunligini qidiradi → uzunlik 6. 4. LBS qo'shni geohashlarni hisoblaydi (8 qo'shni + o'zi). 5. LBS "Geohash" Redis keshidan har bir geohash uchun parallel ravishda biznes ID larini oladi. 6. LBS "Biznes ma'lumoti" Redis keshidan to'ldirilgan biznes ob'ektlarini oladi, masofalarni hisoblaydi, tartiblaydi va natijalarni qaytaradi.

**Biznes ko'rish/yangilash/qo'shish/o'chirish:** - Biznes xizmati avval "Biznes ma'lumoti" Redis keshini tekshiradi. - Kesh o'tkazib yuborilsa → ma'lumotlar bazasidan olib kelish va natijani keshlash. - Keshlanangan biznes ma'lumotlari tungi ish tomonidan yangilanadi (yangi/yangilangan biznesllar keyingi kun kuchga kiradi).

4-qadam - Yakunlash

Geofazoviy indekslash (geohash) yordamida yaqinlik xizmatini loyihalashtirildi. Ko'rib chiqilgan asosiy mavzular: - Beshta indekslash varianti: 2D qidiruv, bir xil to'r, geohash, kvadro-daraxt, Google S2. - Geohash ni kesh kaliti sifatida ishlatib keshlash. - O'qish replikalari orqali ma'lumotlar bazasini kengaytirish. - Mavjudlik va muvofiqlik uchun ko'p mintaqali joylashtirish.

"Yaqin Do'stlar" xususiyati uchun kengayuvchan backend loyihalashtiramiz. Ixtiyoriy ravishda yoqgan foydalanuvchi uchun mobil mijoz geografik jihatdan yaqin do'stlar ro'yxatini ko'rsatadi. Biznes joylashuvlari statik bo'lgan yaqinlik xizmatlaridan farqli o'laroq, foydalanuvchi joylashuvlari tez-tez o'zgaradi — bu dinamik, real vaqtli dizaynni talab qiladi.

1-qadam - Muammoni Tushunish va Dizayn Doirasini Belgilash

**Funksional talablar:** - Foydalanuvchilar mobil ilovalarida yaqin do'stlarni ko'radi. - Har bir yozuv masofani va so'nggi yangilanish vaqt tamg'asini ko'rsatadi. - Yaqin do'stlar ro'yxati bir necha soniyada yangilanadi. - "Yaqin" = 5 milya ichida (sozlanuvchi). - 10+ daqiqa faol bo'lmagan do'stlar ro'yxatdan yo'qoladi. - Joylashuv tarixini saqlash.

**Funksional bo'lmagan talablar:** - Joylashuv yangilanishlari uchun past kechikish. - Ishonchlilik (vaqti-vaqti bilan ma'lumotlar nuqtasi yo'qolishi qabul qilinadi). - Yakuniy izchillik (bir necha soniya kechikish qabul qilinadi).

**Taxminiy hisob-kitob:** - 1 milliard foydalanuvchi; 10% yaqin do'stlardan foydalanadi = 100M DAU. - 10% bir vaqtdagi foydalanuvchilar = 10M bir vaqtda. - Joylashuv yangilash intervali: 30 soniya. - O'rtacha 400 do'st, 10% onlayn va yaqin. - **Joylashuv yangilash QPS = 10M / 30 ≈ 334,000 QPS** - Yo'naltirish QPS = 334K × 400 × 10% = **sekundiga 14M joylashuv yangilanishi**

2-qadam - Yuqori Darajali Dizayn Taklif Qilish va Kelishuv Olish

Yuqori darajali dizayn

Kontseptual jihatdan, foydalanuvchi barcha yaqin faol do'stlarga peer-to-peer ulanishlarni saqlashi mumkin (2-rasm) — mobil qurilmalar uchun amaliy emas (beqaror ulanishlar, energiya sarfi).

Umumiy backend (3-rasm) quyidagilarni boshqaradi: - Barcha faol foydalanuvchilardan joylashuv yangilanishlarini qabul qilish. - Har bir yangilanishni radius ichidagi barcha faol do'stlarga yo'naltirish. - Chegara undan oshgan do'stlar uchun yangilanishlarni rad etish.

4-rasm quyidagi komponentlar bilan taklif qilingan dizaynni ko'rsatadi:

- **Yukni muvozanatlashtirgich:** Trafikni RESTful API serverlar va WebSocket serverlar bo'ylab taqsimlaydi. - **RESTful API serverlar:** Yordamchi vazifalar uchun holatsiz HTTP serverlar (do'st qo'shish/o'chirish, profil yangilash). - **WebSocket serverlar:** Holatlı, ikki yo'nalishli. Har bir mijoz bitta doimiy WebSocket ulanishini saqlaydi. Deyarli real vaqtdagi joylashuv yangilanishlarini boshqaradi va mijozni barcha yaqin onlayn do'stlarning joylashuvlari bilan initsializatsiya qiladi. - **Redis joylashuv keshi:** TTL bilan har faol foydalanuvchi uchun eng so'nggi joylashuvni saqlaydi. TTL har yangilanishda yangilanadi; muddati o'tgan = foydalanuvchi faol emas. - **Foydalanuvchi ma'lumotlar bazasi:** Foydalanuvchi ma'lumotlari va do'stlik ma'lumotlari (relyatsion yoki NoSQL). - **Joylashuv tarixi ma'lumotlar bazasi:** Tarixiy joylashuv ma'lumotlari (yaqin do'stlar xususiyati tomonidan to'g'ridan-to'g'ri ishlatilmaydi). - **Redis pub/sub server:** Engil xabar avtobusligi. Har bir foydalanuvchining o'z kanali bor. WebSocket boshqaruvchilari do'stlarining kanallariga obuna bo'ladi va joylashuv yangilanishlarini qabul qiladi.

Davriy joylashuv yangilanishi

7-rasm davriy joylashuv yangilanishi oqimini ko'rsatadi: 1. Mobil mijoz doimiy WebSocket ulanishi orqali joylashuv yangilanishini yuboradi. 2. Yukni muvozanatlashtirgich mijozning WebSocket serveriga yo'naltiradi. 3. WebSocket server joylashuv tarixi ma'lumotlar bazasiga saqlaydi. 4. WebSocket server Redis joylashuv keshini yangilaydi (TTL ni yangilaydi); joylashuvni ulanish boshqaruvchisi o'zgaruvchisida saqlaydi. 5. WebSocket server Redis pub/sub dagi foydalanuvchi kanaliga yangi joylashuvni nashr qiladi. 6. Redis pub/sub barcha obunachilarga (do'stlarning WebSocket ulanish boshqaruvchilariga) tarqatadi. 7. Har bir qabul qiluvchi WebSocket boshqaruvchisi yangilanish jo'natuvchisi va obunachi o'rtasidagi masofani hisoblaydi. 8. Agar masofa ≤ qidiruv radiusi bo'lsa, joylashuv + vaqt tamg'asini obunachi mijoziga yuborish. Aks holda, rad etish.

8-rasm 1-6-foydalanuvchilar bilan aniq misolni ko'rsatadi.

API dizayni

**WebSocket API'lari:** 1. Davriy joylashuv yangilanishi: kenglik, uzunlik, vaqt tamg'asini yuborish. 2. Joylashuv yangilanishlarini qabul qilish: do'st joylashuv ma'lumotlari + vaqt tamg'asini qabul qilish. 3. WebSocket initsializatsiyasi: joylashuvni yuborish; barcha yaqin do'stlarning joylashuvlarini qabul qilish. 4. Yangi do'stga obuna bo'lish: friend_id yuborish; so'nggi joylashuvni qabul qilish. 5. Do'stdan obunani bekor qilish: friend_id yuborish.

**Ma'lumotlar modeli:** - **Joylashuv keshi (Redis):** TTL bilan `user_id → {latitude, longitude, timestamp}`. - Redis tez o'qish/yozish, TTL qo'llab-quvvatlashi, barqaror saqlashga muhtoj emasligi uchun tanlangan. - **Joylashuv tarixi ma'lumotlar bazasi (Cassandra):** `user_id, latitude, longitude, timestamp`. - Ko'p yozuv ish yuki; user_id bo'yicha shardlash orqali gorizontal kengayuvchan.

3-qadam - Chuqur Dizayn

WebSocket serverlarini kengaytirish

WebSocket serverlar holatlı — tugunni olib tashlashdan oldin yukni muvozanatlashtirgichda "bo'shatilmoqda" deb belgilash (unga yangi ulanishlar yo'naltirilmaydi). Mavjud ulanishlar yopilgandan so'ng serverni olib tashlash.

**Mijozni initsializatsiya qilish:** WebSocket ulanishi boshlanganda: 1. Redis keshida foydalanuvchi joylashuvini yangilash. 2. Joylashuvni ulanish boshqaruvchisi o'zgaruvchisida saqlash. 3. Foydalanuvchi ma'lumotlar bazasidan barcha do'stlarni yuklash. 4. Redis keshidan joylashuvlarni toplu olish. 5. Radius ichidagi har bir do'st uchun profil, joylashuv, vaqt tamg'asini mijozga qaytarish. 6. Barcha do'stlarning pub/sub kanallariga obuna bo'lish (hatto faol bo'lmaganlar ham — ular CPU ishlatmaydi, minimal xotira). 7. Foydalanuvchining joriy joylashuvini o'zining pub/sub kanaliga nashr qilish.

Redis pub/sub serverlarini kengaytirish

**Xotira foydalanishi:** 100M kanal × 20 bayt × 100 do'st = ~200 GB jami. ~2 Redis server kerak (har biri 100 GB).

**CPU foydalanishi:** sekundiga 14M push ÷ server boshiga 100K push ≈ **140 Redis server** kerak.

Bottleneck xotira emas, CPU. Taqsimlangan Redis pub/sub klasteri kerak.

**Taqsimlangan pub/sub klasteri:** Izchil xeshlash yordamida yuzlab Redis serverlar bo'ylab kanallarni shardlash (9-rasm). Xesh halqasini saqlash va WebSocket serverlarni o'zgarishlar haqida xabardor qilish uchun xizmat kashfiyot komponentidan (etcd yoki Zookeeper) foydalanish.

10-rasm WebSocket serverning foydalanuvchi kanali uchun to'g'ri pub/sub serverni qanday topishini ko'rsatadi.

**Kengaytirish mulohazalari:** - Pub/sub kanallar holatsiz (xabarlar saqlanmaydi), lekin obunachi ro'yxatlari holatlı. - Pub/sub klasterni holatlı saqlash klasteri kabi muomala qilish — ehtiyotkorlik bilan kengaytirish. - Kunlik cho'qqini boshqarish uchun haddan ortiq ta'minlash. Faqat eng past foydalanish davrlarida o'lchamni o'zgartirish. - O'lchamni o'zgartirishda: xesh halqasi yangilanishi ommaviy qayta obuna bo'lishni keltirib chiqaradi — WebSocket CPU portlashini monitoring qilish.

**Muvaffaqiyatsiz pub/sub serverni almashtirish (11-rasm):** - Xizmat kashfiyotida muvaffaqiyatsiz olinni yangi tugun bilan almashtirish orqali xesh halqasini yangilash. - WebSocket serverlar ta'sirlangan kanallarni yangi serverga qayta obuna bo'ladi.

Yaqin tasodifiy shaxs (qo'shimcha)

Tasodifiy ixtiyoriy foydalanuvchilarni ko'rsatish uchun (nafaqat do'stlar): geohash bo'yicha pub/sub kanallar hovuzini qo'shing (12-rasm). To'r ichidagi har kim bir xil kanalga obuna bo'ladi.

13-rasm: 2-foydalanuvchi joylashuvni yangilasa, WebSocket boshqaruvchisi geohashni hisoblaydi va o'sha kanalga nashr qiladi. Barcha yaqin obunachillar (jo'natuvchi tashqari) yangilanishni qabul qiladi.

14-rasm: Har bir mijoz chegara holatlarini boshqarish uchun joriy geohash va 8 ta atrofdagi geohash to'rlarga obuna bo'ladi.

Redis pub/sub ga muqobil

**Erlang/Elixir (BEAM VM + OTP):** Bu muammo uchun yaxshiroq yechim. - Yengil Erlang jarayonlari (~300 bayt har biri) — har bir foydalanuvchini jarayon sifatida modellashtirish mumkin. - Zamonaviy serverlarda 10M jarayon oson. - OTP orqali mahalliy jarayonlararo xabar almashish va obuna. - Bitta foydalanuvchidan ko'plab do'stlarga yangilanishlarni samarali yo'naltirish uchun tarmoq hosil qiladi. - Ajoyib taqsimlangan operatsiyalar va nosozliklarni tuzatish vositalari. - Kelishuv: noyob texnologiya, uchun xodim topish qiyinroq.

4-qadam - Yakunlash

Asosiy komponentlar: WebSocket (real vaqt), Redis joylashuv keshi (TTL bilan tez o'qish/yozish), Redis pub/sub (yo'naltirish qatlami). Ko'rib chiqilgan asosiy muammolar: sekundiga 14M joylashuv yangilanishi, bo'shatish bilan holatlı WebSocket kengaytirish, izchil xeshlash bilan taqsimlangan pub/sub klasteri.

Google Maps ning soddalashtirilgan versiyasini loyihalashtiramiz — sun'iy yo'ldosh tasvirlari, ko'cha xaritalari, real vaqtdagi trafik holatlari va marshrut rejalashtirishni taqdim etuvchi veb xaritalash xizmati. 2021 yil mart holatiga ko'ra, Google Maps 1 milliard DAU, 99% dunyo qamrovi va kuniga 25 million yangilanishga ega edi. Ko'rib chiqiladigan xususiyatlar: joylashuvni yangilash, navigatsiya, taxminiy yetib kelish vaqti (ETA) va xaritani ko'rsatish. Ushbu bobdagi xarita plitkalari Stamen Design dan; ma'lumotlar OpenStreetMap dan.

1-qadam - Muammoni Tushunish va Dizayn Doirasini Belgilash

**Asosiy talablar:** - 1 milliard DAU. - Xususiyatlar: joylashuvni yangilash, navigatsiya, ETA va xaritani ko'rsatish. - Bir nechta sayohat rejimlarini qo'llab-quvvatlash (avtomobil, piyoda, avtobus). - Trafik holatlarini hisobga olish. - Ko'p to'xtashli yo'nalishlar yo'q, biznes joylari/fotosuratlar yo'q.

**Funksional bo'lmagan talablar:** - Aniqlik: foydalanuvchilarga noto'g'ri yo'nalish berilmasligi kerak. - Silliq navigatsiya: mijoz tomonida silliq xarita ko'rsatish. - Ma'lumotlar va batareya foydalanishi: mobil qurilmalar uchun minimallash. - Yuqori mavjudlik va kengayuvchanlik.

Xarita asoslari

**Joylashuv tizimi:** - Kenglik: shimolga yoki janubga qanchalik uzoq. - Uzunlik: sharqqa yoki g'arbga qanchalik uzoq.

1-rasm kenglik/uzunlik koordinata tizimini ko'rsatadi.

**3D dan 2D ga o'tish (Xarita Proyeksiyasi):** 3D globusdagi nuqtalarni 2D tekislikka tarjima qilish Xarita Proyeksiyasi deb ataladi. Har bir proyeksiya haqiqiy geometriyani buzadi. Google Maps Web Mercator (o'zgartirilgan Mercator proyeksiyasi) dan foydalanadi. 2-rasm bir nechta proyeksiya misollarini ko'rsatadi.

**Geokodlash:** Manzillarni geografik koordinatalarga aylantirish (va teskari geokodlash — kenglik/uzunlikni insonlar o'qiy oladigan manzilga qaytarish). Bir usul: GIS ma'lumotlari yordamida interpolyatsiya.

**Geohashing (3-rasm):** Geografik maydonni qisqa satrga kodlaydi. Yerni rekursiv ravishda kichik to'r katakchalarga bo'ladi. Dizaynimizda xarita plitkalash uchun ishlatiladi.

**Xaritani ko'rsatish:** Dunyo kichikroq plitkalarga bo'linadi. Mijoz joriy maydon/zum darajasi uchun faqat tegishli plitkalalarni yuklab oladi va ularni birlashtiradi. Turli zum darajalari uchun turli plitka to'plamlari mavjud — mijoz tegishli to'plamni tanlaydi.

**Navigatsiya algoritmlari uchun yo'l ma'lumotlarini qayta ishlash:** Yo'naltirish algoritmlari (Dijkstra, A*) kesishishlar tugunlar, yo'llar qirralar bo'lgan grafda ishlaydi (4-rasm). Dunyo grafasi xotira uchun juda katta — geohash asosidagi bo'linish orqali yo'naltirish plitkalarga bo'linadi. Har bir yo'naltirish plitka o'zining geografik hududi uchun tugunlar/qirralar va qo'shni plitkalara havolalarni o'z ichiga oladi. Ierarxik yo'naltirish plitkalari (3 daraja): mahalliy yo'llar (kichik plitka), asosiy yo'llar (o'rta plitka), asosiy magistrallar (katta plitka) — 5 va 6-rasmlarda ko'rsatilgan.

Taxminiy hisob-kitob

**Saqlash foydalanishi:** - 21-zum darajasida: ~4.4 trillion plitka × 100 KB = 440 PB. - Dunyo yuzasining 90% yuqori siqiladigan (okeanlar, cho'llar) → 80-90% kamaytirish → eng yuqori zum darajasi uchun **~50 PB**. - Barcha zum darjalarida jami (geometrik ketma-ketlik): **~100 PB**. - Yo'l ma'lumotlari: tashqi manbalardan xom ma'lumotlarning TB → yo'naltirish plitkalari ham TB.

**Server o'tkazuvchanligi (joylashuv yangilanishlari):** - 1B DAU × haftada 35 daqiqa navigatsiya = kuniga 5B daqiqa. - GPS har soniyada yangilanadi → kuniga 300B so'rov = 3M QPS. - Har 15 soniyada paketlash → **200,000 QPS** o'rtacha. - Cho'qqi QPS = 200,000 × 5 = **1 million QPS**.

**CDN ma'lumotlar foydalanishi:** - 30 km/s da, har bir 200m×200m plitka = 100 KB → 1.25 MB/daqiqa. - Kuniga 5B navigatsiya daqiqasi × 1.25 MB = kuniga 6.25 milliard MB → 62,500 MB/soniya. - 200 CDN POP → POP boshiga ~300 MB/soniya.

2-qadam - Yuqori Darajali Dizayn Taklif Qilish va Kelishuv Olish

Yuqori darajali dizayn

7-rasm uchta asosiy xizmat bilan yuqori darajali dizaynni ko'rsatadi: joylashuv xizmati, navigatsiya xizmati va xaritani ko'rsatish.

**Joylashuv xizmati (8-rasm):** Mijozlar har 15 soniyada paketlangan joylashuv yangilanishlarini yuboradi (mahalliy buferlashtirilgan, QPS ni 3M dan 200K ga kamaytiradi). Protokol: keep-alive bilan HTTP. ``` POST /v1/locations Parametrlar: locs — (kenglik, uzunlik, vaqt tamg'asi) kortej JSON massivi ``` Ma'lumotlar bazasi yuqori yozish o'tkazuvchanligi va gorizontal kengayuvchanlikni talab qiladi → Cassandra. Shuningdek, downstream xizmatlari uchun Kafka oqimiga ham yoziladi.

**Navigatsiya xizmati:** A dan B ga oqilona tez marshrut topadi. Kichik kechikishga chidamli; aniqlik muhim. ``` GET /v1/nav?origin=1355+market+street,SF&destination=Disneyland ``` Masofa, davomiylik, HTML ko'rsatmalar, polyline, sayohat rejimini qaytaradi.

**Xaritani ko'rsatish:** Mijoz plitkalalarni talabga binoan oladi. Ikki variant: - 1-variant: Plitkalalarni dinamik ravishda yaratish → og'ir server yuki, keshlash qiyin. Tavsiya etilmaydi. - 2-variant: Har bir zum darajasida oldindan yaratilgan statik plitkal, CDN orqali xizmat ko'rsatiladi (10-rasm).

11-rasm CDN POP larning plitkalalarni global miqyosda xizmat qilishini ko'rsatadi — mijozlar eng yaqin POP dan oladi.

Plitka URL geohash ishlatadi: `https://cdn.map-provider.com/tiles/9q9hvu.png`

Muqobil ko'rsatish oqimi (12-rasm): Mijozda geohash algoritmini qattiq kodlash o'rniga, xarita plitka xizmati (joylashuv, zum darajasi) → 9 ta plitka URL iga (joriy + 8 ta atrofdagi) tarjima qiladi. Keyin mijoz CDN dan oladi.

3-qadam - Chuqur Dizayn

Ma'lumotlar modeli

To'rt turdagi ma'lumot:

**Yo'naltirish plitkalari:** Xom yo'l ma'lumotlari to'plamlaridan oflayn yo'naltirish plitka qayta ishlash xizmati tomonidan yaratiladi. Uchta rezolyutsiya darajasi (mahalliy yo'llar, asosiy yo'llar, magistrallar). Ob'ekt saqlashida (S3) ikkilik qo'shni ro'yxatlar sifatida saqlanadi, tez qidirish uchun geohash bo'yicha tashkil etilgan. Yo'naltirish xizmatlari tomonidan intensiv keshlanadi.

**Foydalanuvchi joylashuvi ma'lumotlari (14-rasm):** Yuqori yozuv hajmi → Cassandra. Sxema: `(user_id, timestamp) → (kenglik, uzunlik, foydalanuvchi_rejimi, navigatsiya_rejimi)`. `user_id` bo'lim kaliti sifatida; samarali diapazon o'qishlari uchun klasterlash kaliti sifatida `timestamp`.

**Geokodlash ma'lumotlar bazasi:** Manzillar/joy nomlarini kenglik/uzunlikka aylantiradi. Tez o'qishlar uchun kalit-qiymat do'koni (Redis) (tez-tez o'qish, kamdan-kam yozish).

**Oldindan hisoblanagan xarita plitkalari:** 21 zum darajasida PNG rasmlar. S3 asosida CDN da saqlanadi. Oson qidirish uchun geohash bilan kodlangan.

Joylashuv xizmati (chuqur tahlil)

Joylashuv ma'lumotlari Cassandra ga yozilishga qo'shimcha ravishda Kafka ga ham yoziladi. Downstream xizmatlar Kafka oqimini iste'mol qiladi (15-rasm): - **Jonli trafik xizmati:** Trafik holatlarini ajratib oladi → jonli trafik ma'lumotlar bazasini yangilaydi. - **Yo'naltirish plitka qayta ishlash xizmati:** Yangi/yopilgan yo'llarni aniqlaydi → S3 dagi yo'naltirish plitkalalarini yangilaydi. - Tahlil, personalizatsiya va boshqalar uchun boshqa xizmatlar.

Xaritani ko'rsatish (chuqur tahlil)

Google Maps 21 zum darajasidan foydalanadi (16-rasm): - 0-daraja: butun dunyo bitta 256×256 piksellik plitkada. - Har bir zum darajasi: plitkalalar ikki yo'nalishda ikki baravar ko'payadi (daraja boshiga jami 4× plitka). - 21-daraja: ~4.4 trillion plitka.

**Vektor plitkalari (kelajakdagi yaxshilanish):** PNG rasmlar o'rniga vektor ma'lumotlarini (yo'llar/ko'pburchaklar) yuborish. Afzalliklari: - Vektor ma'lumotlari rasmlardan ancha yaxshi siqiladi. - Silliqroq zumlashtirish — vektorlar piksellashmasdan toza kengayadi (WebGL asosida ko'rsatish).

Navigatsiya xizmati (chuqur tahlil)

17-rasm to'liq navigatsiya xizmati dizaynini ko'rsatadi. Komponentlar:

1. **Geokodlash xizmati:** Manzil/joy nomini → kenglik/uzunlik juftiga aylantiradi. 2. **Marshrut rejalashtiruvchi:** Yo'naltirish quvurini boshqaradi. Eng qisqa yo'l xizmatini chaqiradi, ETA bashoratlarini oladi, tartiblashga uzatadi. 3. **Eng qisqa yo'l xizmati:** S3 dagi yo'naltirish plitkalalariga qarshi A* variantini ishlatadi. Algoritm: - Boshlang'ich/mo'ljal kenglik/uzunlikni → geohash larga → yo'naltirish plitkalalarini yuklash. - Grafni kesib o'tish, S3 dan qo'shni plitkalalarni talabga binoan yuklash. - Plitka ichidagi ulanishlar orqali plitka rezolyutsiya darajalari o'rtasida o'tish (mahalliy → asosiy → magistral). - 18-rasm plitkalalar bo'ylab kontseptual grafni kesib o'tishni ko'rsatadi. 4. **ETA xizmati:** Joriy trafik + tarixiy ma'lumotlar, shu jumladan kelajakdagi trafik bashoratlari bo'yicha ML yordamida ETA larni bashorat qiladi. 5. **Tartiblash xizmati:** Foydalanuvchi filtrlarini qo'llaydi (to'lovli yo'llardan qochish, avtomobil yo'llaridan qochish), marshrutlarni eng tezdan sekiniga tartiblaydi. 6. **Yangilash xizmatlari (asinxron):** - Yo'naltirish plitka qayta ishlash xizmati: joylashuv oqimidan yo'l o'zgarishlarini aniqlaydi. - Trafik yangilash xizmati: joylashuv oqimidan jonli trafikni ajratib oladi → jonli trafik ma'lumotlar bazasi.

**Moslashuvchan ETA va qayta yo'naltirish (19-rasm, 20-rasm):** Server faol navigatsiya qilayotgan foydalanuvchilarni kuzatadi. Oddiy yondashuv: marshrutlarni yo'naltirish plitkalari ro'yxatlari sifatida saqlash, ta'sirlangan foydalanuvchilar uchun O(n×m) skanerlash.

Optimallashtirilgan yondashuv: har bir foydalanuvchi uchun yo'naltirish plitkalalarining ierarxik zanjirini saqlash — joriy plitka + uning ota plitasi + buvisining plitasi... mo'ljal qoplanmaguncha. Foydalanuvchi T plitasidagi trafik o'zgarishidan ta'sirlanganligini tekshirish uchun faqat T foydalanuvchi zanjirining oxirgi (eng katta) plitasida borligini tekshirish. Bu ko'pchilik foydalanuvchilarni tez filtrlaydi.

Barcha faol navigatsiya qilayotgan foydalanuvchilar uchun ETA larni vaqti-vaqti bilan qayta hisoblash; tezroq marshrut topilsa xabardor qilish.

**Yetkazib berish protokoli:** WebSocket SSE yoki uzun polling o'rniga tanlanadi — qayta yo'naltirish va so'nggi mil yetkazib berish uchun ikki yo'nalishli muloqotni qo'llab-quvvatlaydi.

4-qadam - Yakunlash

Joylashuvni yangilash, ETA lar, marshrut rejalash va xaritani ko'rsatish bilan soddalashtirilgan Google Maps ni loyihalashtirildi. Asosiy komponentlar: yuqori yozuv joylashuv ma'lumotlari uchun Cassandra, hodisa oqimi uchun Kafka, oldindan hisoblanagan xarita plitkalari uchun CDN, S3 da ierarxik yo'naltirish plitkalari, talabga binoan plitka yuklash bilan A* yo'l topish.

21-rasm barcha komponentlarni integratsiyalash bilan yakuniy dizaynni ko'rsatadi.

Mumkin bo'lgan kengaytirish: yetkazib berish xizmatlari (Doordash, Uber, Lyft) uchun ko'p to'xtashli navigatsiya — jonli trafik xabardorligi bilan manzillarni tashrif buyurish uchun optimal tartib topish.

Taqsimlangan xabar navbatini loyihalashtiramiz — mustaqil qurilish bloklari o'rtasida muloqot va muvofiqlashtirishni ta'minlovchi tizim. Afzalliklari: ajratish (qattiq ulanish yo'q qilinadi), yaxshilangan kengayuvchanlik (ishlab chiqaruvchilar/iste'molchilarni mustaqil kengaytirish), ko'paytirилgan mavjudlik (biri oflayn bo'lganda boshqa komponentlar ishlashda davom etadi), yaxshilangan ishlash (asinxron muloqot).

1-rasm mashhur taqsimlangan xabar navbatlarini ko'rsatadi. Eslatma: Kafka va Pulsar texnik jihatdan hodisa oqimlash platformalari, lekin dizaynimiz faqat shu tizimlarda topilinadigan oqimlash xususiyatlarini (uzoq ma'lumot saqlash, takroriy iste'mol) o'z ichiga oladi.

1-qadam - Muammoni Tushunish va Dizayn Doirasini Belgilash

**Funksional talablar:** - Ishlab chiqaruvchilar xabar navbatiga xabarlar yuboradi. - Iste'molchilar xabar navbatidan xabarlarni iste'mol qiladi. - Xabarlar bir necha marta yoki faqat bir marta iste'mol qilinishi mumkin. - Tarixiy ma'lumotlar qisqartirilishi mumkin (2 haftalik saqlash). - Xabar hajmi: kilobayt diapazoni, faqat matn. - Tartiblangan yetkazib berish (ishlab chiqarilgan tartibda). - Sozlanuvchi ma'lumotlar yetkazib berish semantikasi: kamida bir marta, ko'pi bilan bir marta, aynan bir marta.

**Funksional bo'lmagan talablar:** - Yuqori o'tkazuvchanlik yoki past kechikish (foydalanish holatiga qarab sozlanuvchi). - Kengayuvchan: taqsimlangan, hajmning to'satdan oshishini qo'llab-quvvatlaydi. - Doimiy va barqaror: ma'lumotlar diskda, tugunlar bo'ylab replikalangan.

**An'anaviy navbatlar uchun eslatma:** RabbitMQ uslubidagi navbatlar xabarlarni uzoq muddatga saqlamaydi va tartibni kafolatlamaydi. Bu talablarni olib tashlash dizaynni sezilarli darajada soddalashtiradi.

2-qadam - Yuqori Darajali Dizayn Taklif Qilish va Kelishuv Olish

Xabar almashish modellari

**Nuqtadan nuqtaga (3-rasm):** Xabar aynan bitta iste'molchi tomonidan iste'mol qilinadi va tasdiqlangandan so'ng navbatdan o'chiriladi. Ma'lumot saqlanmaydi.

**Nashr-obuna (4-rasm):** Mavzuga yuborilgan xabarlarni obuna bo'lgan barcha iste'molchilar qabul qiladi. Dizaynimiz ikkala modelni qo'llab-quvvatlaydi — mavzular orqali pub-sub, iste'molchi guruhlari orqali nuqtadan nuqtaga simulyatsiya.

Mavzular, bo'limlar va brokerlar

**Bo'limlar (5-rasm):** Mavzu ma'lumotlari brokerlar bo'ylab taqsimlangan bo'limlarga shardlanadi. Har bir bo'lim FIFO navbati — bo'lim ichida xabar tartibini saqlaydi. Xabar pozitsiyasi = offset.

Xabarni yo'naltirish: agar xabar kaliti o'rnatilgan bo'lsa → hash(key) % numPartitions; aks holda tasodifiy bo'lim.

**Xabar navbati klasteri (6-rasm):** Brokerlar bo'limlarni saqlaydi. Mavzuni kengaytirish = bo'lim sonini oshirish.

**Iste'molchi guruhi (7-rasm):** - Mavzular ustida birgalikda ishlovchi iste'molchilar to'plami. - Har bir guruh o'z iste'mol etilgan offsetlarini saqlaydi. - Asosiy cheklov: bitta bo'lim guruh ichida FAQAT BITTA iste'molchi tomonidan iste'mol qilinishi mumkin → bo'lim darajasida tartibni kafolatlaydi. - Agar iste'molchilar > bo'limlar bo'lsa, ba'zi iste'molchilar ma'lumot olmaydi. - Nuqtadan nuqtaga simulyatsiya: barcha iste'molchilarni bir guruhga joylash.

Yuqori darajali arxitektura

8-rasm yuqori darajali dizaynni ko'rsatadi:

**Mijozlar:** - Ishlab chiqaruvchi: muayyan mavzularga xabarlar yuboradi. - Iste'molchi guruhi: xabarlarni obuna bo'ladi va iste'mol qiladi.

**Asosiy xizmat va saqlash:** - Broker: bir nechta bo'limlarni saqlaydi. - Ma'lumotlar saqlash: bo'limlarda saqlanadigan xabarlar. - Holat saqlash: iste'molchi holatlari (offsetlar, bo'lim-iste'molchi xaritasi). - Metadata saqlash: mavzu konfiguratsiyasi (bo'lim soni, saqlash, replika taqsimoti). - Muvofiqlashtiruv xizmati (Zookeeper/etcd): xizmat kashfiyoti (tirik brokerlar), lider saylov (bo'limlarni tayinlovchi faol kontroller).

3-qadam - Chuqur Dizayn

Yuqori ma'lumot saqlash bilan yuqori o'tkazuvchanlik uchun uchta asosiy dizayn tanlovi: 1. Ketma-ket kirish ishlashidan foydalanadigan diskdagi ma'lumotlar tuzilmasi. 2. Nusxasiz tranzit bilan xabar ma'lumotlari tuzilmasi (ishlab chiqaruvchi → navbat → iste'molchi). 3. Hamma joyda (ishlab chiqaruvchi, broker, iste'molchi) paketlashni afzal ko'rish.

Ma'lumotlar saqlash

**Trafik namunasi:** Ko'p yozish, ko'p o'qish; yangilanish/o'chirish yo'q; ketma-ket o'qish/yozish.

**1-variant — Ma'lumotlar bazasi:** Relyatsion yoki NoSQL — ideal emas. Ko'p yozish va o'qish uchun bir vaqtda keng ko'lamda loyihalash qiyin.

**2-variant — Yozishdan Oldingi Jurnal (WAL):** Faqat qo'shimcha jurnal fayl. MySQL redo log, ZooKeeper WAL da ishlatiladi.

Yangi xabarlar monoton oshib boruvchi offset bilan bo'lim quyrug'iga qo'shiladi (9-rasm). Fayllar segmentlarga bo'linadi — faqat faol segment yozishlarni qabul qiladi. Faol bo'lmagan segmentlar o'qishlarni xizmat qiladi. Eski segmentlar saqlash/sig'im chegarasida qisqartiriladi.

10-rasm `Partition-{:partition_id}` papkalarida tashkil etilgan segment fayllarini ko'rsatadi.

**Disk ishlash eslatmasi:** Disklar sekin degan keng tarqalgan noto'g'ri tushuncha — bu faqat tasodifiy kirishda to'g'ri. Zamonaviy RAID disklarda ketma-ket kirish bir necha yuz MB/soniyaga erishadi. OS ham disk ma'lumotlarini xotirada intensiv keshlayd (WAL bundan katta foyda ko'radi).

Xabar ma'lumotlari tuzilmasi

Sxema: `key (byte[]), value (byte[]), topic (string), partition (int), offset (long), timestamp (long), size (int), crc (int)`

- **Kalit:** bo'limni aniqlaydi (hash(key) % numPartitions). Noyob emas — KV do'koni kalitlaridan farqli. - **Qiymat:** payload — oddiy matn yoki siqilgan ikkilik. - **Offset:** bo'limdagi pozitsiya. Xabar (mavzu, bo'lim, offset) orqali topiladi. - **CRC:** ma'lumotlar yaxlitligi uchun tsiklik ortiqcha tekshiruv. - Filtrlash uchun ixtiyoriy maydonlar (masalan, teglar) qo'shilishi mumkin.

Ishlab chiqaruvchi oqimi

**Dastlabki dizayn (11-rasm):** Alohida yo'naltirish qatlami metadatadan replika taqsimotini o'qiydi, lider replika brokeriga yo'naltiradi.

Kamchiliklari: qo'shimcha tarmoq o'tishi, paketlash yo'q.

**Yaxshilangan dizayn (12-rasm):** Yo'naltirish qatlami + buffer ishlab chiqaruvchi mijoz kutubxonasiga integratsiya qilingan. - Afzalliklari: kamroq tarmoq o'tishlari → past kechikish, maxsus bo'lim mantig'i, yuqori o'tkazuvchanlik uchun paketlash.

**Paket hajmi kelishuvi (13-rasm):** Katta paket → yuqori o'tkazuvchanlik, yuqori kechikish. Kichik paket → past kechikish, past o'tkazuvchanlik. Foydalanish holatiga qarab sozlanuvchi.

Iste'molchi oqimi

Iste'molchi bo'limdagi offset ni belgilaydi va o'sha pozitsiyadan xabarlar bo'lagini qabul qiladi (14-rasm).

**Push va pull:** - Push: past kechikish, lekin iste'molchilarni haddan ortiq yuklab yuborishi mumkin; broker tezlikni nazorat qiladi. - **Pull (tanlangan):** iste'molchilar tezlikni nazorat qiladi; paketli qayta ishlash uchun mos; xabarlar yo'q bo'lganda behuda so'rovni oldini olish uchun uzun polling ni qo'llab-quvvatlaydi.

**Pull modeli ish jarayoni (15-rasm):** 1. Yangi iste'molchi guruh nomini xeshlash orqali koordinatorni topadi → bir xil gurohdagi barcha iste'molchilar bir xil koordinatorga ulanadi. 2. Koordinator bo'limlarni tayinlaydi (round-robin, diapazon va hokazo). 3. Iste'molchi so'nggi iste'mol etilgan offsetdan (holat saqlashdan) olib keladi. 4. Iste'molchi xabarlarni qayta ishlaydi va offsetni brokerga tasdiqlaydi.

Iste'molchi qayta muvozanatlashi

Qayta muvozanatlash quyidagi hollarda sodir bo'ladi: iste'molchi qo'shiladi, ketadi, ishdan chiqadi yoki bo'limlar o'zgaradi.

**Koordinator (16-rasm):** Guruh nomini xeshlash orqali topiladigan iste'molchi guruhi boshiga bitta broker. Iste'molchilar ro'yxatini saqlaydi, yurak urish signallarini qabul qiladi, offsetlarni boshqaradi. Ro'yxat o'zgarganda → yangi guruh liderini saylaydi → lider bo'lim rejasini yaratadi → koordinator tarqatadi.

**Stsenariylar:** - 17-rasm: Umumiy qayta muvozanatlash oqimi. - 18-rasm: Yangi B iste'molchi qo'shiladi → koordinator A ni qayta qo'shilishini xabardor qiladi → lider saylanadi → bo'lim rejasi yaratiladi va tarqatiladi. - 19-rasm: A iste'molchi munosib tarzda ketadi → koordinator qolgan iste'molchilarni qayta muvozanatlaydi. - 20-rasm: A iste'molchi ishdan chiqadi → koordinator yo'qolgan yurak urish signalini aniqlaydi → o'lik deb belgilaydi → qayta muvozanatlashni ishga tushiradi.

Holat saqlash

Saqlaydi: bo'lim-iste'molchi xaritasi, bo'lim boshiga iste'molchi guruhi bo'yicha so'nggi iste'mol etilgan offsetlar (21-rasm).

Kirish namunalari: tez-tez o'qish/yozish, ma'lumotlar tez-tez yangilanadi, tasodifiy kirish, izchillik muhim.

Tavsiya: Zookeeper kabi KV do'koni. Kafka offset saqlashni Zookeeper dan Kafka brokerlarining o'zlariga ko'chirdi.

Metadata saqlash va ZooKeeper

Metadata saqlash: mavzu konfiguratsiyasi (bo'limlar, saqlash, replika taqsimoti). Past hajm, kamdan-kam o'zgarishlar, yuqori izchillik → Zookeeper.

**ZooKeeper soddalashtirilgan dizayni (22-rasm):** - Metadata + holat saqlash Zookeeper ga ko'chirildi. - Broker faqat xabarlar uchun ma'lumot saqlashini saqlaydi. - Zookeeper broker lider saylovini boshqaradi.

Replikatsiya

Har bir bo'limning turli brokerlar bo'ylab 3 ta replikasi bor (23-rasm). Bitta replika lider, qolganlar followerlar. Ishlab chiqaruvchilar faqat liderga yuboradi. Followerlar liderdan tortib oladi.

Replika taqsimoti rejasi: saylangan broker kontroller rejani yaratadi va metadatada saqlaydi.

**Sinxronlashtiruvchi replikalar (ISR) (24-rasm):** ISR = liderdan `replica.lag.max.messages` ichidagi replikalar. Lider kechikishni hisoblash orqali ISR ro'yxatini kuzatadi. - Replika-2, Replika-3: to'liq sinxronlashgan → ISR da. - Replika-4: chegara oshdi → u yetib olguncha ISR dan chiqariladi.

**ACK sozlamalari:** - ACK=all (25-rasm): BARCHA ISR lar xabarni olgandan so'ng ACK → eng kuchli barqarorlik, eng yuqori kechikish. - ACK=1 (26-rasm): Lider saqlangandan so'ng ACK → yaxshilangan kechikish, replikatsiyadan oldin lider ishdan chiqsa ma'lumot yo'qolish xavfi. - ACK=0 (27-rasm): ACK yo'q, qayta urinish yo'q → eng past kechikish, qabul qilinadigan ma'lumot yo'qolishi (metrikalar, loglash).

Kengayuvchanlik

**Ishlab chiqaruvchi:** Holatsiz — nusxalarni erkin qo'shish/o'chirish.

**Iste'molchi:** Iste'molchi guruhlari ajratilgan → guruhlarni erkin qo'shish/o'chirish. Qayta muvozanatlash guruhlar ichidagi iste'molchi o'zgarishlarini boshqaradi.

**Broker nosozligi va tiklash (28-rasm):** 3-broker ishdan chiqadi → kontroller muvofiqlashtiruv xizmati orqali aniqlaydi → yangi replika taqsimoti rejasini yaratadi → qolgan broklardagi yangi replikalar liderlardan yetib oladi.

**Broker qo'shish (29-rasm):** Kontroller vaqtincha qo'shimcha replikalarga ruxsat beradi → yangi broker yetib oladi → eski brokerda ortiqcha replika munosib olib tashlanadi. Ma'lumot yo'qolmaydi.

**Bo'lim oshirish (30-rasm):** Mavjud xabarlar eski bo'limlarda qoladi (migratsiya yo'q). Yangi xabarlar barcha bo'limlar bo'ylab taqsimlanadi. Ishlab chiqaruvchi/iste'molchi avtomatik xabardor qilinadi.

**Bo'lim kamaytirish (31-rasm):** Ishdan chiqarilgan bo'lim yangi xabarlar qabul qilmaydi, lekin saqlash muddati tugaguncha o'qilishi mumkin. Joy faqat saqlash muddati tugagandan so'ng bo'shatiladi.

Ma'lumotlar yetkazib berish semantikasi

**Ko'pi bilan bir marta (32-rasm):** - Ishlab chiqaruvchi: ACK=0, qayta urinish yo'q. - Iste'molchi: qayta ishlashdan OLDIN offsetni tasdiqlaydi. - Xabarlar yo'qolishi mumkin, lekin hech qachon qayta yetkazilmaydi. Foydalanish holati: monitoring metrikalari.

**Kamida bir marta (33-rasm):** - Ishlab chiqaruvchi: ACK=1 yoki ACK=all, nosozlikda qayta urinish. - Iste'molchi: faqat muvaffaqiyatli qayta ishlashdan KEYIN offsetni tasdiqlaydi. - Xabarlar hech qachon yo'qolmaydi, lekin dublikat bo'lishi mumkin. Foydalanish holati: ko'pgina umumiy holatlar (iste'molchida noyob kalit bo'yicha dublikatdan chiqarish).

**Aynan bir marta (34-rasm):** - Amalga oshirish eng qiyin; eng yuqori narx. - Foydalanish holati: moliyaviy tranzaktsiyalar (to'lov, savdo, buxgalteriya) qayerda dublikat qabul qilinmaydi.

Kengaytirilgan xususiyatlar

**Xabarni filtrlash (35-rasm):** Iste'molchi guruhlari mavzu xabarlarining faqat kichik turlarini xohlashi mumkin. Oddiy usul: iste'molchi hammasini olib mahalliy joyda filtrlaydi (o'tkazuvchanlikni isrof qiladi). Yaxshiroq: xabarlarga teglar biriktiring, payload ga kirmay broker tomonida filtrlash. Iste'molchi teg bo'yicha obuna bo'ladi.

**Kechiktirilgan/rejalashtirilgan xabarlar (36-rasm):** Kechiktirilgan xabarlar broker da vaqtinchalik saqlashga yuboriladi, kechikish muddati tugagandan keyin mavzuga yetkaziladi. Asosiy komponentlar: vaqtinchalik saqlash (maxsus mavzular) + vaqtlash funksiyasi (oldindan belgilangan darajalar bilan kechikish navbatlari yoki ierarxik vaqt g'ildiragi).

Foydalanish holati: 30 daqiqa to'lov vaqt chegarasi — darhol kechiktirilgan xabar yuborish, to'lov holatini tekshirish uchun 30 daqiqadan so'ng iste'molchiga yetkazish.

4-qadam - Yakunlash

Asosiy dizayn tanlovi: WAL diskda saqlash, nusxasiz xabar tranziti, keng tarqalgan paketlash, ISR asosida replikatsiya, sozlanuvchi ACK.

**Qo'shimcha mavzular:** - Protokol: AMQP yoki Kafka protokoli — ishlab chiqarish/iste'mol qilish/yurak urish signallarini qamrab oladi, samarali ma'lumot transporti, yaxlitlikni tekshirish. - Qayta iste'mol qilish: muvaffaqiyatsiz xabarlar → keyinchalik qayta ishlash uchun maxsus qayta urinish mavzusiga. - Tarixiy ma'lumotlar arxivi: qisqartirilgan tarixiy xabarlarni qayta ijro qilish uchun HDFS yoki ob'ekt saqlash.

Biz katta kompaniyaning ichki foydalanishi uchun kengaytiriladigan metrikalarni monitoring qilish va ogohlantirish tizimini loyihalashtirmoqdamiz (Datadog, Splunk kabi). 1-rasmda ushbu sohadagi mashhur xizmatlar ko'rsatilgan. Yaxshi loyihalashtirilgan tizim infratuzilma salomatligini aniq ko'rsatib, yuqori mavjudlik va ishonchlilikni ta'minlaydi.

1-qadam — Muammoni Tushunish va Loyiha Doirasini Belgilash

**Talablar:** - Katta kompaniya uchun ichki tizim. - Operatsion tizim metrikalarini yig'ish (CPU yuklama, xotira, disk, so'rovlar/soniya, xabar navbati soni). Jurnal monitoringi va taqsimlangan kuzatuv yo'q. - Ko'lam: 100 million kunlik faol foydalanuvchi, 1000 server puli × 100 mashina × 100 metrika = **~10 million metrika**. - 1 yillik saqlash muddati va namuna qisqartirish: - 0-7 kun: xom ko'rinishda. - 7-30 kun: 1 daqiqalik aniqlik. - 30 kun - 1 yil: 1 soatlik aniqlik. - Ogohlantirish kanallari: elektron pochta, telefon, PagerDuty, webhook.

**Funktsional bo'lmagan talablar:** - Kengaytiriladigan (o'sib borayotgan metrikalar va ogohlantirishlar uchun). - Past kechikish (dashboard va ogohlantirishlar). - Yuqori ishonchlilik (muhim ogohlantirishlar o'tkazib yuborilmasin). - Moslashuvchan pipeline (texnologiyalarni oson integratsiya qilish).

2-qadam — Yuqori Darajali Dizayn Taklif Qilish va Rozilik Olish

Asosiy tushunchalar

Metrikalarni monitoring tizimining beshta komponenti (2-rasm): 1. **Ma'lumot yig'ish:** manbalardan metrika ma'lumotlarini to'plash. 2. **Ma'lumot uzatish:** ma'lumotlarni monitoring tizimiga o'tkazish. 3. **Ma'lumot saqlash:** kelayotgan ma'lumotlarni tartibga solish va saqlash. 4. **Ogohlantirish:** ma'lumotlarni tahlil qilish, anomaliyalarni aniqlash, kanallarga ogohlantirishlar yuborish. 5. **Vizualizatsiya:** ma'lumotlarni grafik va diagrammalarda ko'rsatish.

Ma'lumot modeli

Metrika ma'lumotlari vaqt qatori hisoblanadi: metrika nomi + yorliqlar bilan noyob tarzda aniqlanadigan, vaqt tamg'alari bilan bog'liq qiymatlar to'plami.

**Misol (3-rasm):** i631 serverida soat 20:00 dagi CPU yuklama → `{metric_name: cpu.load, labels: host:i631,env:prod, timestamp: 1613707265, value: 0.29}`

**Satr protokoli formati:** `CPU.load host=webserver01,region=us-west 1613707265 50`

Vaqt qatori sxemasi: - Metrika nomi (satr) - Yorliqlar/teglar (kalit:qiymat juftliklari ro'yxati) - (qiymat, vaqt tamg'asi) juftliklari massivi

**Ma'lumotlarga kirish namunasi (4-rasm):** - **Yozish:** intensiv — ~10 million metrika yuqori chastotada doimiy yoziladi. - **O'qish:** o'zgaruvchan — vizualizatsiya va ogohlantirish tez-tez o'qishlarni keltirib chiqaradi.

**Ma'lumot saqlash — nima uchun vaqt qatori ma'lumotlar bazasi:** - Umumiy maqsadli MB (MySQL): yomon mos — vaqt oralig'idagi so'rovlar uchun murakkab SQL, har bir teg uchun indeks kerak, doimiy intensiv yozishda qiyinchilik. - NoSQL (Cassandra, Bigtable): mumkin, ammo kengaytiriladigan vaqt qatori sxemasi uchun chuqur bilim talab etiladi. - **Vaqt qatori MB (InfluxDB, Prometheus):** ketma-ket yozish uchun optimallashtirilgan, maxsus so'rov tillari, o'rnatilgan yorliq indekslash, ma'lumotlarni saqlash/birlashtirish imkoniyatlari.

5-rasm: InfluxDB 8 yadroli + 32 GB RAM bilan **250 000+ yozish/soniya** ni ko'taradi.

Yuqori darajali dizayn

6-rasmda yuqori darajali dizayn komponentlari ko'rsatilgan: - **Metrika manbasi:** dastur serverlari, MB lar, xabar navbatlari. - **Metrika kollektori:** metrikalarni yig'adi, vaqt qatori MB ga yozadi. - **Vaqt qatori ma'lumotlar bazasi:** maxsus so'rov interfeysi + yorliq indekslari bilan metrikalarni saqlaydi. - **So'rov xizmati:** vizualizatsiya va ogohlantirish tizimlari uchun vaqt qatori MB ustidagi yengil qatlam. - **Ogohlantirish tizimi:** kanallarga bildirishnomalar yuboradi. - **Vizualizatsiya tizimi:** muhandislar uchun grafik va diagrammalar.

3-qadam — Chuqur Dizayn

Metrikalarni yig'ish

Vaqti-vaqti bilan ma'lumot yo'qolishi qabul qilinadi (yubor va unut). 7-rasmda metrikalarni yig'ish oqimi ko'rsatilgan.

**Pull modeli (8-rasm):** Maxsus metrika kollektorlari ishlaydigan dasturlardan HTTP orqali metrikalarni oladi (masalan, `/metrics` endpointi).

**Xizmatni kashf etish (9-rasm):** Kollektorlar xizmat endpointlarini topish uchun etcd/Zookeeper dan foydalanadi. Konfiguratsiya: tortish intervali, IP manzillar, timeout, qayta urinish parametrlari.

**Pull modeli batafsil (10-rasm):** 1. Kollektor Xizmatni Kashf Etishdan endpoint konfiguratsiyasini oladi. 2. HTTP `/metrics` endpointi orqali metrikalarni tortadi (mijoz kutubxonasi kerak). 3. Ixtiyoriy ravishda Xizmatni Kashf Etishdan o'zgarish hodisalarini kuzatadi.

**Pull modelini kengaytirish (11-rasm):** Bir nechta kollektorlar bilan ketma-ket xeshlash halqasidan foydalanish. Har bir kollektor halqaning bir qismiga egalik qiladi → har bir manba server faqat bitta kollektorga tayinlanadi (dublikatsiz).

**Push modeli (12-rasm):** Har bir serverda o'rnatilgan yig'ish agentlari metrikalarni kollektorlarga muntazam ravishda yuboradi. Agent yuborishdan oldin lokal agregatsiya qilishi mumkin. Yukni muvozanatlash bilan avtomatik kengayadigan kollektor klasteri (13-rasm) ortiqcha yuklamani oldini oladi.

**Pull va push taqqoslash:**

| | Pull | Push | |---|---|---| | Nosozliklarni tuzatish | Oson — `/metrics` istalgan vaqt mavjud | Qiyinroq | | Salomatlikni tekshirish | Oson — javob yo'q = server o'chgan | Tarmoq muammosini ma'lumotsizlikdan ajratish qiyin | | Qisqa muddatli ishlar | O'tkazib yuboradi (tuzatish: push gateway lar) | Yaxshi ishlaydi | | Tarmoq sozlamasi | Barcha endpointlar erishilishi kerak | Yukni muvozanatlash har qayerdan qabul qiladi | | Protokol | TCP | UDP (past kechikish) | | Ma'lumot haqiqiyligi | Konfiguratsiya fayllarida belgilangan | Har qanday mijoz yuborishi mumkin (tuzatish: whitelist/autentifikatsiya) |

Misollar: Pull → Prometheus. Push → Amazon CloudWatch, Graphite.

Metrikalarni uzatish pipelineni kengaytirish

Metrika kollektori klasteri har ikki modeldan ham katta hajmda ma'lumot oladi (14-rasm). Xavf: vaqt qatori MB mavjud bo'lmasa ma'lumot yo'qolishi.

**Yechim (15-rasm):** Kollektorlar va vaqt qatori MB o'rtasiga Kafka navbatini qo'shish. Oqim protsessorlari (Apache Storm, Flink, Spark) Kafka dan iste'mol qilib, TSDB ga yozadi.

Afzalliklari: - Yuqori ishonchli va kengaytiriladigan xabar almashish platformasi. - Ma'lumot yig'ishni qayta ishlashdan ajratadi. - MB mavjud bo'lmaganda ma'lumot yo'qolishini oldini oladi.

**Kafka orqali kengaytirish (16-rasm):** - O'tkazuvchanlik asosida bo'lim sonini sozlash. - Metrika nomi bo'yicha bo'limlash → iste'molchilar metrika bo'yicha agregatsiya qiladi. - Teglar/yorliqlar bo'yicha qo'shimcha bo'limlash. - Muhim metrikalarni ustuvorlashtirish.

**Kafka muqobili:** Facebook ning Gorilla in-memory vaqt qatori MB qisman tarmoq uzilishlarida ham yuqori yozish mavjudligini ta'minlash orqali oraliq navbatdan qochadi.

So'rov xizmati

Vizualizatsiya/ogohlantirish mijozlari uchun vaqt qatori MB ga kiradigan so'rov serverlar klasteri. TSDB ni mijozlardan ajratadi — har birini almashtirish moslashuvchanligi.

**Kesh qatlami (17-rasm):** Kesh serverlar TSDB yuklamani kamaytirish uchun so'rov natijalarini saqlaydi.

**Vaqt qatori so'rov tili:** Prometheus va InfluxDB SQL o'rniga maxsus tillardan (PromQL, Flux) foydalanadi. Sabab: vaqt oralig'ini tahlil qilish uchun SQL murakkab.

Eksponensial harakatlanuvchi o'rtacha uchun SQL (murakkab): ```sql select id, temp, avg(temp) over (partition by group_nr order by time_read) ... ```

Flux (oddiy): ``` from(db:"telegraf") |> range(start:-1h) |> filter(...) |> exponentialMovingAverage(size:-10s) ```

Saqlash qatlami

**Ma'lumotlarni kodlash va siqish (18-rasm):** So'rovlarning 85% so'nggi 26 soat ichida yig'ilgan ma'lumotlar uchun (Facebook tadqiqoti). Delta kodlashdan foydalanish: to'liq vaqt tamg'alari o'rniga 1610087371, 10, 10, 9, 11 ni saqlash → delta uchun 32 bit emas, 4 bit.

**Namuna qisqartirish:** Disk foydalanishini kamaytirish uchun yuqori aniqlikni pastroq aniqlikka o'tkazish. - 0-7 kun: namuna olish yo'q (xom). - 7-30 kun: 1 daqiqalik aniqlik. - 30 kun - 1 yil: 1 soatlik aniqlik.

Misol: 10 soniyalik ma'lumotlar → uchta nuqtani o'rtalashtirish orqali 30 soniyalik ma'lumotlarga.

**Sovuq saqlash:** Faol bo'lmagan/eski ma'lumotlar sovuq saqlashga ko'chiriladi (narxi ancha arzon).

Ogohlantirish tizimi

19-rasmda ogohlantirish tizimining oqimi ko'rsatilgan:

1. **Ogohlantirish konfiguratsiyasini keshga yuklash:** Qoidalar YAML fayllarida belgilanadi. ```yaml - name: instance_down rules: - alert: instance_down expr: up == 0 for: 5m labels: severity: page ``` 2. **Ogohlantirish menejeri keshdan konfiguratsiya oladi.** 3. **Ogohlantirish menejeri oldindan belgilangan intervallarda so'rov xizmatini chaqiradi.** Chegara buzilsa → ogohlantirish hodisasi yaratiladi. Mas'uliyatlar: - **Filtrlash, birlashtirish, deduplikatsiya (20-rasm):** Qisqa vaqt oralig'ida bir xil instansiya uchun bir nechta ogohlantirishlarni birlashtirish. - **Kirishni boshqarish:** Operatsiyalarni faqat vakolatli foydalanuvchilar bilan cheklash. - **Qayta urinish:** Kamida bir marta bildirishnoma yetkazilishini ta'minlash. 4. **Ogohlantirish ombori:** Ogohlantirish holatini saqlaydigan kalit-qiymat ma'lumotlar bazasi, Cassandra (faolsiz → kutish → otish → hal qilindi). 5. Tegishli ogohlantirishlar → Kafka. 6. Ogohlantirish iste'molchilari Kafka dan oladi. 7. Ogohlantirish iste'molchilari elektron pochta, SMS, PagerDuty, HTTP webhook orqali bildirishnoma yuboradi.

**Qurishmi yoki sotib olishmi:** Sanoat miqyosidagi ogohlantirish tizimlari (masalan, Grafana Alerting) mashhur TSDB va bildirishnoma kanallari bilan integratsiyalashadi. Sotib olish uchun kuchli dalillar mavjud.

Vizualizatsiya tizimi

Ma'lumot qatlami ustiga qurilgan. 21-rasmda Grafana interfeysida server so'rovlari, xotira/CPU foydalanishi, sahifa yuklash vaqti, trafik, kirish ma'lumotlari ko'rsatilgan.

Tavsiya: Grafana dan foydalanish (tayyor yechim). Yuqori sifatli vizualizatsiya tizimini qurish qiyin; Grafana mashhur vaqt qatori ma'lumotlar bazalari bilan yaxshi integratsiyalashadi.

4-qadam — Yakunlash

Asosiy dizayn mavzulari: pull va push yig'ish, ko'lam uchun Kafka, vaqt qatori MB tanlash, saqlashni optimallashtirish uchun namuna qisqartirish, ogohlantirish/vizualizatsiya uchun qurish yoki sotib olish.

22-rasmda yakuniy integratsiyalangan dizayn ko'rsatilgan.

Biz Facebook/Google miqyosida reklama bosish hodisalarini agregatsiya qilish tizimini loyihalashtirmoqdamiz. Raqamli reklamada Real-Vaqtli Tender (RTB) ishlatiladi — inventar bir soniyadan kam vaqt ichida sotib olinadi va sotiladi (1-rasm). CTR (bosish tezligi) va CVR (konversiya tezligi) kabi asosiy metrikalar agregatsiyalangan bosish ma'lumotlariga bog'liq. Ma'lumot aniqligi juda muhim, chunki u bevosita reklama beruvchilarning hisobiga ta'sir qiladi.

1-qadam — Muammoni Tushunish va Loyiha Doirasini Belgilash

**Funktsional talablar:** - Kirish: `ad_id, click_timestamp, user_id, ip, country` maydonli jurnal fayllari. - So'rov 1: so'nggi M daqiqada berilgan ad_id uchun bosish hodisalari soni. - So'rov 2: o'tgan 1 daqiqada eng ko'p bosilgan 100 ta reklama (sozlanadi). - So'rov 3: ip, user_id yoki country bo'yicha filtrlash. - Kechikib kelgan hodisalar, dublikat hodisalar va tizimni tiklashni boshqarish.

**Funktsional bo'lmagan talablar:** - To'g'rilik (RTB va hisoblash uchun ishlatiladi). - Kechiktirilgan va dublikat hodisalarni to'g'ri boshqarish. - Mustahkamlik (qisman nosozliklarga chidamli). - Uchidan uchigacha kechikish: ko'pi bilan bir necha daqiqa.

**Taxminiy hisob-kitob:** - Kuniga 1 milliard reklama bosish hodisasi. - O'rtacha QPS = 10^9 / 10^5 = **10 000 QPS**; cho'qqi QPS = **50 000**. - Saqlash: 0,1 KB × 1 mlrd = **100 GB/kun** (~3 TB/oy).

2-qadam — Yuqori Darajali Dizayn Taklif Qilish va Rozilik Olish

So'rov API dizayni

**API 1:** Reklama uchun bosish sonini agregatsiya qilish. ``` GET /v1/ads/{:ad_id}/aggregated_count Parametrlar: from (boshlang'ich daqiqa), to (tugash daqiqasi), filter (filtrlash strategiyasi id) Javob: { ad_id, count } ```

**API 2:** Eng ko'p bosilgan N ta reklama. ``` GET /v1/ads/popular_ads Parametrlar: count (top N), window (M daqiqa), filter (filtrlash strategiyasi id) Javob: { ad_ids: [...] } ```

Ma'lumot modeli

**Xom ma'lumot (jurnal fayllari):** ``` [AdClickEvent] ad001, 2021-01-01 00:00:01, user1, 207.148.22.22, USA ``` Maydonlar: `ad_id, click_timestamp, user_id, ip, country`

**Agregatsiyalangan ma'lumot (daqiqa bo'yicha):** `ad_id, click_minute, count` — filtrlash uchun ixtiyoriy `filter_id` bilan.

**Top N ma'lumoti:** `window_size, update_time_minute, most_clicked_ads (JSON massivi)`

**Tavsiya: XOM va agregatsiyalangan ma'lumotlarni IKKALASINI ham saqlash.** - Xom ma'lumot: qayta hisoblash, nosozliklarni tuzatish uchun zaxira. Eski bo'lganda sovuq saqlashga ko'chiriladi. - Agregatsiyalangan ma'lumot: so'rov samaradorligi uchun optimallashtirilgan faol ma'lumot.

**Ma'lumotlar bazasini tanlash:** Yozishga intensiv (o'rtacha 10K QPS). Xom va agregatsiyalangan ma'lumotlar uchun Cassandra yoki InfluxDB kabi NoSQL afzalroq (yozish + vaqt oralig'idagi so'rovlar uchun optimallashtirilgan). Muqobil: S3 da ustunli formatlar (ORC, Parquet, AVRO) yordamida xom ma'lumotlarni saqlash.

Yuqori darajali dizayn

2-rasmda agregatsiya ish oqimi ko'rsatilgan. 3-rasmda ikki Kafka navbati bilan to'liq yuqori darajali dizayn ko'rsatilgan:

- **Kafka 1:** xom reklama bosish hodisalari. - **Agregatsiya xizmati:** MapReduce qayta ishlash. - **Kafka 2:** agregatsiyalangan natijalar (daqiqa bo'yicha bosish soni + daqiqa bo'yicha top N reklamalar). - **Ma'lumotlar bazasi yozuvchisi:** Kafka 2 dan so'raydi, MB ga yozadi.

Kafka 2 sababi (to'g'ridan-to'g'ri MB ga yozmaslik): atomik commit orqali uchidan uchigacha aynan bir marta semantika uchun zarur (4-rasm).

**Agregatsiya xizmati — MapReduce DAG (5-rasm):** - **Map node (6-rasm):** ma'lumot manbasidan o'qiydi, hodisalarni filtrlaydi va yo'naltiradi. Masalan, `ad_id % 2 = 0` bo'lgan reklamalar → 1-node, qolganlari → 2-node. - **Aggregate node:** har daqiqada xotirada ad_id bo'yicha reklama bosish hodisalarini sanaydi (xotirada hisoblash). - **Reduce node (7-rasm):** barcha Aggregate nodelardan agregatsiyalangan natijalarni yakuniy natijaga kamaytiradi.

Oraliq ma'lumotlar xotirada saqlanadi; nodelar TCP (turli jarayonlar) yoki umumiy xotira (bir jarayon) orqali muloqot qiladi.

**Foydalanish holatlari:** - 8-rasm: bosishlarni sanash — kirish `ad_id % 3` bo'yicha bo'linadi → har bir Aggregate node mustaqil sanaydi. - 9-rasm: top N reklamalar — har bir Aggregate node top 3 reklama uchun heap saqlaydi → Reduce node yakuniy top N ga birlashtiradi. - Filtrlash: yulduz sxemasi — o'lcham bo'yicha oldindan agregatsiya (mamlakat, ip, user_id). Yozuvlarda `ad_id, click_minute, country, count` bor.

3-qadam — Chuqur Dizayn

Oqim va paketli qayta ishlash

Bizning dizaynimiz ham oqim qayta ishlash (real-vaqtli agregatsiya), ham paketli qayta ishlash (tarixiy ma'lumotlar zaxirasi) dan foydalanadi.

**Lambda arxitekturasi:** Ikki qayta ishlash yo'li (paket + oqim) bir vaqtda. Kamchiligi: ikki kod bazasini saqlash.

**Kappa arxitekturasi (bizning tanlovimiz, 10-rasm):** Real-vaqtli va tarixiy qayta ishlash uchun bitta oqim qayta ishlash yo'li. Oddiyroq — bitta kod bazasi.

**Ma'lumotlarni qayta hisoblash (11-rasm):** Agregatsiya xizmatida xato topilganda: 1. Qayta hisoblash xizmati sovuq saqlashdan xom ma'lumotlarni oladi (paketli ish). 2. Maxsus agregatsiya xizmatiga yuboradi (real-vaqtlidan alohida, ta'siri yo'q). 3. Agregatsiyalangan natijalar → Kafka 2 → MB yangilanishi.

Vaqt va agregatsiya oynasi

**Hodisa vaqti va qayta ishlash vaqti (12-rasm):** - Hodisa vaqti: reklama bosilganda → aniqroq, lekin mijoz soatiga bog'liq (noto'g'ri/zararli bo'lishi mumkin). - Qayta ishlash vaqti: server tizim vaqti → ishonchliroq, lekin kechikib kelgan hodisalar uchun noaniq. - Tavsiya: aniqlik uchun **hodisa vaqti**.

**Suv belgisi texnikasi (13, 14-rasmlar):** Agregatsiya oynasini sozlanadigan muddat (masalan, 15 soniya) ga uzaytiradi, shunda biroz kechikkan hodisalar ham qo'lga olinadi. - Uzun suv belgisi: yaxshi aniqlik, yuqori kechikish. - Qisqa suv belgisi: past kechikish, ba'zi ma'lumot yo'qolishi. - Juda kech kelgan hodisalar: kun oxirida yarashtirish orqali boshqarish.

**Ag'dariluvchi oyna (15-rasm):** Qo'shilmaydigan qat'iy vaqt bo'laklari. 1-foydalanish holati uchun eng yaxshi (daqiqa bo'yicha sana).

**Siljuvchi oyna (16-rasm):** Sozlangan interval bilan siljuvchi qo'shiluvchi oyna. 2-foydalanish holati uchun eng yaxshi (so'nggi M daqiqada top N).

Yetkazib berish kafolatlari

Agregatsiya hisoblash uchun ishlatilganligi sababli, **aynan bir marta** yetkazib berish talab etiladi (kamida bir marta emas). Bir necha foiz tafovut = hisoblash xatolarida millionlab dollar.

**Ma'lumotlarni deduplikatsiya qilish — dublikat manbalari:** 1. Mijoz tomoni: zararli qayta yuborish → reklama firibgarligi/xavf nazorati komponentlari tomonidan hal qilinadi. 2. Server xarobiyligi (17-rasm): Agregator pastki oqimga yuborgandan keyin, lekin offsetni commit qilishdan oldin ishdan chiqadi → keyingi Agregator bir xil hodisalarni qayta ishlaydi.

**Offset kuzatish yechimlari:** - 18-rasm: Pastki oqimga yuborishdan OLDIN offsetni tashqi saqlashga (HDFS/S3) yozish. Muammo: pastki oqimga yuborish muvaffaqiyatsiz bo'lsa, offset allaqachon yozilgan → hodisalar yo'qoladi. - 19-rasm: Pastki oqimdan ACK olgandan KEYIN offsetni yozish. Muammo: Agregator offsetni saqlashdan oldin ishdan chiqsa → hodisalar qayta qayta ishlanadi (dublikat). - 20-rasm: 4-6 qadamlarni **taqsimlangan tranzaksiya** ga o'rash → aynan bir marta kafolat. Biror qadam muvaffaqiyatsiz bo'lsa, butun tranzaksiya bekor qilinadi.

Katta miqyosli tizimlarda aynan bir marta murakkab — tafsilotlar uchun Apache Flink ning uchidan uchigacha aynan bir marta hujjatiga murojaat qiling.

Tizimni kengaytirish

Biznes yiliga 30% o'sadi → har 3 yilda ikki baravar. Har bir komponentni mustaqil ravishda kengaytirish.

**Xabar navbatini kengaytirish:** - Ishlab chiqaruvchilar: instansiyalar sonida cheklov yo'q. - Iste'molchilar (21-rasm): guruhga iste'molchilar qo'shish → muvozanatlash bo'limlarni taqsimlaydi. Buni cho'qqi vaqtlardan tashqarida bajaring (muvozanatlash bir necha daqiqa davom etishi mumkin). - Brokerlar: Kafka xeshlash kaliti sifatida `ad_id` dan foydalanish → bir xil reklama hodisalari bir xil bo'limga tushadi. Yetarlicha bo'limlarni oldindan ajratib qo'yish. Mavzularni geografiya yoki biznes turi bo'yicha bo'laklash.

**Agregatsiya xizmatini kengaytirish (22-rasm):** - 1-variant: Ko'p iplilik — turli `ad_id` oraliqlarini turli iplarga berish (23-rasm). Amalga oshirish osonroq. - 2-variant: YARN orqali ko'p jarayon — gorizontal kengaytirish. Ishlab chiqarishda kengroq qo'llaniladi.

**Ma'lumotlar bazasini kengaytirish:** Cassandra ketma-ket xeshlash yordamida gorizontal kengaytishni qo'llab-quvvatlaydi (24-rasm — virtual nodelar). Node qo'shish avtomatik muvozanatlaydi — qo'lda qayta bo'laklash shart emas.

**Issiq nuqta muammosi (25-rasm):** Mashhur reklamalar (yirik reklama beruvchilar) mutanosib bo'lmagan hodisalar oladi. - Agregatsiya node ortiqcha yuklamani aniqlaydi → resurs menejeridan qo'shimcha resurs so'raydi. - Resurs menejeri qo'shimcha nodelar ajratadi → asl node hodisalarni nodelar bo'ylab bo'ladi → natijalar qayta agregatsiya qilinadi. - Ilg'or: Global-Lokal Agregatsiya yoki Bo'lingan Alohida Agregatsiya.

Nosozliklarga chidamlilik

Agregatsiya xotirada amalga oshiriladi → node xarobiyaligi xotiradagi holatni yo'qotadi.

**Snapshot mexanizmi (26-rasm):** Tizim holatini (yuqori oqim Kafka offseti + top-N agregatsiya holati) davriy ravishda snapshotga saqlash.

**Muqobil almashtirish (27-rasm):** Yangi node so'nggi snapshotdan boshlanadi, Kafka brokeridan faqat snapshot dan keyingi hodisalarni qayta o'ynaydi. Tez tiklash — boshidan qayta o'ynash shart emas.

4-qadam — Yakunlash

Asosiy dizayn mavzulari: agregatsiya uchun MapReduce DAG, birlashtirilgan paket+oqim uchun Kappa arxitekturasi, kechikkan hodisalar uchun suv belgisi, aynan bir marta uchun taqsimlangan tranzaksiyalar, snapshot asosidagi nosozliklarga chidamlilik.

28-rasmda yarashtirish qo'llab-quvvatlamasi bilan yakuniy dizayn ko'rsatilgan. 29-rasmda OLAP asosidagi agregatsiya uchun Hive + ElasticSearch + ClickHouse/Druid yordamida muqobil dizayn ko'rsatilgan.

Biz Marriott International kabi mehmonxona tarmog'i uchun mehmonxona bron qilish tizimini loyihalashtirmoqdamiz. Dizayn va texnikalar boshqa bron qilish bilan bog'liq suhbat mavzulariga ham qo'llaniladi: Airbnb ni loyihalash, aviabilet bron qilish tizimini loyihalash, kino chiptasi bron qilish tizimini loyihalash.

1-qadam — Muammoni Tushunish va Loyiha Doirasini Belgilash

**Funktsional talablar:** - Jami **5 000 mehmonxona va 1 million xona** ga ega mehmonxona tarmog'i. - Mijozlar bron qilishda to'liq to'laydi. - Faqat mehmonxona veb-sayti yoki ilovasi orqali bron qilish. - Mijozlar bronlarni bekor qilishi mumkin. - **10% ortiqcha bron** qo'llab-quvvatlanadi (mehmonxonalar bekor qilishni oldindan ko'rish uchun sig'imdan ko'proq xona sotadi). - Doira: mehmonxona tafsilotlari sahifasi, xona tafsilotlari sahifasi, xona bron qilish, admin panel, ortiqcha bron. - Xona narxlari dinamik ravishda o'zgaradi (berilgan kun uchun kutilayotgan bandlikka bog'liq).

**Funktsional bo'lmagan talablar:** - Yuqori bir vaqtdalikni qo'llab-quvvatlash — mashhur mehmonxonalarda cho'qqi mavsumida ko'p foydalanuvchi bir xona uchun bron qilishi mumkin. - O'rtacha kechikish — bron jarayonini bir necha soniyada qayta ishlash qabul qilinadi.

**Taxminiy hisob-kitob (1-rasm):** - 5 000 mehmonxona, 1 million xona, 70% bandlik, o'rtacha 3 kunlik yashash. - Kunlik bronlar: (1M × 0,7) / 3 ≈ **240 000/kun**. - Bron TPS: 240 000 / 10⁵ soniya ≈ **3 TPS**. - Odatiy mijoz voronkasi (har bosqichda 10% konversiya): - Mehmonxona tafsilotlari sahifasi QPS: **300** - Bron sahifasi QPS: **30** - Yakuniy bron TPS: **3**

2-qadam — Yuqori Darajali Dizayn Taklif Qilish va Rozilik Olish

API dizayni

Mehmonxona, xona va bronlarni boshqarish uchun RESTful API lar.

**Mehmonxona API lari:** | API | Tafsilot | |-----|----------| | GET /v1/hotels/ID | Mehmonxona tafsilotlarini olish | | POST /v1/hotels | Mehmonxona qo'shish (faqat xodimlar) | | PUT /v1/hotels/ID | Mehmonxonani yangilash (faqat xodimlar) | | DELETE /v1/hotels/ID | Mehmonxonani o'chirish (faqat xodimlar) |

**Xona API lari:** | API | Tafsilot | |-----|----------| | GET /v1/hotels/ID/rooms/ID | Xona tafsilotlarini olish | | POST /v1/hotels/ID/rooms | Xona qo'shish (faqat xodimlar) | | PUT /v1/hotels/ID/rooms/ID | Xonani yangilash (faqat xodimlar) | | DELETE /v1/hotels/ID/rooms/ID | Xonani o'chirish (faqat xodimlar) |

**Bron API lari:** | API | Tafsilot | |-----|----------| | GET /v1/reservations | Bron tarixini olish | | GET /v1/reservations/ID | Bron tafsilotlarini olish | | POST /v1/reservations | Yangi bron qilish | | DELETE /v1/reservations/ID | Bronni bekor qilish |

**Bron so'rovi tanasi:** ```json { "startDate": "2021-04-28", "endDate": "2021-04-30", "hotelID": "245", "roomID": "U12354673389", "reservationID": "13422445" } ```

`reservationID` ikki marta bron qilishni oldini oluvchi **idempotentlik kaliti** hisoblanadi.

Ma'lumot modeli

Kirish namunalari: 1. Mehmonxona haqida batafsil ma'lumot ko'rish. 2. Sana oralig'i berilganda mavjud xona turlarini topish. 3. Bronni yozib qo'yish. 4. Bronni yoki o'tgan tarixni qidirish.

**Nima uchun relatsion ma'lumotlar bazasi:** - O'qishga intensiv, kamroq yozish ish oqimi (foydalanuvchilar ko'rib chiqishi >> foydalanuvchilar bron qilishi). - ACID kafolatlari — ikki marta bron qilish, manfiy balans, ikki marta to'lovni oldini olish uchun muhim. - Aniq, barqaror ma'lumot modeli va yaxshi belgilangan munosabatlar (mehmonxona, xona, xona_turi).

**Dastlabki sxema (2-rasm):** mehmonxona → xona → bron jadvallari. Bron jadvalidagi `status` maydoni 3-rasmdagi holat mashinasiga amal qiladi (kutish → to'langan/bekor qilingan → qaytarilgan/rad etilgan).

**Muhim cheklov:** Bu sxema bronlarni muayyan xonalarga bog'laydi (room_id). Ammo mehmonxonalarda mijozlar muayyan xona emas, *xona turi* ni bron qiladi. Xona raqamlari tekshiruv vaqtida tayinlanadi. Bu takomillashtirilgan ma'lumot modelida hal qilinadi (chuqur o'rganish).

Yuqori darajali dizayn

Mikroservis arxitekturasi (4-rasm):

- **Foydalanuvchi** — mobil yoki kompyuter orqali xona bron qiladi. - **Admin (mehmonxona xodimi)** — bronlarni, qaytarishlarni, xona ma'lumotlarini boshqaradi. - **CDN** — statik kontentni (JS, rasmlar, HTML) keshlab, yuklash tezligini oshiradi. - **Ochiq API shlyuzi** — so'rovlar chastotasini cheklash, autentifikatsiya, so'rovlarni xizmatlarga yo'naltirish. - **Ichki API lar** — faqat vakolatli xodimlarga ochiq, VPN bilan himoyalangan. - **Mehmonxona xizmati** — mehmonxona va xona tafsilotlari (asosan statik, osongina keshlanadi). - **Narx xizmati** — kelajakdagi sanalar uchun xona narxlari (dinamik narxlash). - **Bron xizmati** — bron so'rovlarini boshqaradi va xona inventarini kuzatadi. - **To'lov xizmati** — to'lovlarni amalga oshiradi, bron holatini yangilaydi (to'langan/rad etilgan). - **Mehmonxonani boshqarish xizmati** — xodim operatsiyalari: kelayotgan bronlarni ko'rish, xona bron qilish, bronlarni bekor qilish.

5-rasmda xizmatlar o'rtasidagi ulanishlar ko'rsatilgan: Bron xizmati jami xona to'lovini hisoblash uchun Narx xizmatiga murojaat qiladi; Mehmonxonani boshqarish xizmati so'rovlarni ma'lumotga egalik qiluvchi xizmatlarga yo'naltiradi.

Xizmatlar o'rtasidagi muloqot odatda zamonaviy, yuqori samarali RPC uchun gRPC dan foydalanadi.

3-qadam — Chuqur Dizayn

Takomillashtirilgan ma'lumot modeli

**Asosiy tushuncha:** Mijozlar muayyan xona emas, *xona turi* ni bron qiladi. Yangilangan bron API `roomID` o'rniga `roomTypeID` + `roomCount` dan foydalanadi.

**Yangilangan so'rov:** ```json { "startDate": "2021-04-28", "endDate": "2021-04-30", "hotelID": "245", "roomTypeID": "12354673389", "roomCount": "3", "reservationID": "13422445" } ```

**Yangilangan sxema (6-rasm)** muhim `room_type_inventory` jadvalini kiritadi:

| Ustun | Tavsif | |-------|--------| | hotel_id | Mehmonxona identifikatori | | room_type_id | Xona turi identifikatori | | date | Yagona sana (har sana uchun bitta qator) | | total_inventory | Jami xonalar minus vaqtincha oflayn olingan xonalar | | total_reserved | Ushbu mehmonxona/tur/sana uchun bron qilingan jami xonalar |

**Murakkab birlamchi kalit:** (hotel_id, room_type_id, date)

Qatorlar 2 yil ichidagi barcha kelajak sanalar uchun oldindan to'ldiriladi; kunlik ish oynani siljitadi.

**Bron tekshirish so'rovi:** ```sql SELECT date, total_inventory, total_reserved FROM room_type_inventory WHERE room_type_id = ${roomTypeId} AND hotel_id = ${hotelId} AND date BETWEEN ${startDate} AND ${endDate} ```

Har bir qator uchun: `if (total_reserved + numberOfRoomsToReserve) <= total_inventory` → xona mavjud.

**10% ortiqcha bron:** shartni `<= 110% * total_inventory` ga o'zgartirish.

**Saqlash taxmini:** 5 000 mehmonxona × 20 xona turi × 2 yil × 365 kun = **73 million qator** — replikalari bilan bitta MB ga sig'adi.

Bir vaqtdalilik muammolari

**1-muammo: Bir xil foydalanuvchi "bron qilish" tugmasini bir necha marta bosadi (7-rasm).**

Yechimlar: - **Mijoz tomoni:** Bosishdan keyin yuborish tugmasini kulranglash/o'chirish. Ishonchsiz — foydalanuvchilar JavaScript ni chetlab o'tishi mumkin. - **Idempotent API (8-rasm):** Idempotentlik kaliti sifatida `reservationID` ni qo'shish. `reservationID` bron jadvalining birlamchi kaliti bo'lgani uchun, noyoblik chegarasi dublikat qatorlarni oldini oladi.

**Oqim:** 1. Mijoz bron tafsilotlarini kiritadi → "Davom etish" ni bosadi → global noyob `reservationID` bilan bron buyurtmasi yaratiladi. 2. Tasdiqlash sahifasi (9-rasm) `reservationID` bilan buyurtma tafsilotlarini ko'rsatadi. 3. Mijoz "Bronimni yakunlash" ni bosadi — `reservationID` birlamchi kalit sifatida yuboriladi. 4. Ikki marta bosilsa, ikkinchi kiritish birlamchi kalit noyobligini buzadi → rad etiladi (10-rasm).

**2-muammo: Faqat 1 ta qolganda bir nechta foydalanuvchi bir xil xonani bron qiladi (11-rasm).**

Poygali holat: ikkita tranzaksiya ham `total_reserved = 99` (1 xona qolgan) ni o'qiydi, ikkalasi ham tekshiruvdan o'tadi, ikkalasi ham commit qiladi → 100 inventarga qarshi 101 ta bron qilingan.

Uchta qulflash strategiyasi:

**1-variant: Pessimistik qulflash (12-rasm)** `SELECT ... FOR UPDATE` tranzaksiya davomida qatorlarni qulflaydi. - Afzalliklari: Nizolarni oldini oladi, amalga oshirish oddiy, kuchli raqobatda samarali. - Kamchiliklari: Deadlock xavfi, kengaytirish imkonsiz (uzoq saqlanadigan qulflar boshqa tranzaksiyalarni to'sadi). - Xulosa: Bu tizim uchun **tavsiya etilmaydi**.

**2-variant: Optimistik qulflash (13-rasm)** `version` ustunini qo'shadi. Versiyani o'qing → yangilang → `version + 1` bilan yozing. Ma'lumotlar bazasi versiya mos kelmasa yozishni rad etadi. - Afzalliklari: MB qulflari yo'q, raqobat past bo'lganda yaxshi ishlaydi. - Kamchiliklari: Kuchli raqobatda samaradorlik pasayadi — takroriy urinishlar foydalanuvchi tajribasini yomonlashtiradi. - Xulosa: Mehmonxona bron QPS odatda past bo'lgani uchun **yaxshi variant**.

**3-variant: Ma'lumotlar bazasi chegarasi (14-rasm)** ```sql CONSTRAINT check_room_count CHECK((total_inventory - total_reserved >= 0)) ``` Buzilish → tranzaksiya bekor qilinadi. - Afzalliklari: Amalga oshirish oson, past raqobatda samarali. - Kamchiliklari: Kuchli raqobat ko'p nosozliklarga olib keladi, chegara versiya nazorat ostida emas, barcha MB lar ularni qo'llab-quvvatlamaydi. - Xulosa: Past QPS li mehmonxona bronlari uchun **yaxshi variant**.

Kengaytirilishi

Katta miqyosli sayohat saytlari (booking.com, expedia.com) uchun QPS 1 000 martaga yuqori bo'lishi mumkin. Barcha xizmatlar holatsiz va gorizontal kengayadi. Ma'lumotlar bazasi to'siq hisoblanadi.

**Ma'lumotlar bazasini bo'laklash (15-rasm):** - Ko'pgina so'rovlar `hotel_id` bo'yicha filtrlaydi → `hotel_id` bo'yicha bo'laklash. - 16 bo'lak: 30 000 QPS / 16 = **har bir bo'lakda 1 875 QPS** (MySQL sig'imi doirasida). - Bo'lak kaliti: `hash(hotel_id) % number_of_servers`.

**Keshlash (16-rasm):** - Mehmonxona inventari vaqt chegaralangan — faqat joriy va kelajakdagi sanalar muhim; eski ma'lumotlar ahamiyatsiz. - Optimal xotira foydalanishi uchun TTL + LRU evakuatsiya bilan **Redis** dan foydalanish. - Inventar tekshirish mantiqini keshga ko'chirish: `kalit = hotelID_roomTypeID_{date}`, `qiymat = mavjud xonalar`. - O'qish operatsiyalari (inventar tekshirish) >> yozish operatsiyalari (bron qilish) → kesh ko'pgina o'qishlarni o'z zimmasiga oladi.

**CDC orqali kesh izchilligi (O'zgarishlar Ma'lumotlarini Qo'lga Olish):** 1. Avval MB yangilanadi (haqiqat manbasi). 2. O'zgarish CDC orqali Redis ga asinxron ravishda tarqatiladi (masalan, **Debezium** manba konnektori).

**Kesh izchilsizligini boshqarish:** Kesh xona mavjud desa, lekin MB to'liq desa → foydalanuvchi MB tasdiqlashida xato oladi. Qabul qilinadi — MB har doim yakuniy maqom hisoblanadi. Izchilsizlik qisqa muddatli va o'z-o'zidan tuzaladi.

Xizmatlar o'rtasidagi ma'lumot izchilligi

**Pragmatik yondashuv (bizning dizaynimiz):** Bron xizmati bron va inventar API larini ham boshqaradi, har ikki jadval **bir xil relatsion ma'lumotlar bazasida** saqlanadi. Bu bir vaqtdalikni munosib boshqarish uchun ACID xususiyatlaridan foydalanadi.

**Sof mikroservis muqobili (17-19-rasmlar):** Har bir xizmatning o'z MB si bor. Yagona mantiqiy operatsiya (xona bron qilish + to'lovni yozish) bir nechta xizmatni qamrab oladi → yagona tranzaksiyadan foydalanib bo'lmaydi.

**Muammo (19-rasm):** Inventar yangilanishi muvaffaqiyatli bo'lsa, lekin bron MB muvaffaqiyatsiz bo'lsa, inventar o'zgarishini bekor qilish uchun qoplashtiruvchi tranzaksiyalar kerak. Ko'plab nosozlik holatlari → ma'lumot izchilsizligi.

**Taqsimlangan izchillik uchun sanoat texnikalari:** - **Ikki bosqichli commit (2PC):** Bir nechta nodelar bo'ylab atomik commit (hammasi muvaffaqiyatli yoki hammasi muvaffaqiyatsiz). Blokirovka protokoli — bitta node xarobiyaligi jarayonni to'xtatadi. Samarali emas. - **Saga:** Lokal tranzaksiyalar ketma-ketligi. Har bir qadam keyingisini ishga tushirish uchun xabar e'lon qiladi. Nosozlikda qoplashtiruvchi tranzaksiyalar oldingi qadamlarni bekor qiladi. Yakuniy izchillikka tayanadi (2PC ning kuchli izchilligiga nisbatan).

**Qaror:** Taqsimlangan izchillikning qo'shimcha murakkabligi bu tizim uchun arzimaydi. Inventar va bron ma'lumotlarini bir xil relatsion MB da saqlaymiz.

4-qadam — Yakunlash

Asosiy dizayn mavzulari: idempotentlik kalitlari bilan API dizayni, room_type_inventory ma'lumot modeli, uchta bir vaqtdalilik yechimi (pessimistik qulflash, optimistik qulflash, MB chegaralari), ko'lam uchun ma'lumotlar bazasini bo'laklash va Redis keshlash, mikroservislarda taqsimlangan izchillik uchun 2PC va Saga.

Biz Gmail, Outlook yoki Yahoo Mail kabi katta miqyosli elektron pochta xizmatini (1-rasm) loyihalashtirmoqdamiz. 2020 yilda Gmail ning 1,8 milliarddan ortiq faol foydalanuvchisi, Outlook ning esa dunyo bo'ylab 400 milliondan ortiq foydalanuvchisi bor edi.

1-qadam — Muammoni Tushunish va Loyiha Doirasini Belgilash

**Ko'lam:** 1 milliard foydalanuvchi.

**Doiradagi xususiyatlar:** - Elektron pochta yuborish va qabul qilish. - Barcha elektron pochtalarni olish. - O'qilgan/o'qilmagan holat bo'yicha filtrlash. - Mavzu, jo'natuvchi va matn bo'yicha qidirish. - Spam va virus himoyasi. - Elektron pochta qo'shimchalari qo'llab-quvvatlanadi. - Mijoz-server aloqasi uchun HTTP protokoli (API uchun eski SMTP/POP/IMAP emas).

**Funktsional bo'lmagan talablar:** - **Ishonchlilik:** Elektron pochta ma'lumotlari yo'qolmasin. - **Mavjudlik:** Ma'lumotlar nodelar bo'ylab avtomatik replikatsiya qilinadi; tizim qisman nosozliklarga qaramay ishlaydi. - **Kengaytiriladigan:** Samaradorlik pasaymasdan o'sib borayotgan foydalanuvchi va elektron pochta hajmini ko'taradi. - **Moslashuvchanlik/Kengaytirilishi:** Xususiyatlarni qo'shish oson; eski POP/IMAP ning funksionalligi cheklanganligi sababli maxsus protokollar kerak bo'lishi mumkin.

**Taxminiy hisob-kitob:** - 1 milliard foydalanuvchi × kuniga 10 ta yuborilgan pochta ÷ 10⁵ soniya = yuborish uchun **100 000 QPS**. - 1 milliard foydalanuvchi × kuniga 40 ta qabul qilingan pochta × 365 kun × 50 KB metadata = **yiliga 730 PB metadata**. - Qo'shimchalar: 1 mlrd × 40 × 365 × 20% × 500 KB = **yiliga 1 460 PB**. - Xulosa: taqsimlangan ma'lumotlar bazasi yechimi talab etiladi.

2-qadam — Yuqori Darajali Dizayn Taklif Qilish va Rozilik Olish

Elektron pochta haqida asosiy bilimlar

**Elektron pochta protokollari:** - **SMTP** — Pochta serverlari o'rtasida elektron pochta yuborish uchun standart protokol. - **POP (Post Office Protocol)** — Elektron pochtalarni lokal qurilmaga yuklab oladi, serverdan o'chiradi; yagona qurilma kirishi; katta qo'shimchalar bilan butun elektron pochtani yuklab oladi. - **IMAP** — Ochilgunga qadar faqat sarlavhalarni yuklab oladi; elektron pochtalar serverda qoladi; ko'p qurilmadan kirish; individual hisoblar uchun eng keng qo'llaniladi. - **HTTPS/ActiveSync** — Vebpochta va mobil mijozlar uchun ishlatiladi (masalan, Microsoft ning maxsus ActiveSync).

**DNS MX yozuvlari (2-rasm):** Jo'natuvchi serverlar qabul qiluvchining domeni uchun MX yozuvlarini DNS dan so'raydi. Past ustuvorlik raqami = afzalroq. Asosiy server mavjud bo'lmasa yuqoriroq ustuvorlik raqamli serverlarga o'tish.

**Elektron pochta qo'shimchalari:** MIME (Ko'p Maqsadli Internet Pochta Kengaytmasi) yordamida Base64 kodlash orqali yuboriladi. Hajm chegaralari: Gmail 25 MB, Outlook 20 MB.

An'anaviy pochta serverlari

**An'anaviy oqim (3-rasm):** Alisa (Outlook) → SMTP → Outlook server → DNS → Gmail SMTP server → saqlash → IMAP/POP → Bobning Gmail mijozi.

**Saqlash (4-rasm):** Elektron pochtalar lokal fayl kataloglarida saqlanadi (har bir elektron pochta uchun bitta fayl). **Maildir** formati mashhur edi. Cheklovlar: - Milliardlab elektron pochtalar uchun kengayish imkoni yomon. - Murakkab fayl tuzilmasi → disk I/U to'siq. - Yuqori mavjudlik yo'q — disk shikastlanishi yoki server nosozliklari ma'lumot yo'qolishiga olib keladi.

An'anaviy protokollar (POP, IMAP, SMTP) zamonaviy xususiyatlar (iplar, yorliqlar, qidirish) yoki milliardlab foydalanuvchilar uchun mo'ljallanmagan.

Taqsimlangan pochta serverlari

**Elektron pochta API lari (vebpochta uchun HTTP/RESTful):** - `POST /v1/messages` — To, Cc, Bcc qabul qiluvchilariga elektron pochta yuborish. - `GET /v1/folders` — Barcha papkalarni olish (Hammasi, Arxiv, Qoralamalar, Belgilangan, Spam, Yuborilgan, Axlat). - `GET /v1/folders/{folder_id}/messages` — Papkadagi barcha xabarlar ro'yxati (sahifalangan). - `GET /v1/messages/{message_id}` — To'liq xabar tafsilotlarini olish (kim yubordi, kimga, mavzu, matn, o'qilganmi, qo'shimchalar).

**Yuqori darajali dizayn komponentlari (5-rasm):** - **Vebpochta** — Brauzer asosidagi interfeys. - **Veb serverlar** — Ommaga ochiq: kirish, ro'yxatdan o'tish, profil, barcha elektron pochta API so'rovlari. - **Real-vaqt serverlar** — Onlayn mijozlarga yangi elektron pochtalarni push qiluvchi holat saqlangan WebSocket serverlar. Brauzer mosligi uchun zaxira sifatida uzun-so'rov. - **Metadata ma'lumotlar bazasi** — Elektron pochta mavzusi, matni, kim yubordi/kimga, vaqt tamg'alarini saqlaydi. Maxsus yoki Cassandra ga o'xshash NoSQL. - **Qo'shimcha ombori** — Amazon S3 (ob'ekt ombori). 25 MB gacha qo'shimchalar. Cassandra mos emas (amaliy blob chegarasi <1 MB, kesh muammolari). - **Taqsimlangan kesh** — Yaqinda kelgan elektron pochtalarni keshlash uchun Redis (ko'pgina o'qishlar so'nggi xabarlar uchun). - **Qidiruv ombori** — To'liq matn qidirish uchun teskari indeks.

Elektron pochta yuborish oqimi

**Oqim (6-rasm):** 1. Foydalanuvchi "yuborish" ni bosadi → so'rov yukni muvozanatlashga boradi. 2. Yukni muvozanatlash so'rovlar chastotasini cheklaydi → veb serverlarga yo'naltiradi. 3. Veb server: - 3a. Elektron pochtani tekshiradi (hajm chegaralari, format). - 3b. Bir xil domen bo'lsa: spam/virus tekshiruvi → jo'natuvchining Yuborilgan papkasida va qabul qiluvchining Kiruvchi papkasida to'g'ridan-to'g'ri saqlaydi (tashqi SMTP shart emas). 4. Xabar navbatlari: - 4a. To'g'ri elektron pochta → chiquvchi navbat (katta qo'shimchalar S3 da havola bilan saqlanadi). - 4b. Noto'g'ri elektron pochta → xato navbati. 5. SMTP chiquvchi ishchilar navbatdan oladi → spam/virus tekshiruvi. 6. Elektron pochta jo'natuvchining Yuborilgan papkasida saqlanadi. 7. SMTP ishchilar elektron pochtani qabul qiluvchining pochta serveriga yetkazadi.

**Navbat afzalliklari:** Veb serverlarni SMTP ishchilaridan ajratadi; mustaqil kengaytirishga imkon beradi; trafik cho'qqilarini buferlashtiradi.

**Navbatni monitoring:** Qotib qolgan elektron pochtalar → sababni aniqlash: qabul qiluvchi server mavjud emas (eksponensial qayta urinishdan foydalanish) yoki yetarli iste'molchilar yo'q (ko'proq qo'shish).

Elektron pochta qabul qilish oqimi

**Oqim (7-rasm):** 1. Kiruvchi elektron pochta SMTP yukni muvozanatlashga keladi. 2. Yukni muvozanatlash SMTP serverlariga taqsimlaydi; noto'g'ri elektron pochtalar SMTP ulanish darajasida qaytariladi. 3. Katta qo'shimchalar navbatga qo'yishdan oldin S3 da saqlanadi. 4. Elektron pochta kiruvchi navbatga qo'yiladi (surjlarni buferlashtiradi, SMTP serverlardan ajratadi). 5. Pochta qayta ishlash ishchilar spam/viruslarni filtrlaydi. 6. Elektron pochta metadata MB da, Redis keshda va S3 da (qo'shimchalar) saqlanadi. 7. Qabul qiluvchi onlayn bo'lsa → WebSocket real-vaqt serverlariga push qilinadi. 8. WebSocket serverlar mijozga real vaqtda yetkazadi. 9. Oflayn foydalanuvchilar: elektron pochta saqlashda kutadi; mijoz qayta ulanishda RESTful API orqali oladi.

3-qadam — Chuqur Dizayn

Metadata ma'lumotlar bazasi

**Elektron pochta metadata xususiyatlari:** - Elektron pochta sarlavhalari: kichik, tez-tez kiriladigan. - Elektron pochta matnlari: kattaroq, kamdan-kam o'qiladi (odatda bir marta). - Pochta operatsiyalari foydalanuvchi boshiga (foydalanuvchilar arosi kirish yo'q). - Ma'lumotlar yangiligi: o'qishlarning 82% 16 kundan yoshroq elektron pochtalar uchun. - Yuqori ishonchlilik: ma'lumot yo'qolishi qabul qilinmaydi.

**Ma'lumotlar bazasi tanlovlari:** - **Relatsion (MySQL/PostgreSQL):** Yaxshi indekslash, lekin kichik ma'lumot yozuvlari uchun optimallashtirilgan; elektron pochta matnlari (>100 KB HTML) mos emas; BLOB qidirish samarasiz. - **Taqsimlangan ob'ekt ombori (S3):** Yaxshi zaxira, lekin o'qish/qidirish/iplar operatsiyalarini samarali qo'llab-quvvatlay olmaydi. - **NoSQL (Bigtable, Cassandra):** Bigtable Gmail tomonidan ishlatiladi, lekin ochiq manba emas; Cassandra mumkin, lekin hech qanday yirik elektron pochta provayderining undan foydalangani ma'lum emas.

**Maxsus ma'lumotlar bazasi talablari (suhbat javobi):** - Yagona ustun bir xonali MB bo'lishi mumkin. - Kuchli ma'lumot izchilligi. - Disk I/U ni kamaytirish uchun mo'ljallangan. - Yuqori mavjud va nosozliklarga chidamli. - Oson bosqichma-bosqich zaxiralash.

**Ma'lumot modeli — barcha foydalanuvchi ma'lumotlari bir bo'lakda bo'lishi uchun user_id bo'yicha bo'laklash:**

**1-jadval — Foydalanuvchi bo'yicha papkalar** (bo'lak kaliti: user_id): - Qo'llab-quvvatlaydi: foydalanuvchi uchun barcha papkalarni olish.

Ma'lumot modeli — so'rovlar

**2-jadval — Papka bo'yicha elektron pochtalar** (murakkab bo'lak kaliti: user_id + folder_id, klasterlash kaliti: vaqt tartibida saralash uchun TIMEUUID sifatida email_id): - Qo'llab-quvvatlaydi: papkadagi barcha elektron pochtalarni vaqt bo'yicha saralangan holda ro'yxatlash.

3-so'rov — Elektron pochta tafsilotlarini olish

**3-jadval — Foydalanuvchi bo'yicha elektron pochtalar** — qo'shimchalar bilan to'liq elektron pochta ma'lumotlari (email_id + fayl nomi bilan olinadi).

```sql SELECT * FROM emails_by_user WHERE email_id = 123; ```

4-so'rov — O'qilgan/o'qilmagan elektron pochtalar (NoSQL denormalizatsiyasi)

NoSQL da `is_read` bo'lak yoki klasterlash kaliti emas → samarali filtrlash mumkin emas. Yechim: ikkita jadvalga **denormalizatsiya** (4-jadval): - `read_emails` — barcha o'qilgan elektron pochtalarni saqlaydi. - `unread_emails` — barcha o'qilmagan elektron pochtalarni saqlaydi.

O'qilgan deb belgilash: `unread_emails` dan o'chirish, `read_emails` ga qo'shish.

```sql SELECT * FROM unread_emails WHERE user_id = <id> AND folder_id = <id> ORDER BY email_id; ```

Kompromi: murakkabroq dastur kodi, ko'lamda yaxshi o'qish samaradorligi.

**Qo'shimcha: Suhbat iplari** — JWZ algoritmi bilan elektron pochta sarlavha maydonlari (Message-Id, In-Reply-To, References) dan foydalanib, oldindan yuklangan javob zanjiri xabarlaridan ip zanjirlarini qayta tiklash.

**Izchillik kompromisi:** Har bir pochta qutisi uchun yagona asosiy — mavjudlikni izchillik evaziga almashtiradi. Almashtirish paytida, almashtirish tugaguncha pochta qutisiga kirish imkonsiz.

Elektron pochtani yetkazib berish

Elektron pochtalarni foydalanuvchilar kiruvchi qutisiga (spamga emas) yetkazish qiyin. Yuborilgan barcha elektron pochtalarning 50% dan ortiqrog'i spam.

**Asosiy omillar:** - **Maxsus IP lar** — Yangi IP manzillarning obro'si yo'q; tarixi bor maxsus IP lardan foydalanish. - **Elektron pochtalarni tasniflash** — Spam tasniflashni oldini olish uchun marketing va tranzaksion elektron pochtalar uchun alohida IP lar. - **Yangi IP larni isitish** — 2-6 hafta davomida (Amazon SES ko'rsatmasi bo'yicha) bosqichma-bosqich obro' qurish. - **Spamchilarni tezda bloklash** — Sezilarli ta'sirdan oldin obro' zararlanishini oldini olish. - **Fikr-mulohazalarni qayta ishlash (8-rasm):** ISP lar bilan fikr-mulohaza halqalarini o'rnatish. Jarayon: - **Qattiq qaytarish** — Noto'g'ri qabul qiluvchi manzil. - **Yumshoq qaytarish** — Vaqtinchalik yetkazib berish muammosi (ISP band). - **Shikoyat** — Foydalanuvchi "spam deb xabar berish" ni bosadi. - Mustaqil boshqarish uchun yumshoq qaytarish, qattiq qaytarish, shikoyatlar uchun alohida navbatlar.

**Elektron pochta autentifikatsiyasi (9-rasm — Gmail sarlavha misoli):** - **SPF** (Jo'natuvchi Siyosati Tizimi) — Jo'natuvchi IP ning domen nomidan yuborishga vakolatliligini tasdiqlaydi. - **DKIM** (Domen Kaliti Bilan Aniqlangan Pochta) — Xabar yaxlitligini tasdiqlash uchun kriptografik imzo. - **DMARC** (Domen Asosida Xabar Autentifikatsiyasi) — SPF + DKIM ni birlashtiruvchi siyosat tizimi.

Fishing va bahona qilish buzilishlarning 93% ini tashkil qiladi (Verizon 2018 hisoboti).

Qidiruv

Google qidiruviga nisbatan elektron pochta qidirish xususiyatlari: | Xususiyat | Google Qidiruv | Elektron Pochta Qidirish | |-----------|---------------|-------------------------| | Doira | Butun internet | Foydalanuvchining o'z pochta qutisi | | Saralash | Dolzarblik bo'yicha | Vaqt, qo'shimcha, o'qilmagan va h.k. bo'yicha | | Aniqlik | Ba'zi indekslash kechikishi qabul qilinadi | Real vaqtga yaqin, aniq bo'lishi shart |

Elektron pochta qidirish **yozishga intensiv** (har yuborish/qabul qilish/o'chirishda qayta indekslash); so'rovlar nisbatan kam.

**1-variant: Elasticsearch (10-rasm)** - Asosiy hujjatlarni user_id bo'yicha bo'laklash → barcha foydalanuvchi ma'lumotlari bir nodeda. - Qayta indekslash oflayn ishlar orqali asinxron bajariladi; Kafka trigger hodisalarini qayta indekslash ishchilaridan ajratadi. - Qidiruv so'rovlari sinxron (foydalanuvchi natijalarni kutadi). - Tencent QQ Email tomonidan ko'lamda ishlatiladi.

**2-variant: LSM daraxti bilan maxsus qidiruv (11-rasm)** - Gmail/Outlook miqyosi uchun maxsus qidiruv tizimlari keng tarqalgan. - **LSM (Jurnal Tuzilmali Birlashtirish Daraxti):** Faqat ketma-ket yozishlar orqali yozishga intensiv ish yuki uchun optimallashtirilgan. - Yangi elektron pochta → 0-darajali xotira keshdagi → chegara yetganda keyingi darajaga birlashtirish. - Tez-tez o'zgaruvchi ma'lumotlarni (papka ma'lumoti) barqaror ma'lumotlardan (elektron pochta mazmuni) ajratadi. - BigTable, Cassandra, RocksDB da ishlatiladi.

| Xususiyat | Elasticsearch | Maxsus qidiruv tizimi | |-----------|---------------|----------------------| | Kengaytirilishi | Ma'lum darajada kengaytiriladi | Osonroq (elektron pochtaga xos optimizatsiyalar) | | Murakkablik | Ikki tizim (ma'lumot ombori + ES) | Bir tizim | | Ma'lumot izchilligi | Ikki nusxa, sinxronlashtirish qiyin | Yagona nusxa | | Ma'lumot yo'qolishi | Yo'q (asosiydan qayta qurish) | Yo'q | | Ishlab chiqish sa'yi | Oson integratsiya | Sezilarli muhandislik |

**Umumiy qoida:** Kichikroq miqyos uchun Elasticsearch; Gmail/Outlook miqyosi uchun mahalliy o'rnatilgan qidiruv.

Kengaytirilishi va mavjudligi

Aksariyat komponentlar holatsiz va gorizontal kengayadi (foydalanuvchi ma'lumotlariga kirish namunalari mustaqil).

Yuqori mavjudlik uchun ma'lumotlar bir nechta ma'lumot markazlari bo'ylab replikatsiya qilinadi (12-rasm). Foydalanuvchilar geografik jihatdan eng yaqin pochta serveriga ulanadi. Tarmoq bo'linishi paytida foydalanuvchilar boshqa ma'lumot markazlaridan xabarlarga kira oladi.

4-qadam — Yakunlash

Asosiy dizayn mavzulari: an'anaviy va taqsimlangan pochta server evolyutsiyasi, HTTP API dizayni, navbatlar bilan elektron pochta yuborish/qabul qilish oqimlari, denormalizatsiya bilan NoSQL ma'lumot modeli, elektron pochtani yetkazib berish (SPF/DKIM/DMARC), Elasticsearch va LSM asosidagi maxsus qidiruv, ko'p ma'lumot markazi replikatsiyasi.

Qo'shimcha muhokama nuqtalari: nosozliklarga chidamlilik (node nosozliklari, tarmoq muammolari), muvofiqlik (GDPR, qonuniy ushlab qolish), xavfsizlik (Gmail xavfsizlik xususiyatlari), qo'shimchalarni deduplikatsiya qilish (guruh elektron pochtalar uchun S3 da dublikat ob'ektlarni saqlashdan oldin mavjudligini tekshirish).

Biz Amazon S3 ga o'xshash ob'ekt ombori xizmatini loyihalashtirmoqdamiz. Asosiy bosqichlar: 2006 yilda ishga tushirildi, 2010 yilda versiyalash/ko'p qismli yuklash qo'shildi, 2013 yilga kelib 2 trillion ob'ekt, 2021 yilga kelib 100 trillion ob'ekt.

Saqlash tizimlari haqida asosiy bilimlar

Saqlashning uchta keng toifasi (1-rasm):

**Blok ombori** (1960-yillar): Jismoniy yoki tarmoq orqali ulangan xom bloklar (HDD, SSD). VM lar, ma'lumotlar bazalari, yuqori samarali dasturlar tomonidan qo'llaniladi. SAS/iSCSI/FC orqali kiriladigan. O'zgaruvchan, yuqori samaradorlik, o'rtacha kengaytirilishi, yuqori narx.

**Fayl ombori**: Blok omborida qurilgan. Ierarxik katalog tuzilmasi. SMB/CIFS, NFS orqali kiriladigan. Umumiy maqsadli. O'zgaruvchan, o'rtacha-yuqori samaradorlik va kengaytirilishi.

**Ob'ekt ombori**: Yangi. Yuqori ishonchlilik, ulkan ko'lam, past narx evaziga samaradorlikni qurbon qiladi. Tekis tuzilma (ierarxiya yo'q). RESTful API kirishi. O'zgarmas (versiyalash qo'llab-quvvatlanadi, o'rnida yangilash yo'q). Sovuq ma'lumotlar, arxiv, zaxira uchun. AWS S3, Google Cloud Storage, Azure Blob.

**S3 ning asosiy terminologiyasi:** - **Bucket** — Ob'ektlar uchun mantiqiy konteyner; global noyob nom; yuklashdan oldin yaratilishi kerak. - **Ob'ekt** — Alohida ma'lumot bo'lagi (yuk + metadata kalit-qiymat juftliklari). - **Versiyalash** — Ob'ektning bir nechta variantlarini saqlash; bucket boshiga yoqiladi; tasodifiy o'chirish/ustiga yozishdan tiklashga imkon beradi. - **URI** — Har bir resurs (bucket/ob'ekt) URI bilan noyob tarzda aniqlanadi. - **SLA** — S3 Standard-Kam Foydalanish: 99,999999999% (11 to'qqizlik) ishonchlilik, 99,9% mavjudlik.

1-qadam — Muammoni Tushunish va Loyiha Doirasini Belgilash

**Xususiyatlar:** Bucket yaratish, ob'ekt yuklash/yuklab olish, ob'ektni versiyalash, bucket dagi ob'ektlarni ro'yxatlash.

**Ma'lumot o'lchamlari:** Katta ob'ektlar (GB) ham, ko'plab kichik ob'ektlar (o'nlab KB) ham.

**Funktsional bo'lmagan talablar:** - **100 PB** ma'lumot saqlash. - **6 to'qqizlik** ma'lumot ishonchliligi (99,9999%). - **4 to'qqizlik** xizmat mavjudligi (99,99%). - Saqlash samaradorligi: ishonchlilikni saqlab narxni kamaytirish.

**Taxminiy hisob-kitob:** - Ob'ekt taqsimoti: 20% kichik (<1 MB), 60% o'rtacha (1-64 MB), 20% katta (>64 MB). - 40% saqlash foydalanishida medianalar (0,5 MB, 32 MB, 200 MB) yordamida: - 10¹¹ × 0,4 / (0,2×0,5 + 0,6×32 + 0,2×200) ≈ **0,68 milliard ob'ekt**. - Ob'ekt boshiga 1 KB metadata: barcha metadata uchun **0,68 TB**. - IOPS to'siq: aylanuvchi disk (7200 ayl/daqiqa SATA) ≈ 100-150 IOPS.

2-qadam — Yuqori Darajali Dizayn Taklif Qilish va Rozilik Olish

**Ob'ekt omborining asosiy xususiyatlari:** - **O'zgarmaslik** — Ob'ektlarni o'chirish yoki to'liq almashtirish mumkin, lekin qisman o'zgartirish mumkin emas. - **Kalit-qiymat ombori** — URI kalit, ob'ekt ma'lumotlari qiymat. - **Bir marta yoz, ko'p marta o'qi** — So'rovlarning 95% o'qish (LinkedIn tadqiqoti). - **Kichik va katta ob'ektlarni qo'llab-quvvatlaydi.**

**UNIX fayl tizimi bilan o'xshashlik (2-rasm):** - UNIX: inode dagi fayl nomi → inode blok ko'rsatgichlari → diskdagi ma'lumotlar. - Ob'ekt ombori: metadata omborida ob'ekt nomi → metadata ob'ekt IDga moslashtiradi → tarmoq orqali ma'lumotlar omborida ma'lumot. - Metadata ombori ≈ inode (o'zgaruvchan). Ma'lumot ombori ≈ disk (yozilgandan keyin o'zgarmas). - Ajratish har bir komponentni mustaqil optimallashtirish imkonini beradi.

3-rasmda bucket va ob'ekt munosabati ko'rsatilgan.

Yuqori darajali dizayn

**Komponentlar (4-rasm):** - **Yukni muvozanatlash** — RESTful API so'rovlarini API serverlar bo'ylab taqsimlaydi. - **API xizmati** — Holatsiz orkestratori; IAM, metadata ombori va ma'lumot omboriga murojaat qiladi. Gorizontal kengayadi. - **IAM (Shaxsni va Kirishni Boshqarish)** — Autentifikatsiya (kim ekanligingiz) + Avtorizatsiya (nima qila olishingiz). - **Ma'lumot ombori** — UUID bo'yicha haqiqiy ob'ekt ma'lumotlarini saqlaydi/oladi. O'zgarmas ob'ektlar. - **Metadata ombori** — Ob'ekt metadatasini saqlaydi (ob'ekt nomi, bucket, UUID, vaqt tamg'alari).

Ob'ektni yuklash

**7 qadamli yuklash oqimi (5-rasm):** 1. Mijoz bucket yaratish uchun HTTP PUT yuboradi. 2. API xizmati YOZISH ruxsatini tekshirish uchun IAM ga murojaat qiladi. 3. API xizmati metadata MB da bucket yozuvi yaratadi → muvaffaqiyat qaytaradi. 4. Mijoz ob'ekt yuklash uchun HTTP PUT yuboradi (masalan, `script.txt`). 5. API xizmati shaxsni va bucket dagi YOZISH ruxsatini tekshiradi. 6. API xizmati ob'ekt ma'lumotlarini ma'lumot omboriga yuboradi → UUID oladi. 7. API xizmati metadata yozuvi yaratadi: `{object_id (UUID), bucket_id, object_name}`.

```http PUT /bucket-to-share/script.txt HTTP/1.1 Content-Type: text/plain Content-Length: 4567 [4567 bayt ob'ekt ma'lumotlari] ```

Ob'ektni yuklab olish

**Yuklab olish oqimi (6-rasm):** 1. Mijoz: `GET /bucket-to-share/script.txt` 2. API xizmati IAM orqali O'QISH ruxsatini tekshiradi. 3. API xizmati metadata omboridan ob'ekt UUID ni oladi (bucket+ob'ekt nomi bo'yicha). 4. API xizmati ma'lumot omboridan UUID bo'yicha ob'ekt ma'lumotlarini oladi. 5. Ob'ekt ma'lumotlari mijozga qaytariladi.

Bucket larda katalog ierarxiyasi yo'q — `/` ajratilgan ob'ekt nomlari (masalan, `abc/d/e/file.txt`) yordamida papkalarni taqlid qilish.

3-qadam — Chuqur Dizayn

Ma'lumot ombori

7-rasmda API xizmati va ma'lumot ombori o'rtasidagi muloqot ko'rsatilgan. Ma'lumot omborining uchta asosiy komponenti bor (8-rasm):

**Ma'lumot yo'naltirish xizmati** — Holatsiz; eng yaxshi ma'lumot nodeni topish uchun joylashtirish xizmatiga murojaat qiladi; ma'lumot nodelariga ma'lumot o'qiydi/yozadi.

**Joylashtirish xizmati** — Har bir ob'ektni qaysi ma'lumot nodlari (asosiy + replikalar) saqlashini belgilaydi. Jismoniy topologiya bilan **virtual klaster xaritasini** (9-rasm) saqlaydi. Nodelarni yurak urishi orqali kuzatadi (15 soniyalik oraliq). Muhim xizmat — Paxos yoki Raft konsensusdan foydalangan holda 5-7 nodelik klaster.

**Ma'lumot node** — Haqiqiy ob'ekt ma'lumotlarini saqlaydi. Ma'lumot xizmati daemonini ishlatadi; joylashtirish xizmatiga yurak urishlarini yuboradi (disk soni, disk boshiga ma'lumot). Ishonchlilik uchun replikatsiya guruh a'zolariga ma'lumotlarni nusxalaydi.

Ma'lumotlarni saqlash oqimi

**5 qadamli saqlash oqimi (10-rasm):** 1. API xizmati ob'ekt ma'lumotlarini ma'lumot omboriga yuboradi. 2. Ma'lumot yo'naltirish xizmati UUID yaratadi, joylashtirish xizmatiga murojaat qiladi → asosiy ma'lumot nodini oladi (ketma-ket xeshlash orqali). 3. Ma'lumot yo'naltirish xizmati ma'lumot + UUID ni asosiy ma'lumot nodiga yuboradi. 4. Asosiy lokal saqlaydi va 2 ta ikkinchi darajali nodega nusxalaydi; faqat barcha replikalar tasdiqlangandan keyin javob beradi. 5. UUID API xizmatiga qaytariladi.

**Izchillik va kechikish kompromisi (11-rasm):** - 3 ta node ham saqlaydi → eng yaxshi izchillik, eng yuqori kechikish. - Asosiy + 1 ikkinchi darajali → o'rtacha izchillik + kechikish. - Faqat asosiy → eng yomon izchillik, eng past kechikish (2 va 3 variant yakuniy izchillik).

Ma'lumotlar qanday tartiblanadi

**Ob'ekt boshiga bitta fayl muammosi:** Kichik fayllar uchun disk bloklarini isrof qiladi (minimal 4 KB); inode sig'imini tugatashmaydi; OS katta inode sonlarini yomon boshqaradi.

**Yechim: Kichik ob'ektlarni katta fayllarga birlashtirish (12-rasm)** — Oldinga yozish jurnali (WAL) kabi ishlaydi: - Ob'ektlar o'qish-yozish fayliga ketma-ket qo'shiladi. - Fayl chegara (bir necha GB) ga yetganda → faqat o'qish uchun belgilanadi, yangi o'qish-yozish fayli yaratiladi. - Faqat o'qish uchun fayllar faqat o'qishga xizmat qiladi. - O'qish-yozish fayliga yozish kirishini ketma-ket bajarish; o'tkazuvchanlikni oshirish uchun har bir CPU yadrosi uchun bitta fayl.

**Ob'ektni qidirish** — Ma'lumot node mahalliy SQLite ma'lumotlar bazasida moslashtirishni saqlaydi (3-jadval): | Maydon | Tavsif | |--------|--------| | object_id | UUID | | file_name | Ob'ektni o'z ichiga olgan ma'lumot fayli | | start_offset | Fayldagi bayt ofseti | | object_size | Baytlardagi ob'ekt hajmi |

SQLite RocksDB dan afzal ko'rilgan: B+ daraxti yaxshiroq o'qish samaradorligini ta'minlaydi (bir marta yoz, ko'p marta o'qi namunasi).

Yangilangan ma'lumotlarni saqlash oqimi

**Yangilangan 4 qadamli oqim (13-rasm):** 1. API xizmati "4-ob'ektni" saqlashni so'raydi. 2. Ma'lumot node `/data/c` o'qish-yozish faylining oxiriga 4-ob'ektni qo'shadi. 3. `object_mapping` jadvaliga (SQLite) yangi yozuv kiritiladi. 4. UUID API xizmatiga qaytariladi.

Ishonchlilik

**3 nusxa replikatsiya:** Yillik disk nosozligi darajasi ~0,81% → 1-(0,0081)³ ≈ **6 to'qqizlik ishonchlilik**.

**Nosozlik domenlari:** Rack darajasi, node darajasi nosozlik domenlari. Katta miqyosli nosozliklardan (elektr uzilishlari, tabiiy ofatlar) himoya uchun replikalar turli Mavjudlik Zonalarida (14-rasm) joylashtiriladi.

**O'chirish kodlash (15-rasm — 4+2 misol):** - Ma'lumotlar 4 bo'lakka bo'linadi (d1-d4). - Matematik formula yordamida 2 ta paritet bo'lagi hisoblanadi (p1, p2). - Har qanday 2 bo'lak yo'qolsa ham asl ma'lumotlarni tiklash mumkin.

**8+4 o'chirish kodlash (16-rasm):** 12 ta nosozlik domeni bo'ylab 12 bo'lak; har qanday 4 ta node nosozligiga chidaydi.

**Saqlash ortiqcha xarajat taqqoslash (17-rasm):** - 3 nusxa replikatsiya: **200% ortiqcha xarajat**. - 8+4 o'chirish kodlash: **50% ortiqcha xarajat**. - O'chirish kodlash replikatsiyaning 6 to'qqizligiga nisbatan **11 to'qqizlik ishonchliligi** ni ta'minlaydi.

**Replikatsiya va o'chirish kodlash kompromislari:** | | Replikatsiya | O'chirish kodlash | |--|------------|------------------| | Ishonchlilik | 6 to'qqizlik | 11 to'qqizlik | | Saqlash ortiqcha xarajat | 200% | 50% | | Hisoblash | Yo'q | Yuqori (paritet hisoblash) | | Yozish samaradorligi | Tezroq | Sekinroq (paritetlarni hisoblash) | | O'qish samaradorligi | Tez (yagona node) | Sekinroq (8+ node, nosozlikda tiklash) |

**Qoida:** Kechikishga sezgir dasturlar uchun replikatsiya; narx uchun optimallashtirilgan saqlash uchun o'chirish kodlash.

To'g'rilikni tekshirish (nazorat yig'indilari)

Xotiradagi ma'lumot buzilishi katta miqyosli tizimlarda keng tarqalgan. Nazorat yig'indilari orqali aniqlash.

**Nazorat yig'indisini yaratish (18-rasm):** Ob'ekt ma'lumotlaridan MD5, SHA1 yoki HMAC yordamida hisoblanadi. Yaxshi algoritmlar hatto kichik kirish o'zgarishlari uchun ham sezilarli farqli natijalar beradi.

**Nazorat yig'indisini taqqoslash (19-rasm):** Uzatishdan keyin qayta hisoblash va taqqoslash: - Mos keladi → ma'lumot butun. - Mos kelmaydi → ma'lumot buzilgan → boshqa nosozlik domenidan o'qish.

**Tartib (20-rasm):** Har bir ob'ektdan keyin nazorat yig'indisi qo'shiladi; faqat o'qish faylining oxirida fayl darajasidagi nazorat yig'indisi.

**8+4 o'chirish kodlash bilan:** 8 ta ma'lumot bo'lagi + nazorat yig'indilari olish → har birini tekshirish → buzilgan bo'lsa tiklash → mijozga qaytarish.

Metadata ma'lumot modeli

**Qo'llab-quvvatlanadigan uchta so'rov:** 1. Ob'ekt nomi bo'yicha ob'ekt IDsini topish. 2. Ob'ekt nomi bo'yicha ob'ekt kiritish/o'chirish. 3. Prefiksni umumlashtiradigan bucket dagi ob'ektlarni ro'yxatlash.

**Sxema (21-rasm): Ikkita jadval — `bucket` va `object`.**

- `bucket` jadvali: kichik (1 million mijoz × 10 bucket × 1 KB ≈ 10 GB). Yagona MB ga sig'adi; o'qishlarni replika bilan kengaytirish. - `object` jadvali: katta. Bo'laklash zarur.

**Bo'lak kaliti: hash(bucket_name + object_name)** - Faqat bucket_id bo'yicha emas → issiq nuqta xavfi (milliardlab ob'ektli bucket lar). - Faqat object_id bo'yicha emas → URI asosidagi so'rovlarni qo'llab-quvvatlay olmaydi (ko'pgina operatsiyalar ob'ekt nomini ishlatadi). - Birlashtirilgan kalit → teng taqsimot + URI asosidagi so'rov qo'llab-quvvatlamasi.

Bucket dagi ob'ektlarni ro'yxatlash

S3 katalog tuzilmasini taqlid qilish uchun **prefikslardan** foydalanadi. Ob'ekt nomi: `abc/d/e/f/file.txt` → prefiks: `abc/d/e/f/`.

**Uchta ro'yxatlash rejimi:** 1. `aws s3 list-buckets` — Foydalanuvchiga tegishli barcha bucket larni ro'yxatlash. 2. `aws s3 ls s3://mybucket/abc/` — Prefiks darajasida ro'yxatlash; chuqurroq yo'llar umumiy prefiksga yig'iladi. 3. `aws s3 ls s3://mybucket/abc/ --recursive` — Prefiksni umumlashtiradigan barcha ob'ektlarni rekursiv ro'yxatlash.

**Yagona ma'lumotlar bazasi:** Oddiy LIKE so'rovi: `SELECT * FROM object WHERE bucket_id = '123' AND object_name LIKE 'abc/%'`

**Taqsimlangan bo'laklangan ma'lumotlar bazasi muammosi:** Ob'ektlar bo'laklar bo'ylab taqsimlangan → barcha bo'laklarni so'rash, natijalarni birlashtirish. Sahifalash murakkab (har bir bo'lakda kuzatiladigan turli ofset bor).

**Bo'laklangan ro'yxatlash uchun yechim:** Ro'yxatlash ma'lumotlarini bucket_id bo'yicha bo'laklangan alohida jadvalga denormalizatsiya qilish. Ro'yxatlash so'rovlari faqat ushbu jadvalga tegadi (yagona bo'lak qidirish). Ob'ektlarni ro'yxatlash samaradorligi S3 ga o'xshash tizimlarda ustuvorlik emas — barcha tijorat ob'ekt omborlarida ro'yxatlash samaradorligi yomon.

Ob'ektni versiyalash

Ob'ektning bir nechta versiyasini saqlaydi; tasodifan o'chirilgan/ustiga yozilgan fayllarni tiklaydi. Har bir bucket uchun yoqilishi kerak.

**Versiyalangan yuklash oqimi (22-rasm):** 1. Mijoz: `PUT script.txt` 2. API xizmati YOZISH ruxsatini tekshiradi. 3. Ma'lumot ombori yangi ob'ektni saqlaydi → yangi UUID qaytaradi. 4. API xizmati metadatani saqlaydi. 5. Ustiga yozish o'rniga: bir xil `bucket_id` + `object_name` bilan, lekin yangi `object_id` va `object_version` (TIMEUUID) bilan yangi qator kiritiladi. Joriy versiya = eng katta TIMEUUID (23-rasm).

**Versiyalangan ob'ektni o'chirish (24-rasm):** Barcha versiyalar bucket da qoladi; **o'chirish markeri** eng yangi versiya sifatida kiritiladi. O'chirish markeridagi GET so'rovi 404 Ob'ekt Topilmadi qaytaradi.

Katta fayllarni yuklashni optimallashtirish (ko'p qismli yuklash)

Katta ob'ektlar (GB) parallel bo'lakli yukdan foyda ko'radi. Tarmoq nosozligi butun yukni qaytadan boshlashni talab qilmaydi.

**Ko'p qismli yuklash oqimi (25-rasm):** 1. Mijoz ko'p qismli yukni boshlaydi → `uploadID` oladi. 2. Mijoz faylni bo'laklaydi (masalan, 1,6 GB ni 8 × 200 MB qismlarga). 3. Mijoz har bir qismni `uploadID` bilan yuklaydi → **ETag** (qismning MD5 nazorat yig'indisi) oladi. 4. Barcha qismlar yuklanganidan keyin mijoz `{uploadID, qism raqamlari, ETaglar}` bilan **ko'p qismli yukni yakunlash** so'rovini yuboradi. 5. Ma'lumot ombori qismlardan ob'ektni qayta yig'adi (bir necha daqiqa ketishi mumkin) → muvaffaqiyat qaytaradi.

Tark etilgan qismlar axlat to'plash xizmati tomonidan tozalanadi.

Axlat to'plash

Endi ishlatilmayotgan saqlashni qaytarib oladi. Axlat manbalari: - **Kechiktirilgan o'chirish** — Ob'ekt o'chirilgan deb belgilangan, lekin darhol olib tashlanmagan. - **Ota-onasiz ma'lumotlar** — Yarim yuklangan yoki tark etilgan ko'p qismli yuklar. - **Buzilgan ma'lumotlar** — Muvaffaqiyatsiz nazorat yig'indisi tekshiruvi.

**Siqish mexanizmi (26-rasm):** 1. Axlat to'plovchi eski `/data/b` faylidan yangi `/data/d` fayliga jonli ob'ektlarni nusxalaydi, `delete_flag = true` bo'lgan ob'ektlarni o'tkazib yuboradi. 2. `object_mapping` jadvalini yangilaydi (MB tranzaksiyasiga o'ralgan): `obj_id` va `object_size` ni saqlab, `file_name` va `start_offset` ni yangilaydi. 3. Yangi fayl kichikroq; ko'plab kichik fayllar yaratishdan qochish uchun siqishdan oldin ko'plab faqat o'qish uchun fayllarni kutadi.

Replika maydonini ham qaytarib oladi: barcha 3 nusxadan o'chirish (replikatsiya) yoki barcha 12 ta nodedan (8+4 o'chirish kodlash).

4-qadam — Yakunlash

Asosiy dizayn mavzulari: blok/fayl/ob'ekt ombori taqqoslash, metadata/ma'lumot ajratish uchun inode o'xshashlik, yuklash/yuklab olish oqimlari, ma'lumot node tashkili (WAL ga o'xshash fayl birlashtirish + SQLite moslashtiruv), replikatsiya va o'chirish kodlash ishonchliligi, nazorat yig'indisi tekshiruvi, (bucket_name + object_name) bo'yicha metadata bo'laklash, prefiks so'rovlari bilan ro'yxatlash, TIMEUUID bilan versiyalash, ko'p qismli yuklash, siqish bilan axlat to'plash.

Biz onlayn mobil o'yin uchun real-vaqtli reytingni (1-rasm) loyihalashtirmoqdamiz. Reyting o'yinchilarni g'alaba uchun to'plangan ballar bo'yicha tartiblashtiradi va eng yaxshi o'yinchilar hamda alohida foydalanuvchi reytinglarini ko'rsatadi.

1-qadam — Muammoni Tushunish va Loyiha Doirasini Belgilash

**Funktsional talablar:** - Reytingda **eng yaxshi 10 o'yinchini** ko'rsatish. - **Foydalanuvchining aniq reytingini** ko'rsatish. - Bonus: Muayyan foydalanuvchidan **4 pozitsiya yuqori va pastdagi o'yinchilarni** ko'rsatish. - Ball tizimi: har bir g'alaba uchun 1 ball; oylik turnir reytingni nolga tushiradi. - Bir xil ball → bir xil reyting.

**Ko'lam:** - **5 million kunlik faol foydalanuvchi**, 25 million oylik faol foydalanuvchi. - Har bir o'yinchi kuniga ~10 ta o'yin o'ynaydi.

**Funktsional bo'lmagan talablar:** - **Real-vaqtli** ball yangilanishlari (paketli natijalar qabul qilinmaydi). - Umumiy kengaytirilishi, mavjudligi, ishonchliligi.

**Taxminiy hisob-kitob:** - O'rtacha foydalanuvchilar/soniya: 5M / 10⁵ = **~50 foydalanuvchi/soniya**; cho'qqi (5x) = **250/soniya**. - Ball qo'shish uchun QPS: 50 × 10 = **500 QPS**; cho'qqi = **2 500 QPS**. - Eng yaxshi 10 ni olish uchun QPS: ~**50 QPS** (kundalik sessiyada bir marta yuklanadi).

2-qadam — Yuqori Darajali Dizayn Taklif Qilish va Rozilik Olish

API dizayni

**POST /v1/scores** — Foydalanuvchi o'yin g'alaba qilganda ballini yangilash. Faqat ichki API (o'yin serverlari chaqiradi, mijozlar emas — o'rtadagi hujumlar orqali aldashni oldini oladi). ```json { "user_id": "user1", "points": 1 } ```

**GET /v1/scores** — Reytingdan eng yaxshi 10 o'yinchini olish. ```json { "data": [{"user_id": "user1", "user_name": "alice", "rank": 1, "score": 12543}, ...], "total": 10 } ```

**GET /v1/scores/{:user_id}** — Muayyan foydalanuvchining reytingini olish. ```json { "user_info": { "user_id": "user5", "score": 1000, "rank": 6 } } ```

Yuqori darajali arxitektura

**Ikki xizmat (2-rasm):** 1. **O'yin xizmati** — G'alabalarni tasdiqlaydi, ball yangilash uchun reyting xizmatini chaqiradi. 2. **Reyting xizmati** — Reyting omborida ballarni yangilaydi; eng yaxshi 10 va foydalanuvchi reytingi so'rovlariga xizmat qiladi.

**Nima uchun o'yin serveri ball o'rnatadi (mijoz emas):** Mijoz tomonidagi ball o'rnatish o'yinchilar ballarni ushlab va o'zgartirishi mumkin bo'lgan o'rtadagi hujumlarga zaif.

**Xabar navbati (4-rasm):** O'yin va reyting xizmatlari o'rtasida ixtiyoriy Kafka — ballar bir nechta iste'molchiga (tahlil, push bildirishnomalar, reyting) borishi kerak bo'lganda foydali. Belgilangan talablar asosida shart emas.

Ma'lumot modellari

Relatsion ma'lumotlar bazasi yechimi

**Oddiy yondashuv (5-rasm):** user_id va score ustunlari bilan oylik reyting jadvali.

```sql -- Foydalanuvchi ball qo'shadi: INSERT INTO leaderboard (user_id, score) VALUES ('mary1934', 1); UPDATE leaderboard SET score=score+1 WHERE user_id='mary1934';

-- Foydalanuvchi reytingini topish (7-rasm): SELECT (@rownum := @rownum+1) AS rank, user_id, score FROM leaderboard ORDER BY score DESC; ```

**Nima uchun ko'lamda ishlamaydi:** - Foydalanuvchi reytingini topish butun jadvalni saralashni talab qiladi → millionlab qatorlar bo'ylab O(n) skanerlash. - Reyting so'rovlari uchun 10 soniya — real-vaqt talabi uchun qabul qilinmaydi. - Doimiy o'zgaruvchan ma'lumotlar keshlashni amalga oshirib bo'lmaydigan qiladi. - Indeks + LIMIT 10 bilan ham, eng yaxshi bo'lmagan foydalanuvchilar reytingini aniqlash hali ham to'liq skanerlashni talab qiladi.

**Xulosa:** Relatsion ma'lumotlar bazasi faqat kichik ma'lumotlar to'plami yoki paketli operatsiyalar uchun ishlaydi.

Redis tartiblangan to'plamlari yechimi

**Redis tartiblangan to'plamlari** (8-rasm): Har bir a'zo bog'liq ball bilan noyob. Ichki ikkita ma'lumot tuzilmasidan foydalanadi: - **Hash jadval** — Foydalanuvchilarni ballarga moslashtiradi. - **O'tkazib ketish ro'yxati** — Tez reyting so'rovlari uchun ballarni foydalanuvchilarga moslashtiradi.

**O'tkazib ketish ro'yxati (9-rasm):** Tartiblangan bog'liq ro'yxat + ko'p darajali indekslar. Har bir daraja oldingi darajaning har ikkinchi nodeini o'tkazib ketadi. Qiymatni qidirish avval yuqori indeksni ko'rib chiqadi, O(n) bog'liq ro'yxatga nisbatan taqqoslashlarni keskin kamaytiradi.

**10-rasm:** 5 indeks darajasi bilan o'tkazib ketish ro'yxati — asosiy bog'liq ro'yxatdagi 62 ga nisbatan 11 ko'rib chiqishda tugun topadi.

**Barcha operatsiyalar O(log n)** — millionlab foydalanuvchilarda oldindan aytish mumkin bo'lgan samaradorlik.

**Ishlatiladigan Redis buyruqlari:** - `ZADD` — Tartiblangan to'plamga foydalanuvchini kiritish/yangilash. O(log n). - `ZINCRBY <kalit> <oshirish> <foydalanuvchi>` — Foydalanuvchi ballini oshirish; mavjud bo'lmasa 0 ballda qo'shadi. O(log n). - `ZRANGE/ZREVRANGE` — Ball bo'yicha foydalanuvchilar oralig'ini olish (o'suvchi/kamayuvchi). O(log n + m). - `ZRANK/ZREVRANK` — Foydalanuvchi reytingini olish. O(log n).

**Ish oqimi:**

1. **Foydalanuvchi ball qo'shadi (11-rasm):** ``` ZINCRBY leaderboard_feb_2021 1 'mary1934' ```

2. **Eng yaxshi 10 ni olish (12-rasm):** ``` ZREVRANGE leaderboard_feb_2021 0 9 WITHSCORES ``` Qaytaradi: `[(user2,score2),(user1,score1)...]`

3. **Foydalanuvchi reytingini olish (13-rasm):** ``` ZREVRANK leaderboard_feb_2021 'mary1934' ```

4. **361-reytingdan 4 o'yinchi yuqori va pastini olish (14-rasm):** ``` ZREVRANGE leaderboard_feb_2021 357 365 ```

**Saqlash taxmini:** - 25M oylik faol foydalanuvchi × 26 bayt/yozuv (24 belgili user_id + 2 baytlik ball) = **~650 MB** — bitta Redis serverga sig'adi. - Cho'qqi QPS 2 500 — yagona Redis server sig'imi doirasida.

**Saqlash:** Redis o'qish replika bilan sozlangan; asosiy instansiya nosozligi → replika tayinlanadi.

**MySQL qo'llab-quvvatlovchi jadvallar:** `user` (profil ma'lumotlari) va `point` (vaqt tamg'alari bilan g'alabalar tarixi) — o'yin tarixi va nosozlikdan keyin reytingni tiklash uchun ishlatiladi.

3-qadam — Chuqur Dizayn

Bulut va o'z-o'zini boshqarish joylashtirilishi

**O'z-o'zini boshqarish (15-rasm):** Redis dagi oylik tartiblangan to'plam + foydalanuvchi profillari uchun MySQL. API serverlar reyting ma'lumotlari uchun Redis ga + foydalanuvchi nomlari/rasmlari uchun MySQL ga murojaat qiladi. Eng yaxshi 10 foydalanuvchi profillari uchun ixtiyoriy kesh.

**AWS da serverless (16-17-rasmlar):** Amazon API Gateway → AWS Lambda funksiyalari → Redis + MySQL.

| API | Lambda funksiya | |-----|----------------| | GET /v1/scores | LeaderboardFetchTop10 | | GET /v1/scores/{user_id} | LeaderboardFetchPlayerRank | | POST /v1/scores | LeaderboardUpdateScore |

**Serverless afzalliklari:** Server ta'minlash shart emas, trafik bilan avtomatik kengayish, infratuzilmani saqlash shart emas. Yangi loyihalar uchun tavsiya etiladi.

Redis ni kengaytirish

500M kunlik faol foydalanuvchida (100x ko'lam): reyting **65 GB** ga o'sadi, cho'qqi QPS **250 000**. Bo'laklash talab etiladi.

**1-variant: Qat'iy bo'limlar (18-rasm)** - Ball oralig'i 1-1000 → 10 bo'lak, har biri 100 ballik oraliqni qamrab oladi. - Dastur foydalanuvchi balli asosida to'g'ri bo'lakka yo'naltiradi. - Ikkilamchi kesh kerak: user_id → joriy ball (qaysi bo'lakda ekanligini bilish uchun). - Ball oshishi bo'lak chegarasini kesib o'tganda → eski bo'lakdan o'chirish, yangisiga qo'shish. - Eng yaxshi 10 ni olish: faqat eng yuqori ballli bo'lakni so'rash. - Foydalanuvchi reytingini olish: bo'lak ichidagi lokal reyting + yuqoriroq ballli bo'laklardagi foydalanuvchilar soni (`INFO keyspace` orqali O(1)). - **Tavsiya etilgan yondashuv.**

**2-variant: Redis klaster hash bo'limlash (19-rasm)** - 16 384 hash slot; kalit `CRC16(kalit) % 16384` orqali tayinlanadi. - Avtomatik bo'laklash; nodelarni qo'shish/olib tashlash oson. - Eng yaxshi 10 ni olish scatter-gather talab qiladi (20-rasm): barcha bo'laklarni so'rash, dastur natijalarni saralaydi. - Cheklovlar: katta K uchun top-K so'rovlarida yuqori kechikish; ko'p bo'limlar bilan yuqori kechikish; foydalanuvchi reytingini aniqlash murakkab. - Bu foydalanish holati uchun **tavsiya etilmaydi**.

Muqobil yechim: NoSQL (DynamoDB)

Redis ga muqobil sifatida **Global Ikkilamchi Indekslar (GSI)** bilan DynamoDB.

**21-rasm:** Redis + MySQL ni DynamoDB bilan almashtirgan tizim diagrammasi.

**Dastlabki jadval dizayni (22-rasm):** Denormalizatsiyalangan reyting + foydalanuvchi jadvali. Muammo: eng yuqori ballar uchun to'liq jadval skanerlash.

**Birinchi indeks urinish (23-rasm):** Bo'lim kaliti = `game_name#{yil-oy}`, tartiblash kaliti = `score`. Muammo: joriy oy ma'lumotlarining hammasi bir bo'limda → **issiq bo'lim**.

**Yozishni bo'laklash yechimi (24-rasm):** Bo'lim kaliti = `game_name#{yil-oy}#p{bo'lim_raqami}` bu yerda bo'lim_raqami = `user_id % N`. Ma'lumotlar N bo'lim bo'ylab teng taqsimlangan.

**Kompromis:** N bo'lim → bo'lim boshiga yengilroq yuk, lekin eng yaxshi 10 ni o'qish barcha N bo'lim bo'ylab **scatter-gather** talab qiladi (25-rasm): 1. Har bir bo'limdan parallel ravishda eng yaxshi 10 ni so'rash. 2. Dastur natijalarni birlashtiradi va saralaydi.

**Foydalanuvchi reytingi cheklovi:** To'g'ridan-to'g'ri mutlaq reyting yo'q. Buning o'rniga **foiz taxmini** dan foydalanish: - Cron ishi har bo'lim uchun ball taqsimotini tahlil qiladi → foiz chegaralarini keshlaydi. - Aniq #1 200 001 reyting o'rniga "siz eng yaxshi 10-20%da" ni qaytaradi.

**Bo'lim sonini tanlash:** Benchmarking talab etiladi — ko'proq bo'lim = yengilroq yuk, lekin ko'proq scatter murakkablik.

4-qadam — Yakunlash

Asosiy dizayn mavzulari: Redis tartiblangan to'plamlari va o'tkazib ketish ro'yxati ichki tuzilmasi bilan (O(log n) operatsiyalar), saqlash va tiklash uchun MySQL, 500M kunlik faol foydalanuvchi ko'lamida Redis qat'iy bo'lim bo'laklash, muqobil sifatida yozishni bo'laklash bilan DynamoDB.

**Qo'shimcha muhokama nuqtalari:** - **Tenglik buzish:** Redis Hash `user_id → so'nggi g'alaba vaqt tamg'asi` ni saqlaydi; ballar teng bo'lganda oldingi vaqt tamg'asi yuqoriroq reyting oladi. - **Nosozlikdan tiklash:** MySQL g'alabalar tarixini ZINCRBY chaqiruvlari orqali qayta o'ynash reytingni noldan qayta quradi.

Biz Amazon kabi elektron tijorat ilovasi uchun to'lov backend ni loyihalashtirmoqdamiz. To'lov tizimi barcha pul harakatlarini boshqaradi: xaridorlardan to'lovlarni yig'ish (pay-in) va sotuvchilarga mablag' to'lash (pay-out). Ko'lam: kuniga 1 million tranzaksiya = ~10 TPS. Asosiy e'tibor o'tkazuvchanlik emas, to'g'rilikka qaratilgan.

1-qadam — Muammoni Tushunish va Loyiha Doirasini Belgilash

**Funktsional talablar:** - **Pay-in oqimi** — To'lov tizimi sotuvchilar nomidan mijozlardan pul qabul qiladi. - **Pay-out oqimi** — To'lov tizimi sotuvchilarga pul yuboradi. - Kredit karta to'lovi misoli (Stripe, Braintree, Square kabi uchinchi tomon PSP lar). - Ichki karta ma'lumotlari saqlanmaydi (PSP orqali PCI DSS muvofiqlik). - Oddiylik uchun yagona valyuta; global ilova.

**Funktsional bo'lmagan talablar:** - Ishonchlilik va nosozliklarga chidamlilik — muvaffaqiyatsiz to'lovlar ehtiyotkorlik bilan boshqariladi. - Yarashtirish — ichki va tashqi xizmatlar bo'ylab to'lov izchilligining asinxron tekshiruvi.

**Taxminiy hisob-kitob:** Kuniga 1M tranzaksiya ÷ 10⁵ soniya = **10 TPS**. Yuqori o'tkazuvchanlik muammosi emas — asosiy e'tibor to'g'rilikka.

2-qadam — Yuqori Darajali Dizayn Taklif Qilish va Rozilik Olish

**Pay-in va Pay-out (1-rasm):** - Xaridor to'laydi → pul Amazon ning bank hisobiga boradi (pay-in). - Amazon pul saqlash vazifasini bajaradi; sotuvchi pulning ko'p qismiga egalik qiladi. - Yetkazib berilgandan keyin pul Amazon dan sotuvchining bankiga o'tadi (pay-out).

Pay-in oqimi

**Komponentlar (2-rasm):** - **To'lov xizmati** — To'lov hodisalarini qabul qiladi; xavf tekshiruvini bajaradi (uchinchi tomon orqali AML/CFT); jarayonni muvofiqlаshtiradi. - **To'lov ijrochisi** — PSP orqali yagona to'lov buyurtmasini bajaradi. Bir to'lov hodisasi bir nechta buyurtmani o'z ichiga olishi mumkin (ko'p sotuvchili kassaga o'tish). - **PSP (To'lov Xizmatlari Provayderı)** — Hisoblar o'rtasida pul ko'chiradi (masalan, Stripe, Braintree). Xaridorning kredit kartasini hisoblaydi. - **Karta tizimlari** — Visa, MasterCard, Discovery. Kredit karta operatsiyalarini qayta ishlaydi. - **Ledger** — Ikki tomonlama buxgalteriya yordamida o'zgarmas moliyaviy yozuv. Daromad tahlili va prognozlash uchun. - **Hamyon** — Savdogar hisob balansi va jami foydalanuvchi to'lovlarini kuzatadi.

**Pay-in oqimi (9 qadam):** 1. Foydalanuvchi "buyurtma berish" ni bosadi → to'lov hodisasi to'lov xizmatiga yuboriladi. 2. To'lov xizmati hodisani MB da saqlaydi. 3. To'lov hodisasi bir nechta buyurtmani o'z ichiga olishi mumkin → to'lov xizmati har bir buyurtma uchun ijrochini chaqiradi. 4. To'lov ijrochisi buyurtmani MB da saqlaydi. 5. To'lov ijrochisi kredit kartani hisoblash uchun PSP ga murojaat qiladi. 6. Muvaffaqiyatdan keyin → to'lov xizmati hamyonni yangilaydi (sotuvchi balansi). 7. Hamyon serveri yangilangan balansni saqlaydi. 8. To'lov xizmati tranzaksiyani yozib qo'yish uchun ledger ni chaqiradi. 9. Ledger yangi yozuvni qo'shadi.

**API lar:** - `POST /v1/payments` — To'lov hodisasini bajarish. Maydonlar: `buyer_info`, `checkout_id`, `credit_card_info`, `payment_orders[]`. - Har bir to'lov buyurtmasi: `seller_account`, `amount` (satr, double emas — suzuvchi nuqta aniqligi xatolarini oldini oladi), `currency` (ISO 4217), `payment_order_id` (PSP idempotentlik kaliti sifatida). - `GET /v1/payments/{:id}` — To'lov buyurtmasi bajarilish holatini olish.

**Nima uchun summa satr sifatida (double emas):** Protokollar/apparat bo'ylab suzuvchi nuqta yaxlitlash xatolari; ekstremal qiymatlar (Yaponiya YIM yenda, Bitcoin satoshi = 10⁻⁸). Ko'rsatish/hisoblash uchun raqamga o'tkazish.

**Ma'lumot modeli:** - `payment_event` jadvali: `checkout_id (PK)`, `buyer_info`, `seller_info`, `credit_card_info`, `is_payment_done`. - `payment_order` jadvali: `payment_order_id (PK)`, `buyer_account`, `amount`, `currency`, `checkout_id (FK)`, `payment_order_status` (BOSLANMAGAN → BAJARILMOQDA → MUVAFFAQIYATLI/MUVAFFAQIYATSIZ), `ledger_updated`, `wallet_updated`.

**Ma'lumotlar bazasi tanlovi:** Samaradorlik o'rniga barqarorlik. ACID bilan an'anaviy relatsion MB. NoSQL/NewSQL emas.

**Ikki tomonlama ledger:** Har bir tranzaksiya bir hisobni debetlaydi va ikkinchisini bir xil summaga kreditlaydi. Barcha yozuvlar yig'indisi = 0. Uchidan uchigacha kuzatuvni ta'minlaydi.

Joylashtirilgan to'lov sahifasi (PSP integratsiyasi)

Ko'pgina kompaniyalar karta ma'lumotlarini saqlashdan va PCI DSS javobgarligidan qochish uchun PSP tomonidan joylashtirilgan to'lov sahifalaridan (iframe/widget/SDK) foydalanadi.

**Misol: PayPal integratsiyasi (3-rasm)** — PSP karta yig'ish uchun o'z interfeysini ko'rsatadi.

**9 qadamli joylashtirilgan to'lov oqimi (4-rasm):** 1. Foydalanuvchi kassaga o'tishni bosadi → mijoz buyurtma ma'lumotlari bilan to'lov xizmatini chaqiradi. 2. To'lov xizmati PSP ga summa, valyuta, muddati, redirect URL va **nonce** (UUID idempotentlik kaliti = payment_order_id) bilan ro'yxatdan o'tish so'rovi yuboradi. Aynan bir marta ro'yxatdan o'tishni ta'minlaydi. 3. PSP **token** (bu to'lov ro'yxatini aniqlaydigan UUID) qaytaradi. 4. To'lov xizmati tokenni MB da saqlaydi. 5. Mijoz PSP tomonidan joylashtirilgan to'lov sahifasini ko'rsatadi (5-rasm — Stripe misoli). PSP JS kutubxonasi karta ma'lumotlarini to'g'ridan-to'g'ri yig'adi; karta ma'lumotlari hech qachon tizimimizga tegmaydi. - PSP JS PSP backenddan to'lov tafsilotlarini olish uchun tokendan foydalanadi. - To'lovdan keyingi navigatsiya uchun redirect URL ko'rsatiladi. 6. Foydalanuvchi karta tafsilotlarini to'ldiradi → to'lash ni bosadi → PSP qayta ishlashni boshlaydi. 7. PSP to'lov holatini qaytaradi. 8. Brauzer redirect URL ga yo'naltiriladi (to'lov holati URL ga qo'shiladi). 9. Asinxron ravishda PSP bizning ro'yxatdan o'tirilgan **webhook** imizni to'lov holati bilan chaqiradi → to'lov xizmati `payment_order_status` ni yangilaydi.

Pay-out oqimi

Pay-in ga o'xshash, lekin teskari yo'nalishda. Elektron tijorat saytining bank hisobidan sotuvchilarning bank hisoblariga pul ko'chirish uchun uchinchi tomon **pay-out provayderlari** (masalan, Tipalti) dan foydalanadi. Murakkab tartibga solish va buxgalteriya talablari qo'llaniladi.

3-qadam — Chuqur Dizayn

Yarashtirish

**To'lov to'g'riligi uchun so'nggi himoya chizig'i.** Xizmatlar bo'ylab holatlar izchil ekanligini asinxron tekshirish.

**Jarayon (6-rasm):** Har kecha PSP lar/banklar kun uchun barcha tranzaksiyalar va hisob balansini o'z ichiga olgan **hisob-kitob fayllarini** yuboradi. Yarashtirish tizimi faylni tahlil qiladi va ichki ledger bilan taqqoslaydi.

**Uch turdagi nomuvofiqliklar:** 1. **Tasniflash mumkin + avtomatik tuzatish** — Ma'lum sabab va avtomatlashtirilgan tuzatish. 2. **Tasniflash mumkin, lekin qo'lda** — Ma'lum sabab, avtomatlashtirish uchun juda murakkab. Moliya jamoasi uchun ish navbatiga boradi. 3. **Tasniflash mumkin emas** — Noma'lum sabab. Moliya jamoasi tomonidan qo'lda tekshirish uchun maxsus navbat.

To'lov qayta ishlash kechikishlarini boshqarish

Ba'zi to'lov so'rovlari soatlar yoki kunlar davom etadi (inson ko'rib chiqishi uchun yuqori xavf sifatida belgilangan, 3D Secure autentifikatsiyasi talab qilingan).

**PSP boshqaruvi:** - Mijozga **kutish holati** qaytaradi; mijoz kutish holatini ko'rsatadi. - PSP kutilayotgan to'lovni kuzatadi va hal qilinganida webhook orqali to'lov xizmatini xabardor qiladi.

**Muqobil:** Ba'zi PSP lar to'lov xizmatidan holat yangilanishlarini so'rash talab qiladi.

Ichki xizmatlar o'rtasidagi muloqot

**Sinxron (HTTP):** Oddiy, lekin qat'iy bog'liqlik yaratadi. Kamchiliklari: past samaradorlik, yomon nosozlik izolyatsiyasi, kengaytirish qiyin.

**Asinxron xabar almashish:** - **Yagona qabul qiluvchi (7-8-rasmlar):** Har bir xabar bitta iste'molchi tomonidan qayta ishlanadi; qayta ishlashdan keyin xabar o'chiriladi. Standart xabar navbati (masalan, SQS). - **Bir nechta qabul qiluvchilar (9-rasm):** Bir xil xabar ko'p xizmatlar tomonidan iste'mol qilinadi. Kafka xabarlarni saqlaydi. To'lov tizimiga yaxshi mos keladi: ball yangilanishi bir vaqtda to'lov qayta ishlash + tahlil + hisoblash + push bildirishnomalarni ishga tushiradi.

**Tavsiya:** Katta miqyosli to'lov tizimlari uchun asinxron — qo'shimcha murakkablikka qaramay yaxshi kengaytirilishi va nosozliklarga chidamlilik.

Muvaffaqiyatsiz to'lovlarni boshqarish

**To'lov holati kuzatish:** To'lov holati har bosqichda faqat qo'shish jadvalida saqlanadi. Nosozlikda joriy holat qayta urinish yoki qaytarishni aniqlaydi.

**Qayta urinish navbati + o'lik xat navbati (10-rasm):** 1. Nosozlik yuz beradi → qayta urinish mumkinligini tekshirish. - 1a. Qayta urinish mumkin (o'tkinchi xatolar) → qayta urinish navbati. - 1b. Qayta urinish mumkin emas (noto'g'ri kirish) → MB da saqlanadi. 2. To'lov tizimi qayta urinish navbatidan iste'mol qiladi va qayta urinadi. 3. Yana muvaffaqiyatsiz bo'lsa: - 3a. Qayta urinish soni chegara ostida → qayta urinish navbatiga qaytish. - 3b. Qayta urinish soni chegara oshganda → **o'lik xat navbati** (nosozliklarni tuzatish va qo'lda tekshirish uchun).

Aynan bir marta yetkazib berish

**Aynan bir marta = kamida bir marta (qayta urinish) VA ko'pi bilan bir marta (idempotentlik)**.

**Qayta urinish — kamida bir marta kafolat (11-rasm):** Strategiyalar (tarmoq muammolari uchun eng yomondan eng yaxshiga): - Darhol qayta urinish — tirbandlikni yomonlashtirishi mumkin. - Qat'iy intervallar. - Bosqichma-bosqich intervallar. - **Eksponensial qaytish** — kutish vaqtini ikki baravar oshiradi (1s → 2s → 4s). O'tkinchi tarmoq muammolari uchun eng yaxshi. - Bekor qilish — doimiy nosozliklar uchun.

Xato kodlari bilan `Retry-After` sarlavhasini taqdim eting.

**Idempotentlik — ko'pi bilan bir marta kafolat (12-rasm):** - Mijoz HTTP sarlavhasida idempotentlik kaliti (UUID, masalan, savat ID si) yaratadi: `idempotency-key: <qiymat>`. - Server MB noyob kalit chegarasidan foydalanadi: birinchi kiritish muvaffaqiyatli; dublikat kiritish muvaffaqiyatsiz → keshdan javob qaytarish. - Bir xil kalit bilan bir vaqtdagi so'rovlar → biri qayta ishlanadi, qolganlar 429 Ko'p So'rovlar oladi.

**1-stsenariy (ikki marta bosish):** Idempotentlik kaliti ikkinchi hisoblab chiqishni oldini oladi.

**2-stsenariy (tarmoq xatosi, foydalanuvchi qayta yuboradi):** PSP tokeni to'lov buyurtmasiga noyob tarzda mos keladi. Bir xil buyurtma → bir xil token → PSP uni dublikat sifatida aniqlaydi → oldingi bajarilish holatini qaytaradi.

Izchillik

Ishtirokchi holat saqlangan xizmatlar: to'lov xizmati, ledger, hamyon, PSP, MB replikalari.

**Ichki izchillik:** Aynan bir marta qayta ishlash xizmatlar o'rtasidagi tafovutni oldini oladi.

**Tashqi izchillik (PSP bilan):** Qayta urinishlar uchun bir xil idempotentlik kalitidan foydalanish. PSP idempotentlikni qo'llab-quvvatlasa ham, hali ham yarashtirish o'tkazish — tashqi tizim har doim to'g'ri deb faraz qilmaslik.

**Replikatsiya kechikishi variantlari:** 1. Faqat asosiydan o'qish + yozish — oddiy, lekin replika resurslarini isrof qiladi. 2. Replikalarni har doim sinxronlashtirishda saqlash — Paxos/Raft konsensusidan foydalanish, yoki konsensus asosidagi MB dan (YugabyteDB, CockroachDB).

To'lov xavfsizligi

| Muammo | Yechim | |--------|--------| | So'rov/javob tinglab turish | HTTPS | | Ma'lumotlarni o'zgartirish | Shifrlash + yaxlitlikni monitoring qilish | | O'rtadagi hujum | Sertifikat pin bilan SSL | | Ma'lumot yo'qolishi | MB replikatsiya + snapshotlar | | DDoS | So'rovlar chastotasini cheklash + xavfsizlik devori | | Karta o'g'irlik | Tokenizatsiya (karta raqamlari emas, tokenlarni saqlash) | | PCI muvofiqlik | PCI DSS standarti | | Firibgarlik | Manzilni tekshirish, CVV, foydalanuvchi xulq tahlili |

4-qadam — Yakunlash

Asosiy dizayn mavzulari: pay-in/pay-out oqimlari, nonce/token/webhook bilan joylashtirilgan PSP to'lov sahifasi, ikki tomonlama ledger, hisob-kitob fayllari bilan yarashtirish, qayta urinish navbatlari + o'lik xat navbatlari, qayta urinish + idempotentlik orqali aynan bir marta yetkazib berish, to'lov xavfsizligi.

Qo'shimcha mavzular: monitoring/ogohlantirish, nosozliklarni tuzatish vositalari, valyuta almashtirish, geografiyaga xos to'lov usullari, naqd pul to'lovlari, Google/Apple Pay integratsiyasi.

To'lov platformalari raqamli hamyon xizmatini taqdim etadi: foydalanuvchilar pul saqlaydi va keyinroq sarflaydi, yoki bir xil platformada boshqa hamyonga to'g'ridan-to'g'ri o'tkazadi (bank-bank o'tkazmasiga nisbatan tezroq va odatda bepul). Biz tranzaksion kafolatlar va qayta ishlab chiqarish imkoniyati bilan 1 million TPS da xamyon-hamyon balansi o'tkazmalarini qo'llab-quvvatlovchi backendni loyihalashtirmoqdamiz.

1-qadam — Muammoni Tushunish va Loyiha Doirasini Belgilash

**Talablar:** - Faqat ikki raqamli hamyon o'rtasida balans o'tkazmasi. - **1 000 000 TPS**. - Ishonchlilik ≥ 99,99%. - Tranzaksion kafolatlar. - **Qayta ishlab chiqarish imkoniyati** — boshidan ma'lumotlarni qayta o'ynash orqali tarixiy balansni tiklash (faqat tafovutlarni ko'rsatadigan yarashtirish emas). - Valyuta almashinuvi yo'q (doira tashqarisida).

Taxminiy hisob-kitob

Har bir o'tkazma = 2 ta MB operatsiyasi (debet + kredit). 1M o'tkazma/soniyada → **2M TPS**.

| Node boshiga TPS | Node soni | |-----------------|----------| | 100 | 20 000 | | 1 000 | 2 000 | | 10 000 | 200 |

Dizayn maqsadi: apparat xarajatini kamaytirish uchun node boshiga TPS ni maksimallashtirish.

2-qadam — Yuqori Darajali Dizayn Taklif Qilish va Rozilik Olish

O'rganilgan uchta yuqori darajali dizayn: 1. Oddiy xotiradagi yechim (Redis) 2. Ma'lumotlar bazasiga asoslangan taqsimlangan tranzaksiya yechimi (2PC, TC/C, Saga) 3. Qayta ishlab chiqarish imkoniyati bilan hodisa manbai yechimi

API dizayni

Yagona REST endpointi:

| API | Tafsilot | |-----|----------| | `POST /v1/wallet/balance_transfer` | Bir hamyondan ikkinchisiga balans o'tkazmasi |

**So'rov parametrlari:**

| Maydon | Tavsif | Tur | |--------|--------|-----| | `from_account` | Debet hisobi | satr | | `to_account` | Kredit hisobi | satr | | `amount` | Summa (satr, double emas — suzuvchi nuqta aniqligi xatolarini oldini oladi) | satr | | `currency` | ISO 4217 | satr | | `transaction_id` | Deduplikatsiya/idempotentlik uchun UUID | uuid |

**Javob:** `{ "Status": "success", "Transaction_id": "..." }`

Xotiradagi bo'laklash yechimi

`{foydalanuvchi → balans}` xaritasini saqlash uchun Redis nodelar klasteridan foydalanish. `accountID.hashCode() % N` bo'yicha bo'laklash. Zookeeper bo'laklash konfiguratsiyasini saqlaydi. Holatsiz hamyon xizmati bo'limni qidiradi va har o'tkazma uchun ikkita Redis nodeni yangilaydi.

**Muammo:** Ikkita Redis node bo'ylab atomiklik yo'q. Hamyon xizmati A nodeini yangilashdan keyin, lekin B nodeidan oldin ishdan chiqsa, o'tkazma to'liq emas. Ikki yangilanish yagona atomik tranzaksiyada bo'lishi kerak.

Taqsimlangan tranzaksiyalar

Node boshiga atomiklikni ta'minlash uchun Redis ni tranzaksion relatsion ma'lumotlar bazalari bilan almashtirish. Yagona o'tkazma uchun nodelar bo'ylab koordinatsiya hali ham zarur.

Ma'lumotlar bazasini bo'laklash

Hisoblarni bir nechta relatsion MB nodelariga bo'laklash (Redis o'rniga). Har bir MB node mahalliy ACID kafolatlarini ta'minlaydi, lekin ikki nodeni qamrab olgan o'tkazma hali ham taqsimlangan koordinatsiya talab qiladi.

Taqsimlangan tranzaksiya: ikki bosqichli commit (2PC)

MB qo'llab-quvvatlamasiga tayanuvchi past darajali yechim (masalan, X/Open XA standarti).

**Ikki bosqich:** 1. Koordinator (hamyon xizmati) bir nechta MB da o'qish/yozish bajaradi — **ikkalasi ham qulflanadi**. 2. Koordinator barcha MB lardan tayyorlanishni so'raydi: - Hammasi "ha" deydi → koordinator hammasini commit qiladi. - Biri "yo'q" deydi → koordinator hammasini bekor qiladi.

**Muammolar:** - **Samaradorlik**: Boshqa nodelardan xabarlarni kutishda qulflar uzoq vaqt saqlanadi. - **SPOF**: Koordinator yagona nosozlik nuqtasi — 1-bosqichdan keyin ishdan chiqsa, qulflar muddatsiz saqlanadi.

Taqsimlangan tranzaksiya: Urinib Ko'r-Tasdiqlash/Bekor Qil (TC/C)

Yuqori darajali qoplashtiruvchi tranzaksiya. 2PC dan farqli ravishda, har bir bosqich **mustaqil lokal tranzaksiya** (uzoq saqlanadigan qulflar yo'q).

**Bosqichlar:** 1. **Urinib Ko'r** — koordinator barcha MB lardan resurslarni zaxiralashni so'raydi. 2. **Tasdiqlash** (hammasi ha desa) — haqiqiy operatsiyalarni bajarish. 2. **Bekor Qilish** (biri yo'q desa) — Urinib Ko'r bosqichi ta'sirini bekor qilish (qoplashtiruvchi tranzaksiyalar).

**Misol: A dan C ga $1 o'tkazish:**

| Bosqich | Operatsiya | A | C | |---------|------------|---|---| | 1 | Urinib Ko'r | -$1 | NOP | | 2 | Tasdiqlash | NOP | +$1 | | | Bekor Qilish | +$1 (bekor) | NOP |

**Nima uchun faqat 1-tanlov Urinib Ko'r bosqichi uchun amal qiladi:** - 2-tanlov (A da NOP, C da +$1): C Bekor Qilish uni qaytarishdan oldin sarflanishi mumkin. - 3-tanlov (bir vaqtda A da -$1 va C da +$1): Murakkab nosozlik holatlari.

**Muvozanatsiz holat:** Urinib Ko'r paytida A dan $1 chegirib tashlanadi, lekin C hali kreditlanmagan — yig'indi vaqtincha kamroq. Bu oraliq izchilsizlik dastur uchun ko'rinadi (uni yashiradigan 2PC/MB tranzaksiyalaridan farqli).

**Bosqich holati jadvali:** A ning ma'lumotlar bazasida saqlanadi. Kuzatadi: taqsimlangan tranzaksiya ID/mazmuni, MB boshiga Urinib Ko'r bosqichi holati, ikkinchi bosqich nomi (Tasdiqlash yoki Bekor Qilish), ikkinchi bosqich holati, tartibsiz bayroq. Ishdan chiqishdan tiklashni ta'minlaydi.

**Tartibsiz bajarish:** Tarmoq muammolari tufayli Bekor Qilish C ga Urinib Ko'r dan oldin yetib kelishi mumkin. Yechim: Bekor Qilish tartibsiz bayroq qoldiradi; keyingi Urinib Ko'r bayroqni aniqlaydi va nosozlik qaytaradi.

**2PC bilan taqqoslash:**

| | Birinchi bosqich | Ikkinchi bosqich: muvaffaqiyat | Ikkinchi bosqich: nosozlik | |--|----------------|-------------------------------|---------------------------| | 2PC | Lokal tranzaksiyalar hali bajarilmagan (qufllangan) | Hammasini commit | Hammasini bekor qilish | | TC/C | Barcha lokal tranzaksiyalar bajarildi | Kerak bo'lsa yangi lokal tranzaksiyalarni bajarish | Commit qilingan tranzaksiyalarni bekor qilish ("undo") |

TC/C ma'lumotlar bazasidan mustaqil (tranzaksiyalarni qo'llab-quvvatlaydigan har qanday MB bilan ishlaydi), lekin murakkablik dastur biznes mantig'ida.

Taqsimlangan tranzaksiya: Saga

Mikroservis arxitekturasida de-fakto standart.

**Qoidalar:** - Operatsiyalar **chiziqli ketma-ketlikda** tartiblangan; har biri mustaqil MB tranzaksiyasi. - Operatsiyalar birma-bir bajariladi; yakunlanish keyingisini ishga tushiradi. - Nosozlikda: joriy operatsiyadan birinchisiga **rollback**, qoplashtiruvchi tranzaksiyalar yordamida. - `n` operatsiya → jami `2n` (n oldinga + n qoplashtiruv).

**Koordinatsiya rejimlari:** - **Xoreografiya** — xizmatlar bir-birining hodisalariga obuna bo'ladi (to'liq markazsizlashtirilgan). Ko'p xizmatlar bilan boshqarish qiyin — har biri ichki holat mashinasini saqlashi kerak. - **Orkestratsiya** — yagona koordinator barcha xizmatlarni navbat bilan boshqaradi. Murakkablikni yaxshi hal qiladi; raqamli hamyon uchun afzalroq.

**TC/C bilan taqqoslash:**

| | TC/C | Saga | |--|------|------| | Qoplashtiruvchi harakat | Bekor Qilish bosqichi | Rollback bosqichi | | Markaziy koordinatsiya | Ha | Ha (orkestratsiya) | | Operatsiya bajarilish tartibi | Istalgan | Faqat chiziqli | | Parallel bajarilish | Ha | Yo'q | | Qisman izchilsizlik ko'rinadi | Ha | Ha |

**Qachon tanlash:** Kechikishga sezgir + ko'p xizmatlar → TC/C (parallel). Kamroq xizmatlar / mikroservis tendensiyasi → Saga.

Hodisa manbai

Tekshiruv imkoniyati va qayta ishlab chiqarish imkoniyati uchun tanlangan — auditorlar savollariga javob beradi: - Istalgan vaqtdagi hisob balansi? (o'sha nuqtagacha hodisalarni qayta o'ynash) - Tarixiy balanslar to'g'ri ekanligini qanday tekshirish? (hodisalar ro'yxatidan qayta hisoblash) - Kod o'zgarishidan keyin mantiq to'g'ri ekanligini qanday isbotlash? (bir xil hodisalar ustida turli versiyalarni ishlatish)

Fon

Taqsimlangan tranzaksiya yechimlari faqat yangilangan holatni saqlaydi — balans nima uchun o'zgarganini tekshirib bo'lmaydi. Hodisa manbai barcha o'zgarishlarni o'zgarmas tarix sifatida saqlaydi; holat hosil qilingan ko'rinish, har doim tiklash mumkin.

Ta'rif

To'rtta asosiy tushuncha:

**Buyruq** — tashqi dunyodan mo'ljallangan harakat (masalan, "A dan C ga $1 o'tkazish"). Buyruqlar FIFO navbatiga qo'yiladi. Noto'g'ri bo'lishi mumkin.

**Hodisa** — tasdiqlangan, bajarilgan buyruq natijasi (o'tgan zamon: "A dan C ga $1 o'tkazildi"). Bajarilishi shart. **Deterministik** — tasodifiylik yoki I/U yo'q. Hodisalar FIFO navbatida saqlanadi. Bir buyruq → 0 yoki ko'proq hodisa (hodisa yaratish tasodifiylikni o'z ichiga olishi mumkin; hodisalarning o'zi deterministik bo'lishi kerak).

**Holat** — hodisa qo'llanilganda nima o'zgaradi. Hamyon tizimida: `{hisob → balans}` xaritasi. Kalit-qiymat omborida yoki relatsion MB da saqlanadi.

**Holat mashina** — hodisa manbaini boshqaradi: 1. Buyruqlarni tasdiqlaydi va hodisalar yaratadi. 2. Holatni yangilash uchun hodisalarni qo'llaydi. **To'liq deterministik** bo'lishi shart — tashqi I/U yo'q, tasodifiy sonlar yo'q. Bir xil hodisalar har doim bir xil holatni yaratadi.

Hamyon xizmati misoli

Buyruqlar = balans o'tkazmasi so'rovlari → Kafka FIFO navbati. Holat = relatsion MB dagi hisob balanslari.

**Holat mashina (5 qadam):** 1. Buyruqlar navbatidan buyruqni o'qish. 2. MB dan balans holatini o'qish. 3. Buyruqni tasdiqlash; to'g'ri bo'lsa, ikki hodisa yaratish (masalan, `A:-$1`, `C:+$1`). 4. Keyingi hodisani o'qish. 5. Hodisani qo'llash — MB da balansni yangilash.

Qayta ishlab chiqarish imkoniyati

Hodisalar ro'yxati **o'zgarmas**. Holat mashina **deterministik**. Shuning uchun: boshidan hodisalarni qayta o'ynash har doim bir xil tarixiy holatlarni qayta tiklaydi.

Taqsimlangan tranzaksiya yechimlari holat yangilanishida tarixni yo'qotadi. Hodisa manbai barcha tarixni saqlaydi; MB faqat hodisalar jurnalining joriy ko'rinish keshlari.

Buyruq-so'rov mas'uliyatini ajratish (CQRS)

Tashqi mijozlar joriy balansni so'rashi kerak — lekin hodisa manbaining ichki holati to'g'ridan-to'g'ri ko'rsatilmaydi.

**CQRS namunasi:** Holatni e'lon qilish o'rniga barcha hodisalarni e'lon qilish. Tashqi iste'molchilar o'zlarining moslashtirilgan holat ko'rinishlarini qayta quradi.

- **Bitta yozish holat mashina** — vakolatli hodisalar jurnalini saqlaydi. - **Ko'plab faqat o'qish holat mashinalari** — hodisalar navbatiga obuna bo'ladi, turli so'rov ehtiyojlari uchun materiallashtirilgan ko'rinishlar quradi (joriy balanslar, vaqt oralig'idagi tekshiruvlar, ikki marta hisoblab chiqishni tekshirish, yarashtirish).

Faqat o'qish holat mashinalari ortda qoladi, lekin har doim yetib oladi → **yakuniy izchillik**.

3-qadam — Chuqur Dizayn

Hodisa manbai arxitekturasi uchun yuqori samaradorlik, ishonchlilik va kengaytirilishini chuqur o'rganish.

Yuqori samarali hodisa manbai

Tarmoq kechikishini yo'q qilish uchun masofaviy Kafka + masofaviy MB dan mahalliy fayl asosidagi saqlashga o'tish.

Fayl asosidagi buyruq va hodisalar ro'yxati

**1-optimizatsiya:** Buyruqlar va hodisalarni **lokal diskka** saqlash (masofaviy Kafka emas) — tarmoq tur-qaytarni yo'q qiladi. Faqat qo'shish tuzilmasidan foydalanadi (ketma-ket yozishlar, OT tomonidan optimallashtirilgan; tasodifiy xotira kirishidan tezroq bo'lishi mumkin).

**2-optimizatsiya:** So'nggi buyruqlar/hodisalarni **xotirada** keshlash — yaqinda yozilgan ma'lumotlar uchun diskdan o'qishni o'tkazib yuborish.

**Amalga oshirish:** `mmap` dan foydalanish — disk faylini xotira massiviga moslashtiradi. OT issiq bo'limlarni xotirada keshlaydi. Faqat qo'shish operatsiyalari uchun: ma'lumotlar deyarli har doim xotira keshida.

Fayl asosidagi holat

Holatni masofaviy relatsion MB dan mahalliy fayl asosidagi omborlarga ko'chirish: - **SQLite** — fayl asosidagi mahalliy relatsion MB. - **RocksDB** — LSM daraxtidan foydalangan fayl asosidagi kalit-qiymat ombori (yozishlar uchun optimallashtirilgan; o'qishlar uchun so'nggi ma'lumotlarni keshlaydi). Afzal tanlov.

Snapshot

**Muammo:** Qayta ishlab chiqarish imkoniyati har safar #1 hodisadan qayta o'ynashni talab qiladi.

**Yechim:** Holat mashinani davriy to'xtatish va joriy holatni **snapshot fayliga** saqlash (o'zgarmas tarixiy holat ko'rinishi). Qayta ishga tushirish/qayta o'ynashda: eng yaqin snapshotni yuklash, pozitsiyani tekshirish, u yerdan davom ettirish.

Moliya jamoalari ko'pincha kunlik tranzaksiyalarni tekshirish uchun 00:00 da snapshot talab qiladi. Faqat o'qish holat mashinalari barcha hodisalarni boshidan qayta o'ynash o'rniga bitta snapshotni yuklaydi.

Snapshot fayllari katta ikkilik fayllar — ob'ekt omborida saqlanadi (masalan, HDFS).

Hamma narsa fayl asosida bo'lganda, tizim lokal apparat maksimal I/U o'tkazuvchanligidan to'liq foydalana oladi.

Ishonchli yuqori samarali hodisa manbai

Fayl asosidagi lokal saqlash yagona nosozlik nuqtasini yaratadi. Replikatsiya zarur.

Ishonchlilik tahlili

**To'rt turdagi ma'lumot:** 1. Fayl asosidagi buyruq 2. Fayl asosidagi hodisa 3. Fayl asosidagi holat 4. Holat snapshot

**Tahlil:** - Holat va snapshot har doim hodisalar ro'yxatidan qayta tiklanishi mumkin → faqat hodisalarni himoya qilish. - Buyruq hodisani qayta ishlab chiqarish imkoniyatini kafolatlay olmaydi (hodisa yaratish deterministik bo'lmasligi mumkin — tashqi I/U, tasodifiy sonlarni o'z ichiga oladi). - **Hodisa** kuchli ishonchlilik kafolatini talab qiladigan yagona ma'lumot. Hodisalar deterministik faktlar; ularni qayta o'ynash har doim bir xil holatni tiklaydi.

**Xulosa: Faqat hodisalar ro'yxati yuqori ishonchlilik replikatsiyasini talab qiladi.**

Konsensus

Hodisalar ro'yxatini bir nechta node bo'ylab replikatsiya qilish uchun **Raft konsensus algoritmi** dan foydalanish.

**Kafolatlar:** Nodelarning aksariyati onlayn bo'lsa, barcha faqat qo'shish hodisalar ro'ylxatlari bir xil ma'lumotga ega.

**Raft node rollari:** Rahbar, Nomzod, Izdosh. - Klaster boshiga ko'pi bilan bitta rahbar. - Rahbar buyruqlar oladi, hodisalarni ishonchli tarzda replikatsiya qiladi. - **3 node** → 1 nosozlikka chidaydi. **5 node** → 2 nosozlikka chidaydi.

Ishonchli yechim

**Raft bilan 3 nodelik hodisa manbai klasteri (24-rasm):** - Rahbar kiruvchi buyruqlar oladi, hodisalarga aylantiradi, lokal hodisalar ro'yxatiga qo'shadi. - Raft yangi hodisalarni izdoshlarga replikatsiya qiladi. - Barcha nodelar (rahbar + izdoshlar) hodisalar ro'yxatini qayta ishlaydi va holatni yangilaydi → bir xil holatlar kafolatlanadi.

**Nosozlikni boshqarish:** - **Rahbar ishdan chiqishi:** Raft avtomatik yangi rahbar saylaydi. Mijoz buyruqni qayta yuboradi (ishdan chiqish buyruq→hodisaga aylantirish paytida yuz bergan bo'lishi mumkin). Idempotentlik kaliti (transaction_id) ikki marta qayta ishlashni oldini oladi. - **Izdosh ishdan chiqishi:** Raft node qayta ishga tushgunga yoki almashtirilgunga qadar cheksiz qayta urinadi.

Taqsimlangan hodisa manbai

Yagona Raft guruhining ikkita cheklovi bor: 1. CQRS javobi sekin — mijoz bajarilish holati uchun so'rab turishi kerak. 2. Bitta Raft guruh sig'imi cheklangan — ko'lamda bo'laklash + taqsimlangan tranzaksiyalar kerak.

So'rab turish va push

**So'rab turish modeli (25-rasm):** Tashqi foydalanuvchi faqat o'qish holat mashinasini davriy so'raydi. Real-vaqt emas; hamyon xizmatini ortiqcha yuklatishi mumkin.

**So'rab turish + teskari proksi (26-rasm):** Foydalanuvchi buyruqni teskari proksiga yuboradi, u foydalanuvchi nomidan so'raydi. Mijoz mantig'ini soddalashtiradi, lekin hali ham real-vaqt emas.

**Push modeli (27-rasm):** Faqat o'qish holat mashina hodisa olinganda darhol bajarilish holatini teskari proksiga push qiladi. Foydalanuvchi real vaqtga yaqin javob oladi.

Taqsimlangan tranzaksiya

Push modeli har bir Raft guruhini sinxron qilganda, bo'limlar arosi koordinatsiya uchun TC/C yoki Sagadan qayta foydalanish.

**Bo'lim sxemasi:** 2 ga hash kaliti → Bo'lim 1 (A hisob) va Bo'lim 2 (C hisob).

**Yakuniy taqsimlangan hodisa manbai dizayni (28-rasm):** Saga koordinatori + bir nechta Raft bo'lim guruhlari.

**29 qadamli Saga baxtli yo'l (29-rasm): A dan C ga $1 o'tkazish:** 1. A foydalanuvchisi Saga koordinatoriga taqsimlangan tranzaksiya yuboradi (A-$1, C+$1). 2. Saga koordinatori bosqich holati jadvalida yozuv yaratadi. 3. Koordinator 1-bo'limga A-$1 buyruqi yuboradi. 4. 1-bo'lim Raft rahbari buyruqni saqlaydi, tasdiqlaydi, hodisaga aylantiradi, Raft nodelar bo'ylab sinxronlashtiradi, bajaradi (A dan $1 chegirib tashlaydi). 5. 1-bo'lim CQRS o'qish yo'liga sinxronlashtiradi; o'qish yo'li holatni va bajarilish holatini tiklaydi. 6. 1-bo'lim o'qish yo'li holatni Saga koordinatoriga push qiladi. 7. Saga koordinatori 1-bo'limdan muvaffaqiyat oladi. 8. Koordinator bosqich holati jadvalida 1-bo'lim muvaffaqiyatini yozib qo'yadi. 9. Koordinator 2-bo'limga C+$1 buyruqi yuboradi. 10. 2-bo'lim Raft rahbari buyruqni saqlaydi, tasdiqlaydi, hodisaga aylantiradi, Raft sinxronlashtiradi, bajaradi (C ga $1 qo'shadi). 11. 2-bo'lim CQRS o'qish yo'liga sinxronlashtiradi; holatni tiklaydi. 12. 2-bo'lim o'qish yo'li holatni Saga koordinatoriga push qiladi. 13. Saga koordinatori 2-bo'limdan muvaffaqiyat oladi. 14. Koordinator bosqich holati jadvalida 2-bo'lim muvaffaqiyatini yozib qo'yadi. 15. Barcha operatsiyalar yakunlandi; koordinator chaqiruvchiga muvaffaqiyat bilan javob beradi.

4-qadam — Yakunlash

**Dizaynlar evolyutsiyasi:** 1. **Xotiradagi Redis bo'laklash** — tez, lekin nodelar bo'ylab atomiklik yo'q. 2. **Taqsimlangan tranzaksiyalar (2PC / TC/C / Saga)** — atomiklik ta'minlandi, lekin tekshiruv izi yo'q. 3. **Hodisa manbai (masofaviy Kafka + MB)** — qayta ishlab chiqarish imkoniyati, lekin sekin (tarmoq). 4. **Fayl asosidagi hodisa manbai** — lokal mmap + RocksDB orqali yuqori samaradorlik. 5. **Raft replikatsiya** — yagona nosozlik nuqtasini yo'q qiladi. 6. **CQRS + teskari proksi (push)** — tashqi foydalanuvchilar uchun sinxron javob. 7. **Raft bo'lim guruhlari bo'ylab Saga** — yakuniy kengaytiriladigan, ishonchli, tekshirilishi mumkin bo'lgan dizayn.

**Erishilgan asosiy xususiyatlar:** 1M+ TPS, tranzaksion kafolatlar, 99,99% ishonchlilik, tekshiruvlar uchun to'liq qayta ishlab chiqarish imkoniyati.

Biz elektron fond birjasi tizimini loyihalashtirmoqdamiz. Asosiy vazifa — xaridorlar va sotuvchilarni samarali moslashtirishdir. Bugun buyurtmalar NYSE (kuniga milliardlab moslamalar) va HKEX (~kuniga 200 milliard aksiya) dagi superkompyuterlar tomonidan qayta ishlanadi. Ko'lam muhim — o'lcham va xususiyatlar uchun intervyu oluvchi bilan tekshiring.

1-qadam — Muammoni Tushunish va Loyiha Doirasini Belgilash

**Funktsional talablar:** - Qimmatli qog'ozlar: faqat **aksiyalar** (optsionlar/fyuchers yo'q). - Operatsiyalar: limit buyurtmalarni **joylashtirish** va **bekor qilish**. - Buyurtma turlari: faqat **limit buyurtmalar** (bozor yoki shartli buyurtmalar yo'q). - Savdo soatlari: faqat oddiy soatlar (soatdan keyingisi yo'q). - O'n minglab bir vaqtdagi foydalanuvchilar, ≥100 ramz, **kuniga milliardlab buyurtmalarni** qo'llab-quvvatlash. - Mijozlarga ko'rinadigan real-vaqtli buyurtmalar kitobi (sotib olish/sotish buyurtmalari ro'yxati). - **Xavf tekshiruvlari** (masalan, foydalanuvchi kuniga yagona aksiyaning 1M dan ortiq ulushiga ega bo'lmasligi). - **Hamyon boshqaruvi**: yetarli mablag' talab etiladi; ochiq buyurtmalar uchun mablag' ushlab turiladi.

Funktsional bo'lmagan talablar

- **Mavjudlik**: ≥99,99%. - **Nosozliklarga chidamlilik**: ishlab chiqarish hodisasining ta'sirini cheklash uchun tez tiklash mexanizmi. - **Kechikish**: millisekundlik tur-qaytarma (buyurtma birjaga kiradi → bajarilgan natija qaytariladi). **99-foiz** kechikishga e'tibor qaratish. - **Xavfsizlik**: yangi hisoblar uchun KYC (Mijozni Bil); ommaviy endpointlar uchun DDoS himoyasi.

Taxminiy hisob-kitob

- 100 ramz, kuniga 1 milliard buyurtma. - NYSE kuniga 6,5 soat ochiq (09:30 - 16:00 ET). - **QPS**: 1 mlrd / 6,5 / 3600 ≈ **43 000**. - **Cho'qqi QPS**: 5× = **215 000** (bozor ochilish/yopilishida yuqori hajm).

2-qadam — Yuqori Darajali Dizayn Taklif Qilish va Rozilik Olish

Asosiy tushunchalar: brokerlar (Charles Schwab, Robinhood), institutsional mijozlar (pensiya fondlari, hedge fondlar/bozor yaratuvchilar), limit buyurtmalar, bozor buyurtmalari, bozor ma'lumotlari darajalari, sham diagrammalari, FIX protokoli.

Biznes bilimlari asoslari

**Broker** — chakana mijozlar brokenlar orqali savdo qiladi (veb/mobil interfeys). Institutsional mijozlar maxsus dasturdan foydalanadi.

**Limit buyurtma** — qat'iy narxda sotib olish/sotish; darhol moslashmasligi yoki qisman to'ldirilishi mumkin.

**Bozor buyurtmasi** — narx ko'rsatilmaydi; joriy narxda darhol bajariladi; kafolatlangan bajarilish evaziga narxni qurbon qiladi.

**Bozor ma'lumotlari darajalari:** - **L1** — eng yaxshi takliflar narxi, so'rov narxi, miqdorlar (2-rasm). - **L2** — L1 dan ko'proq narx darajalari (3-rasm). - **L3** — har bir darajada navbatdagi miqdor bilan narx darajalari (4-rasm).

**Sham diagrammasi** — vaqt oralig'i uchun ochilish, yopilish, eng yuqori, eng past narxni ko'rsatadi (1 daqiqa, 5 daqiqa, 1 soat, 1 kun, 1 hafta, 1 oy). 5-rasmda yagona sham ko'rsatilgan.

**FIX protokoli** — Moliyaviy Ma'lumot Almashinuvi (1991), qimmatli qog'ozlar tranzaksiyalari uchun sotuvchi-neytral protokol.

Yuqori darajali dizayn

Uchta oqim (6-rasm):

**Savdo oqimi (muhim yo'l, qat'iy kechikish):** 1. Mijoz broker ilovasi orqali buyurtma beradi. 2. Broker buyurtmani birjaga yuboradi. 3. Mijoz shlyuzi: kirishni tekshirish, chastotani cheklash, autentifikatsiya, normalizatsiya → buyurtma menejeriga yo'naltirish. 4-5. Buyurtma menejeri xavf tekshiruvlarini amalga oshiradi. 6. Buyurtma menejeri hamyonda yetarli mablag' borligini tekshiradi. 7-9. Buyurtma ketma-ketlovchi orqali moslashtiruv mexanizmiga yuboriladi (ketma-ket ID bilan tamg'alanadi); moslashtirish sotib olish/sotish taraflari uchun ikkita bajarilish (to'ldirish) natijasini beradi; chiquvchi ketma-ketlovchi bajarilishlarni tamg'alaydi. 10-14. Bajarilishlar mijoz shlyuzi orqali mijozga qaytariladi.

**Bozor ma'lumotlari oqimi (muhim emas):** - M1: Moslashtiruv mexanizmi bajarilish oqimini yaratadi → bozor ma'lumotlari nashriyotchisi (MDP). - M2: MDP sham diagrammalari va buyurtmalar kitoblarini quradi → ma'lumotlar xizmati. - M3: Bozor ma'lumotlari ixtisoslashtirilgan saqlashga yoziladi; brokerlar mijozlarga etkazadi.

**Hisobot oqimi (muhim emas):** - R1-R2: Reporter buyurtma + bajarilish maydonlarini yig'adi (client_id, narx, miqdor, buyurtma_turi, to'ldirilgan_miqdor, qolgan_miqdor) → ma'lumotlar bazasiga yozadi.

Savdo oqimi

**Moslashtiruv mexanizmi** (kesishma mexanizmi ham deyiladi): - Har bir ramz uchun buyurtmalar kitobini saqlaydi. - Sotib olish/sotish buyurtmalarini moslaydi → har bir moslashtirish uchun ikkita bajarilish (sotib olish + sotish). - Bajarilish oqimini bozor ma'lumotlari sifatida tarqatadi. - **Deterministik** bo'lishi shart: bir xil kirish ketma-ketligi → bir xil chiqish ketma-ketligi (yuqori mavjudlik uchun qayta o'ynashga imkon beradi).

**Ketma-ketlovchi** — moslashtiruv mexanizmini deterministik qiladi (7-rasm): - **Kiruvchi ketma-ketlovchi**: moslashtiruv mexanizmi qayta ishlashdan oldin kiruvchi buyurtmalarni ketma-ket ID lar bilan tamg'alaydi. - **Chiquvchi ketma-ketlovchi**: chiquvchi bajarilishlarni ketma-ket ID lar bilan tamg'alaydi. - Ketma-ket ID lar → yo'qolgan raqamlar osongina aniqlanadi. - Funksiyalari: xabar navbati, hodisalar ombori, aynan bir marta kafolat, tez qayta o'ynash. - Ikki Kafka oqimiga o'xshash, lekin past va oldindan aytish mumkin bo'lgan kechikish.

**Buyurtma menejeri**: - Mijoz shlyuzidan kiruvchi buyurtmalar oladi. - Xavf tekshiruviga yuboradi (masalan, foydalanuvchi savdo hajmi < kuniga $1M). - Hamyonda yetarli mablag' borligini tekshiradi. - Buyurtmani ketma-ketlovchiga yuboradi (hammasi emas, faqat zarur atributlar). - Ketma-ketlovchidan bajarilishlar oladi → brokerlarga qaytaradi. - Holat boshqaruvi uchun **hodisa manbaidan** foydalanadi (ko'plab holat o'tish holatlarini boshqaradi).

**Mijoz shlyuzi** (8-9-rasmlar): - Qorovul: kirishni tekshirish, chastotani cheklash, autentifikatsiya, normalizatsiya. - Yengil qoladi — buyurtmalarni iloji boricha tez manzillarga o'tkazadi. - Chakana va institutsional uchun turli shlyuzlar (kechikish, hajm, xavfsizlik). - **Kolokatsiya (colo)**: birja savdo dasturi birja ma'lumotlar markazida broker serverida ishlaydi; kechikish = serverlar o'rtasida yorug'lik tezligi.

Bozor ma'lumotlari oqimi

Bozor ma'lumotlari nashriyotchisi (MDP) moslashtiruv mexanizmidan bajarilishlar oladi → buyurtmalar kitoblari va sham diagrammalari (birgalikda: bozor ma'lumotlari) quradi → obunachilarga ma'lumotlar xizmatiga yuboradi.

Hisobot oqimi

Reporter muhim yo'lda emas, lekin biznes uchun muhim: savdo tarixi, soliq hisoboti, muvofiqlik, hisob-kitoblar. - Kiruvchi buyurtmalar + chiquvchi bajarilishlar atributlarini birlashtiradi. - Kechikishga kamroq sezgir; **aniqlik va muvofiqlik** asosiy.

API dizayni

Brokerlar va mijoz shlyuzi o'rtasida REST API (institutsional mijozlar ixtisoslashtirilgan past kechikishli protokollardan foydalanishi mumkin).

**Buyurtma joylashtirish:** `POST /v1/order` - Parametrlar: `symbol` (satr), `side` (sotib olish/sotish), `price` (Long), `orderType` (limit/bozor), `quantity` (Long). - Javob: `id`, `creationTime`, `filledQuantity`, `remainingQuantity`, `status` (yangi/bekor qilingan/to'ldirilgan).

**Bajarilishlarni olish:** `GET /execution?symbol={}&orderId={}&startTime={}&endTime={}` - Javob: `id`, `orderId`, `symbol`, `side`, `price`, `orderType`, `quantity` bilan bajarilishlar massivi.

**Buyurtmalar kitobi:** `GET /marketdata/orderBook/L2?symbol={}&depth={}` - Javob: `bids` va `asks` massivlari (narx + hajm).

**Sham diagrammalari:** `GET /marketdata/candles?symbol={}&resolution={}&startTime={}&endTime={}` - Javob: interval boshiga `open`, `close`, `high`, `low` bilan `candles` massivi.

Ma'lumot modellari

Uchta asosiy ma'lumot turi: mahsulot/buyurtma/bajarilish, buyurtmalar kitobi, sham diagrammasi.

Mahsulot, buyurtma, bajarilish

- **Mahsulot** — ramz atributlari (tur, savdo ramzi, ko'rsatish ramzi, valyuta, lot hajmi, tick hajmi). Kamdan-kam o'zgaradi; yuqori darajada keshlanadi. - **Buyurtma** — kiruvchi sotib olish/sotish ko'rsatmasi. - **Bajarilish (to'ldirish)** — chiquvchi moslashtirilgan natija. Moslashtiruv mexanizmi har bir moslashtirish uchun ikkita bajarilish yaratadi (sotib olish + sotish). Har bir buyurtmada bajarilish bo'lmaydi.

**Saqlash:** - Muhim savdo yo'li: xotira + disk/umumiy xotira (MB emas). Tez tiklash uchun ketma-ketlovchida saqlanadi; bozor yopilgandan keyin arxivlanadi. - Reporter: yarashtirish/soliq hisoboti uchun MB ga yozadi. - MDP: buyurtmalar kitobi va sham ma'lumotlarini tiklash uchun bajarilishlardan foydalanadi.

Buyurtmalar kitobi

Narx darajasi bo'yicha tartib ushlab turilgan qimmatli qog'oz uchun sotib olish/sotish buyurtmalari ro'yxati. Moslashtiruv mexanizmidagi asosiy ma'lumot tuzilmasi.

**Talablar:** O(1) qo'shish/bekor qilish/bajarish, narx darajasi bo'yicha O(1) qidirish, eng yaxshi taklif/so'rovni tez so'rash, narx darajalarini takrorlash.

**Amalga oshirish:** ``` class PriceLevel { Price limitPrice; long totalVolume; List<Order> orders; } class Book<Side> { Side side; Map<Price, PriceLevel> limitMap; } class OrderBook { Book<Buy> buyBook; Book<Sell> sellBook; PriceLevel bestBid; PriceLevel bestOffer; Map<OrderID, Order> orderMap; } ```

**Kalit:** Barcha operatsiyalar uchun O(1) ga erishish uchun `orders` uchun **ikki tomonlama bog'liq ro'yxat** dan foydalanish (oddiy ro'yxat emas): - **Joylashtirish** (yangi buyurtma) → oxiriga qo'shish: O(1). - **Moslashtirish** → boshidan o'chirish: O(1). - **Bekor qilish** → O(1) da buyurtmani topish uchun `orderMap` dan foydalanish; ikki tomonlama bog'liq ro'yxat oldingi ko'rsatgichni topmasdan o'chirishga imkon beradi.

Ayniqsa, bajarilish oqimidan L1/L2/L3 ma'lumotlarini tiklash uchun MDP da ham ishlatiladi.

Sham diagrammasi

Buyurtmalar kitobi bilan birga MDP dagi asosiy ma'lumot tuzilmasi. ``` class Candlestick { long openPrice; long closePrice; long highPrice; long lowPrice; long volume; long timestamp; int interval; } class CandlestickChart { LinkedList<Candlestick> sticks; } ``` **Xotira optimizatsiyalari:** - Shamlarni ushlab turish uchun oldindan ajratilgan **halqa buferlari** (yangi ob'ekt ajratmalari yo'q). - Xotiradagi shamlarni cheklash; qolganlarini diskka saqlash.

Bozor ma'lumotlari real-vaqtli tahlil uchun **xotirali ustunli ma'lumotlar bazasida** saqlanadi (masalan, KDB); tarixiy ma'lumotlar bozor yopilgandan keyin diskka saqlanadi.

3-qadam — Chuqur Dizayn

Zamonaviy yirik birjalar deyarli hamma narsani yagona ulkan serverda ishlatadi. Asosiy optimizatsiya sohalari: samaradorlik, hodisa manbai, yuqori mavjudlik, nosozliklarga chidamlilik.

Samaradorlik

`Kechikish = ∑muhimYo'lBo'yichaBarijararishVaqti`

**Muhim yo'l:** `shlyuz → buyurtma menejeri → ketma-ketlovchi → moslashtiruv mexanizmi`

**Muhim yo'ldagi vazifalarni kamaytirish:** Hatto jurnallash ham muhim yo'ldan olib tashlanadi.

**Vazifalarga sarflanadigan vaqtni kamaytirish — tarmoq va disk kirishini yo'q qilish:** - Tarmoq tur-qaytarma: hop boshiga ~500 mks → bir nechta komponent = jami bir xonali ms. - Ketma-ket disk yozishlari (ketma-ketlovchi): o'n ms. - Jami: o'n ms — zamonaviy past kechikishli birjalar uchun yetarli emas.

**Yechim: Hamma narsani bitta serverga joylashtirish (15-rasm).** - Komponentlar `/dev/shm` (xotira bilan qoplangan fayl tizimi) orqali **mmap** (`mmap(2)`) yordamida muloqot qiladi — tarmoq yo'q, disk I/U yo'q. - mmap xabar avtobuslari: mikrosoniyadan past xabar almashish.

**Dastur sikli (16-rasm):** - Bajariladigan vazifalarni so'rovchi bitta ipli sikl. - **CPU qistirib qo'yish**: har bir dastur sikli ipi qat'iy CPU yadroga qistirilgan. - Afzalliklari: kontekst almashtirish yo'q, qulf raqobati yo'q (yagona yozuvchi) → past 99-foiz kechikish. - Murakkablik: murakkabroq kodlash; muhandislar vazifa boshiga vaqtni ehtiyotkorlik bilan rejalashtirishi kerak.

Hodisa manbai

**An'anaviy MB yondashuvi** (17-rasm chap): faqat joriy holatni (buyurtma holati) saqlaydi — holatga qanday erishilganligi tarixi yo'q.

**Hodisa manbai** (17-rasm o'ng): barcha holat o'zgartiruvchi hodisalarning o'zgarmas jurnali. Hodisalar haqiqat oltin manbai. Holat hodisalarni qayta o'ynash orqali tiklanadi.

**mmap bilan hodisa manbai dizayni (18-rasm):** - Tashqi domen FIX dan foydalanadi; ichki domen ixcham/tez kodlash uchun SBE (Oddiy Ikkilik Kodlash) ustida FIX dan foydalanadi. - Shlyuz FIX → SBE ga aylantiradi → Hodisalar Ombori Mijozi orqali `NewOrderEvent` yuboradi. - Buyurtma menejeri (moslashtiruv mexanizmiga o'rnatilgan): `NewOrderEvent` oladi, tasdiqlaydi, ichki buyurtma holatlarini yangilaydi, moslashtiruv yadroga yuboradi. - Moslashtiruv mexanizmi `OrderFilledEvent` yaratadi → hodisalar ombori. - MDP va reporter hodisalar omboriga obuna bo'ladi.

**Kutubxona sifatida buyurtma menejeri:** Buyurtma holatiga ehtiyoj sezuvchi har bir komponentga o'rnatiladi. Har bir komponent o'zining buyurtma holatini saqlaydi — kechikish zarbisini oldini olish uchun umumiy buyurtma menejeridan qochish. Hodisa manbai barcha holatlar bir xil va qayta o'ynatilishi mumkinligini kafolatlaydi.

**Hodisa manbai dizaynidagi ketma-ketlovchi (19-rasm):** - Yagona yozuvchi — hodisalar ombori boshiga faqat bitta ketma-ketlovchi (bir nechtasi qulf raqobatini keltirib chiqaradi). - Har bir komponentning mahalliy halqa buferidan hodisalar oladi, ketma-ket ID tamg'alaydi, hodisalar omboriga yuboradi. - Oddiy va tez (xabar ombori funksiyasi yo'q — faqat ID tamg'alaydi). - Yuqori mavjudlik uchun zaxira ketma-ketlovchilar.

Yuqori mavjudlik

Maqsad: 4 to'qqizlik (99,99%) = kuniga maksimal 8,64 soniya to'xtab qolish → darhol tiklash talab etiladi.

**Issiq-iliq dizayn (20-rasm):** - **Issiq (asosiy) moslashtiruv mexanizmi**: faol; hodisalar omboriga hodisalar yuboradi. - **Iliq (zaxira) instansiya**: bir xil hodisalar oladi va qayta ishlaydi, lekin hodisalarni chiqarmaydi. - Asosiy nosozlikda: iliq instansiya darhol asosiy sifatida o'z zimmasiga oladi. - Iliq nosozlikda/qayta ishga tushirishda: hodisalar omborini qayta o'ynash orqali barcha holatlarni tiklaydi.

**Yurak urishlari**: moslashtiruv mexanizmi yurak urishlarini yuboradi; yo'qolgan yurak urishi almashtirish tekshiruvini ishga tushiradi.

**Mashinalar bo'ylab issiq-iliqni kengaytirish:** Barcha iliq serverlarga samarali tarqatish uchun **ishonchli UDP** yordamida mashinalar va ma'lumot markazlari bo'ylab butun hodisalar omborini replikatsiya qilish (Aeron dizayniga qarang).

Nosozliklarga chidamlilik

Ofat tiklash uchun ma'lumot markazlari arosi replikatsiya bilan issiq-iliq dizayn (zilzila, elektr uzilishi).

**Asosiy savollar:** - **RTO** (Tiklash Vaqti Maqsadi): soniya darajasi → avtomatik almashtirish + xizmat degradatsiya strategiyasi talab etiladi. - **RPO** (Tiklash Nuqtasi Maqsadi): nolga yaqin ma'lumot yo'qolishi → Raft konsensus bilan ko'plab nusxalarni kafolatlaydi.

**Raft bilan rahbar saylovi (21-22-rasmlar):** - 5 nodelik Raft klasteri; har bir nodening o'zining mmap hodisalar ombori bor. - Rahbar RPC orqali barcha izdoshlarga hodisalar yuboradi; izdoshlar hodisalar omborlariga saqlaydi. - Operatsiyani bajarish uchun minimal ovozlar: N/2 + 1 (5 dan 3 tasi). - **Yurak urishi**: rahbar izdoshlarga `AppendEntries` (mazmuni yo'q) yuboradi. - **Saylov muddati**: yurak urishi olinmasa izdosh nomzodga aylanadi; boshqalarga `RequestVote` yuboradi. - Ko'pchilik ovoziga ega birinchi izdosh g'alaba qiladi; tenglik bo'lsa → bo'lingan ovoz → yangi saylov. - **Muddat** (22-rasm): vaqt oddiy ishlash va saylovni ifodalovchi ixtiyoriy intervallarga bo'linadi.

**Nosozlikni boshqarish bo'yicha yo'riqnoma:** - Qo'lda almashtirishdan boshlash; faqat yetarli operatsion signallar to'planganidan keyin avtomatlashtirish. - Chekka holatlarni tezroq aniqlash uchun **xaos muhandisligidan** foydalanish.

Moslashtiruv algoritmlari

Standart: **FIFO moslashtiruv** — bir xil narx darajasidagi buyurtmalar kelish tartibida moslashtiriladi.

**Boshqa algoritmlar (fyuchers savdosida qo'llaniladi):** - **LMM bilan FIFO (Boshlovchi Bozor Yaratuvchi)**: FIFO navbatidan oldin LMM ga nisbat ajratadi. - **Qorong'u havza**: turli moslashtiruv qoidalari bilan muqobil savdo tizimi.

**Psevdokod asosiy qismlari:** - `handleOrder`: ketma-ket IDni tasdiqlaydi, buyurtmani tasdiqlaydi, `handleNew` yoki `handleCancel` ga yo'naltiradi. - `handleNew`: SOTIB OLISH uchun `match(sellBook, order)` ga, SOTISH uchun `match(buyBook, order)` ga yo'naltiradi. - `handleCancel`: buyurtmani topish uchun `orderMap` dan foydalanadi; olib tashlaydi va BEKOR_QILINDI holati o'rnatadi. - `match`: `leavesQuantity == 0` bo'lgunga qadar narx darajasidagi ikki tomonlama bog'liq ro'yxatni takrorlaydi, boshidan to'ldiradi.

Determinizm

**Funktsional determinizm**: bir xil kirish ketma-ketligi → bir xil chiqish (ketma-ketlovchi + hodisa manbai tomonidan ta'minlangan).

**Kechikish determinizmi**: barcha savdolarda barqaror kechikish. **99-foiz** (yoki 99,99-foiz) kechikish **HdrHistogram** yordamida o'lchanadi.

**Hodisa manbaida vaqt (23-rasm)**: hodisalarning haqiqiy devor soati vaqti muhim emas — faqat tartib muhim. Diskret notekis hodisa vaqt tamg'alari uzluksiz ketma-ket nuqtalarga aylantiriladi → qayta o'ynash/tiklash vaqti sezilarli darajada qisqaradi.

**Java kechikish tuzoq**: JVM To'xtatish-Dunyo GC (HotSpot) xavfsiz nuqta pauzalarini keltirib chiqaradi — 99-foiz kechikish cho'qqilarining keng tarqalgan manbai.

Bozor ma'lumotlari nashriyotchisi optimizatsiyalari

MDP moslashtiruv mexanizmidan moslashtirilgan natijalar oladi → buyurtmalar kitobi va sham diagrammalarini qayta quradi → obunachilarga e'lon qiladi.

**Dizayn halqa buferlaridan foydalanadi (24-rasm):** - Halqa buferi (aylana buferi): boshi dumi bilan bog'liq qat'iy o'lchamli navbat. - Oldindan ajratilgan joy — ob'ekt yaratish/yo'q qilish yo'q. - **Qulfsiz** ma'lumot tuzilmasi. - **Kesh qatori to'ldirish**: halqa buferi ketma-ket raqami hech qachon boshqa narsa bilan bir kesh qatorida bo'lmasligi ta'minlanadi → noto'g'ri ulashmani yo'q qiladi.

**Darajali kirish:** Chakana sukut bo'yicha L2 ning 5 darajasini oladi; ko'proq daraja uchun qo'shimcha to'lash.

Bozor ma'lumotlarining taqsimot adolatliligi

Tartibga solingan birjalar uchun: barcha obunachilap bozor ma'lumotlarini bir vaqtda olishi kerak.

**Muammo:** Ro'yxatdagi birinchi obunachi har doim ma'lumotni birinchi oladi; aqlli mijozlar bozor ochilishida birinchi ulanish uchun musobaqa qiladi.

**Yechimlar:** - **Ishonchli UDP bilan multicast**: ko'plab ishtirokchilarga bir vaqtda yangilanishlarni tarqatish. - **Tasodifiy tartib**: ulanishda obunachiga tasodifiy pozitsiya tayinlash.

Multicast

Uchta ma'lumot transport protokoli: - **Unicast**: bitta manba → bitta manzil. - **Broadcast**: bitta manba → butun quyi tarmoq. - **Multicast**: bitta manba → turli quyi tarmoqlardagi hostlar to'plami.

Bir xil guruhidagi multicast qabul qiluvchilar nazariy jihatdan ma'lumotlarni bir vaqtda oladi. UDP ishonchsiz — qayta uzatishni boshqarish dan foydalanish (masalan, NACK asosidagi ishonchli multicast).

Kolokatsiya

Birjalar kolokatsiya xizmatlarini taklif etadi: broker/hedge fond serverlari birja bilan bir xil ma'lumot markaziga joylashtiriladi. Kechikish ∝ kabel uzunligi. Adolatlilik buzilishi sifatida emas, pullik VIP xizmat sifatida qabul qilinadi.

Tarmoq xavfsizligi

DDoS ommaviy interfeysli birjalar uchun real muammo.

**Kamaytirishlar:** - Ommaviy xizmatlarni xususiy xizmatlardan ajratish; bir nechta faqat o'qish nusxalar. - Kamdan-kam yangilanadigan ma'lumotlar uchun keshlash qatlami. - URL larni mustahkamlash: `/data?from=123&to=456` o'rniga `/data/recent` dan foydalanish (CDN da keshlanadi; sanab chiqish qiyinroq). - Tarmoq shlyuz mahsulotlari orqali ruxsat ro'yxati/bloklash mexanizmlari. - **Chastotani cheklash**.

Yakunlash

Yirik birja uchun ideal joylashtirilish: hamma narsa yagona ulkan serverda yoki yagona jarayonda. Ba'zi birjalar aynan shunday loyihalashtirilgan.

**Kripto birjalar** bulut infratuzilmasidan foydalanadi; ba'zi DeFi loyihalari umuman buyurtmalar kitobisiz AMM (Avtomatik Bozor Yaratish) dan foydalanadi.

**Asosiy dizayn mavzulari:** moslashtiruv mexanizmi + ketma-ketlovchi, buyurtmalar kitobi (ikki tomonlama bog'liq ro'yxat O(1)), sham diagrammalari, mijoz shlyuzi, mmap xabar avtobuslari, CPU qistiruv bilan dastur sikli, SBE bilan hodisa manbai, issiq-iliq yuqori mavjudlik, Raft nosozliklarga chidamliligi, FIFO moslashtiruv, kechikish uchun HdrHistogram, halqa buferi MDP, adolatli ma'lumotlar tarqatish uchun multicast.

Yaxshi tizimlarni loyihalash yillar davomida to'plangan bilimlarni talab qiladi. Bir qisqa yo'l — haqiqiy dunyo tizimlarining arxitekturasini o'rganishdir. Umumiy tamoyillarga ham, asosiy texnologiyalarga ham e'tibor bering — har bir texnologiya qanday muammolarni hal qilishini tushunib oling.

Haqiqiy dunyo tizimlari

Turli kompaniyalarning haqiqiy tizim arxitekturalari haqidagi umumiy loyihalash g'oyalarini qamrab oluvchi materiallar:

**Facebook** - Facebook Timeline: Denormalizatsiya kuchi bilan sizga yetkaziladi - Facebook-da masshtablash - Timeline-ni yaratish: Hayot tarixi uchun kengaytirilgan masshtablash - Facebook-da Erlang (Facebook chat) - Haystack-da igna topish: Facebook-ning foto saqlash tizimi - Facebook Multifeed xizmat ko'rsatish: Qayta loyihalash orqali samaradorlik va unumdorlik - Facebook-da Memcache-ni masshtablash - TAO: Facebook-ning ijtimoiy grafik uchun taqsimlangan ma'lumotlar ombori

**Amazon** - Amazon arxitekturasi - Dynamo: Amazon-ning yuqori mavjudlikdagi kalit-qiymat ombori

**Netflix** - Netflix stek tizimining 360 darajali ko'rinishi - Hamma narsa sinovga bog'liq: Netflix eksperiment platformasi - Netflix tavsiyalari: 5 yulduzdan tashqarida (1 va 2-qism)

**Google** - Google arxitekturasi - Google fayl tizimi - Differentsial sinxronizatsiya (Google Docs) - Bigtable: Tuzilgan ma'lumotlar uchun taqsimlangan saqlash tizimi

**YouTube** - YouTube arxitekturasi - Seattle masshtablilik konferentsiyasi: YouTube masshtablilik

**Twitter** - Twitter 150 million faol foydalanuvchi bilan ishlash uchun foydalanadigan arxitektura - Twitter-ni masshtablash: Twitter-ni 10000% tezlashtirish - Masshtabda vaqt chiziqlari - Snowflake-ni e'lon qilish (yuqori masshtabda noyob ID yaratish)

**Boshqalar** - Instagram arxitekturasi: 14 million foydalanuvchi, terabayt fotosuratlar - Uber o'zining real vaqtli bozor platformasini qanday masshtablaydi - Pinterest-ni masshtablash / Pinterest arxitekturasi yangilanishi - LinkedIn-ni masshtablashning qisqa tarixi - Flickr arxitekturasi - Dropbox-ni qanday masshtabladik - Facebook $19 milliardga sotib olgan WhatsApp arxitekturasi

Kompaniyalar muhandislik bloglari

Suhbatdan oldin kompaniyaning muhandislik blogini o'qish ularning texnologiya to'plami va loyihalash qarorlari haqida qimmatli tushuncha beradi.

| Kompaniya | Blog | |-----------|------| | Airbnb | medium.com/airbnb-engineering | | Amazon | developer.amazon.com/blogs | | Docker | blog.docker.com | | Dropbox | blogs.dropbox.com/tech | | eBay | ebaytechblog.com | | Facebook | code.facebook.com/posts | | GitHub | githubengineering.com | | Google | developers.googleblog.com | | Highscalability | highscalability.com | | Instagram | engineering.instagram.com | | LinkedIn | engineering.linkedin.com/blog | | Netflix | medium.com/netflix-techblog | | PayPal | paypal-engineering.com | | Pinterest | engineering.pinterest.com | | Reddit | redditblog.com | | Shopify | engineering.shopify.com | | Slack | slack.engineering | | Spotify | labs.spotify.com | | Stripe | stripe.com/blog/engineering | | System Design Primer | github.com/donnemartin/system-design-primer | | Twitter | blog.twitter.com/engineering | | Uber | eng.uber.com | | Yelp | engineeringblog.yelp.com | | Zoom | medium.com/zoom-developer-blog |

Tabriklaymiz! Siz ushbu intervyu qo'llanmasining oxiriga yetdingiz. Siz tizimlarni loyihalash uchun zarur ko'nikma va bilimlarni to'pladingiz. Amaliyot mukammallikka olib boradi — orzu qilingan ishga kirish ko'p vaqt va sa'y-harakat talab qiladigan uzoq sayohatdir.