Apache Kafka qanday ishlaydi

Bu darsda nima o‘rganasiz

Siz internet-do‘konda buyurtma berdingiz. Shu bitta bosishdan keyin o‘nlab tizim harakatga keladi: ombor mahsulotni band qiladi, to‘lov tizimi pulni yechadi, SMS xizmati xabar yuboradi, tavsiya tizimi “bu mijoz yana nimani oladi” deb o‘ylaydi, tahlil bo‘limi kunlik hisobotni yangilaydi, firibgarlik tizimi tekshiradi. Ular bir-biri haqida bilmaydi — va bilishi ham shart emas. Hammasi bitta hodisani eshitadi: “buyurtma № 81 402 yaratildi”.

Bu hodisalar qayerdan eshitiladi? Ko‘p kompaniyalarda — Apache Kafkadan. Kafka 2010-yil atrofida LinkedIn’da yaratilgan, 2011-yilda ochiq kodga chiqarilgan va bugun banklardan tortib taksi xizmatlarigacha minglab kompaniyalarning “asab tizimi”ga aylangan. LinkedIn’ning o‘zida 2019-yilda Kafka orqali kuniga 7 trilliondan ortiq xabar o‘tgan.

Kafka’ning siri bitta oddiy g‘oyada: faqat oxiriga yoziladigan jurnal (log). Bank ko‘chirmasi kabi: yangi yozuvlar pastga qo‘shiladi, eskilari o‘zgarmaydi, va har kim o‘zi xohlagan joydan o‘qiy oladi. Dars shu g‘oyadan boshlanadi va to‘rtta savolga javob beradi:

1. Sekundiga millionlab xabarni qanday yozish mumkin? Diskni “sekin” deymiz — lekin ketma-ket yozishda u juda tez. Kafka butun dizaynini shu kuzatuvga quradi.

2. Server o‘lsa, xabar yo‘qolmaydimi? Replikatsiya, ISR va “high watermark” — Kafka’ning eng nozik va eng muhim qismi. Amaliyotda aynan shu protokolni o‘zingiz yozasiz.

3. Yuzlab o‘quvchi bitta oqimni qanday bo‘lishadi? Consumer group’lar, offset’lar va “qayta muvozanatlash” (rebalance).

4. “Aynan bir marta” (exactly-once) mumkinmi? Tarmoq xabarni ikki marta yetkazishi mumkin. Kafka buni qanday hal qiladi — va qayerda hal qila olmaydi.

Har yangi tushuncha avval oddiy tilda, keyin mexanizm sifatida, oxirida raqam bilan beriladi. Dars oxirida — butun darsning o‘n gaplik xulosasi. Oldingi darslardan foydali: Google Docs’dagi “operatsiyalar jurnali” va Airbnb’dagi CDC oqimi — ikkalasi ham Kafka kabi jurnal g‘oyasiga tayanadi.

1. Muammo: hamma hamma bilan gaplashsa

1.1 LinkedIn, 2010-yil

Oddiy tilda: har bir tizim boshqa har bir tizimga to‘g‘ridan-to‘g‘ri ma’lumot yuborsa, simlar chalkashib ketadi. Bu — “spagetti” integratsiya.

2010-yillar boshida LinkedIn’da xuddi shu holat edi: foydalanuvchi faolligi (ko‘rishlar, bosishlar, qidiruvlar), ma’lumotlar bazalaridagi o‘zgarishlar, serverlar metrikalari va loglari — har biri o‘z yo‘li bilan har bir iste’molchiga (qidiruv indeksi, tavsiyalar, ma’lumotlar ombori, monitoring) yetkazilardi. Kafka mualliflaridan biri Jay Kreps 2013-yilgi mashhur maqolasida (“The Log”) bu muammoni shunday chizgan:

Hisobning oxirgi qatori — markaziy jurnalning asosiy qiymati. Yangi tizim qo‘shish arzon bo‘ladi: u jurnalni boshidan o‘qiydi va o‘zi uchun kerakli holatni quradi. Manbalar esa kim o‘qiyotganini umuman bilmaydi.

1.2 Talablar

Beshinchi qator Kafka’ni klassik navbatdan (queue) ajratadi. Oddiy navbatda xabar o‘qilgach — o‘chiriladi: “bajarildi, ketdi”. Kafka’da xabar o‘qilgach ham qoladi. Bu ikki katta imkoniyat beradi: bir nechta mustaqil o‘quvchi bitta xabarni o‘qiydi, va xato bo‘lsa, istalgan o‘quvchi orqaga qaytib, qayta o‘qiy oladi.

1.3 Konvert orqasidagi hisob

Ikkinchi hisob darsning birinchi texnik saboqi: disk sekin emas, tasodifiy disk sekin. Kafka dizaynidagi ko‘p qarorlar (faqat oxiriga yozish, xabarlarni to‘plab yozish, operatsion tizim keshiga tayanish) aynan disk va tarmoqni ketma-ket ishlatish uchun.

2. Nol nuqta: jurnal va offset

2.1 Faqat oxiriga yoziladigan jurnal

Oddiy tilda: jurnal — bu bank ko‘chirmasi. Har yangi operatsiya pastga qo‘shiladi va tartib raqami oladi. Eski qatorlar hech qachon o‘zgarmaydi. Hisobingizdagi balansni bilish uchun ko‘chirmani boshidan oxirigacha o‘qib chiqish kifoya.

offset:   0          1          2          3          4
        +----------+----------+----------+----------+----------+
        | buyurtma | to'lov   | buyurtma | bekor    | to'lov   |  <- yangi yozuvlar
        | #81401   | #81401   | #81402   | #81401   | #81402   |     shu yerga
        +----------+----------+----------+----------+----------+
                                  ^                         ^
                     tahlil shu yerda (offset 2)   qidiruv shu yerda (4)

Uchta tushunchani eslab qoling:

Yozuv (record) — kalit, qiymat va vaqt belgisi. Kalit ixtiyoriy, lekin muhim (2.3).

Offset — yozuvning jurnaldagi tartib raqami: 0, 1, 2, … U hech qachon o‘zgarmaydi va takrorlanmaydi.

O‘quvchining pozitsiyasi — bitta son: “keyingi o‘qiydiganim — offset 2”. O‘quvchining butun holati shu. Uni saqlash, orqaga qaytarish, boshqa o‘quvchiga berish — hammasi bitta sonni o‘zgartirish.

2.2 Nega jurnal — kuchli abstraksiya

Jurnal g‘oyasi Kafka’dan ancha eski. Ma’lumotlar bazalari ichida u yozuvdan oldingi jurnal (write-ahead log, WAL) deyiladi: har o‘zgarish avval jurnalga yoziladi, keyin jadvallarga. Server qulasa — jurnal qayta o‘ynaladi. Replikatsiya — jurnalni boshqa serverga nusxalash.

Bu Airbnb darsidagi CDC oqimi (bazaning o‘zgarishlar jurnali qidiruv indeksini yangilaydi) va Google Docs’dagi “operatsiyalar jurnali va suratlar” bilan bir xil tuzilma. Kafka ularning umumlashmasi: har qanday tizim jurnalga yozadi, har qanday tizim undan o‘qib, o‘z ko‘rinishini quradi.

2.3 Tartib — faqat bitta jurnal ichida

Jurnal ichida tartib qat’iy: offset 3 har doim offset 2 dan keyin. Lekin bitta jurnal bitta serverning diskiga bog‘langan — cheksiz o‘sa olmaydi. Kafka jurnalni bo‘laklarga (partition) bo‘ladi (5-bo‘lim, 1-qadam), va tartib faqat bitta bo‘lak ichida kafolatlanadi.

Qaysi yozuv qaysi bo‘lakka tushishini kalit belgilaydi: bir xil kalit — har doim bir xil bo‘lak. Shuning uchun “bitta buyurtmaning barcha hodisalari tartib bilan” kerak bo‘lsa, kalit — buyurtma raqami.

2.4 Beshta so‘z: Kafka lug‘ati oddiy tilda

Darsning qolgan qismida beshta so‘z doim uchraydi. Ularni bitta rasm bilan eslab qolish oson — gazeta arxivi:

Topic — arxivdagi bitta javon: “buyurtmalar”, “to‘lovlar”, “kirishlar”. Har mavzu o‘z javonida.

Partition — javondagi bitta papka. Javon katta bo‘lsa, u bir nechta papkaga bo‘linadi, va har papka — alohida jurnal (2.3). Papka ichida varaqlar raqamlangan (offset).

Broker — arxiv binosi, ya’ni server. Bitta topic’ning papkalari bir nechta binoga tarqatilgan, va har papkaning nusxasi boshqa binolarda ham bor (6-bo‘lim).

Producer (ishlab chiqaruvchi) — varaq olib kelib, papka oxiriga qo‘yadigan kishi. U faqat oxiriga qo‘shadi — o‘rtaga qo‘ya olmaydi, eski varaqni o‘zgartira olmaydi.

Consumer (o‘quvchi) — papkani o‘qiydigan kishi. U varaqni olib ketmaydi — faqat “men 57-varaqqacha o‘qidim” deb belgi qo‘yadi. Shuning uchun bitta papkani o‘nta turli bo‘lim bir-biriga xalaqit bermasdan o‘qiydi, har biri o‘z belgisi bilan.

Klassik navbat (masalan, pochta bo‘limidagi navbat) bilan asosiy farq shu oxirgi jumlada. Navbatda xabar kimdir olgach yo‘qoladi: bitta xat — bitta oluvchi. Jurnalda xabar belgilangan muddat (masalan, 7 kun) saqlanadi, va uni istalgancha o‘quvchi, istalgancha marta o‘qiydi. Kechikib qo‘shilgan yangi xizmat ham kechagi xabarlarni boshidan o‘qib chiqa oladi — navbatda bu imkonsiz. Farqning narxi va qachon navbat yaxshiroq ekani — 16-bo‘limda.

3. v0: bitta fayl va bitta server

Eng sodda “Kafka” — bitta serverda bitta fayl. Yozish — faylning oxiriga qo‘shish; o‘qish — berilgan offset’dan boshlab. Offset’dan fayldagi o‘ringa tez o‘tish uchun kichik indeks saqlaymiz:

import os, struct

class Log:
    def __init__(self, path):
        self.f = open(path, "a+b")
        self.positions = []            # offset -> fayldagi bayt o'rni (xotirada)
        self._rebuild()

    def _rebuild(self):                # qayta ishga tushganda indeksni tiklash
        self.f.seek(0)
        pos = 0
        while (head := self.f.read(4)):
            self.positions.append(pos)
            (n,) = struct.unpack(">I", head)
            self.f.seek(n, 1)
            pos += 4 + n

    def append(self, value: bytes) -> int:
        self.f.seek(0, os.SEEK_END)
        self.positions.append(self.f.tell())
        self.f.write(struct.pack(">I", len(value)) + value)
        self.f.flush(); os.fsync(self.f.fileno())      # har yozuvda diskka
        return len(self.positions) - 1                  # offset

    def read(self, offset: int, max_n: int = 100):
        out = []
        for pos in self.positions[offset:offset + max_n]:
            self.f.seek(pos)
            (n,) = struct.unpack(">I", self.f.read(4))
            out.append(self.f.read(n))
        return out

Har yozuv — 4 baytli uzunlik va qiymat. Offset — yozuvning tartib raqami. Qayta ishga tushganda fayl boshidan o‘qilib, indeks tiklanadi. Har append fsync qiladi — “yozildi” degani “diskda” degani.

Bu v0 ishlaydi: kichik jamoa uchun hodisalar jurnali, sekundiga yuzlab yozuv, bir nechta o‘quvchi. Muammolar yuk, vaqt va nosozliklar bilan chiqadi.

4. Nima sindi

v0 kichik yuk bilan ishlaydi. Endi unga 1-bo‘limdagi talablarni — sekundiga gigabayt, o‘nlab o‘quvchi guruhlari, serverlar o‘lishi — qo‘yamiz va nima birinchi bo‘lib sinishini ko‘ramiz. Har muammo keyingi bo‘limdagi bitta yoki bir nechta qadamga olib keladi.

4.1 Har yozuvda fsync

Oddiy tilda: fayl “yozildi” deganda, ma’lumot odatda hali operatsion tizim xotirasida turadi — diskka keyinroq, o‘zi qulay paytda yozadi. Elektr o‘chsa, bu xotira yo‘qoladi. fsync — “hozir, darhol diskka yoz va tugagach xabar ber” degan buyruq. v0 har yozuvdan keyin shuni chaqiradi va disk javobini kutadi. Muammo shundaki, bu kutish yozuv kichik yoki katta bo‘lishiga deyarli bog‘liq emas — har chaqiruv bir xil qimmat:

4.2 Bitta disk, bitta fayl — chegara

Hatto fsync muammosi hal bo‘lsa ham, v0 da hamma yozuvlar bitta faylga, ya’ni bitta diskka va bitta serverga tushadi. Server qanchalik kuchli bo‘lmasin, uning diski va tarmoq kartasi chegaralangan. Yozish bilan birga o‘qish ham bor: har xabarni bir nechta guruh o‘qiydi, ya’ni chiquvchi oqim kiruvchidan bir necha barobar katta. Hisoblaymiz:

4.3 Server o‘ldi — jurnal ham

v0 da ma’lumot bitta diskda. Disk yoki server o‘lsa, jurnal yo‘qoladi — va u bilan birga “kompaniyaning barcha hodisalari”. Hatto disk tirik qolsa ham, server qayta ishga tushguncha (daqiqalar-soatlar) hech kim yoza ham, o‘qiy ham olmaydi. S3 darsidagi saboq bu yerda ham amal qiladi: bitta nusxa — saqlanish emas.

4.4 Disk to‘ladi

Jurnal faqat o‘sadi. Kuniga 86 TB (1.3) bilan har qanday disk bir necha kunda to‘ladi. Eski yozuvlarni o‘chirish kerak — lekin bitta ulkan fayldan boshini “kesib tashlash” oson emas (fayl tizimlari fayl boshidan qisqartirishni yaxshi bilmaydi). Yechim — jurnalni segmentlarga (bir nechta kichikroq fayllarga) bo‘lish va eski segmentni butunlay o‘chirish (5-bo‘lim, 2-qadam).

4.5 O‘quvchi qulasa — qayerdan davom etadi?

v0 da o‘quvchi offset’ni o‘zi eslab qoladi — masalan, xotirada. Qulasa, unutadi. Faylga yozsa — o‘sha serverda; server almashsa, yo‘qoladi. O‘quvchilar ko‘p bo‘lsa va ular ishni bo‘lishsa (har biri jurnalning bir qismini o‘qisa), “kim qaysi bo‘lakni o‘qiydi va qayergacha o‘qidi” degan umumiy holat kerak. Bu 5-bo‘limning 8–9-qadamlari.

4.6 Tarmoq takrori

Ishlab chiqaruvchi (producer) xabar yubordi, server yozdi, lekin javob yo‘lda yo‘qoldi. Ishlab chiqaruvchi qayta yuboradi — jurnalda ikkita bir xil xabar. Airbnb darsidagi “ikki marta yechish” muammosining aynan o‘zi, faqat bu yerda xabarlar oqimida.

4.7 Muammolar ro‘yxati

v0 dan qolgan olti muammo va ularni hal qiladigan qadamlar (5-bo‘lim):

Oxirgi qadam (13 — KRaft) hech bir yozuvga to‘g‘ridan-to‘g‘ri tegmaydi: u “kim yetakchi, kim ISR da” degan ma’lumotni saqlaydigan tizimni soddalashtiradi va klasterni millionlab partition’gacha kengaytiradi.

5. Evolyutsiya: o‘n to‘rt qadam

Qadamlar uch guruhda. Tezlik (1–4): bo‘laklar, segmentlar, to‘plash va operatsion tizim keshi. Ishonchlilik (5–9): replikatsiya, tasdiqlash darajalari, yetakchi almashinuvi, o‘quvchilar guruhlari. Semantika va ekspluatatsiya (10–14): takrorsiz yozish, tranzaksiyalar, jurnalni siqish, ZooKeeper’siz Kafka va arzon uzoq saqlash.

partition-0/
  00000000000000000000.log     <- offset 0 dan boshlanadi (yopiq, 1 GB)
  00000000000000000000.index   <- siyrak indeks: offset -> fayldagi o'rin
  00000000000005123456.log     <- fayl nomi = birinchi offset
  00000000000005123456.index
  00000000000010240021.log     <- faol segment, yozuvlar shu yerga
  00000000000010240021.index

Yetakchi (broker 1):  [0][1][2][3][4][5][6]        LEO = 7
Izdosh (broker 2):    [0][1][2][3][4][5]           LEO = 6
Izdosh (broker 3):    [0][1][2][3][4]              LEO = 5
                                     ^
                         HW = 5 (hammada bor: 0..4)
O'quvchilar 0..4 ni ko'radi; 5 va 6 — hali tasdiqlanmagan

1. A m1 ni yozadi (offset 0).        A: [m1]  HW_A=0
2. B fetch qiladi, m1 ni oladi.        B: [m1]  HW_B=0
3. B yana fetch qiladi (offset 1 dan) -> A biladi: B da 1 ta yozuv bor
   A: HW_A = 1 -> m1 TASDIQLANDI, ishlab chiqaruvchiga "OK"
   A javobida HW=1 yuboradi — lekin javob yetib borishidan oldin...
4. B qayta ishga tushadi (qulash). Uning HW_B hali 0.
   Eski qoida: "HW gacha kes" -> B: []   (m1 o'chdi!)
5. A o'ladi. B yagona nusxa -> yetakchi bo'ladi.
   m1 — tasdiqlangan xabar — YO'QOLDI.

Ishlab chiqaruvchi ishga tushganda brokerdan ID oladi: PID = 7001
Har partition uchun har to'plamga tartib raqami: seq = 0, 1, 2, ...

Broker har (PID, partition) uchun oxirgi seq ni eslaydi:
  kelgan seq = oxirgi + 1   -> yoz, oxirgi = seq
  kelgan seq <= oxirgi      -> TAKROR: yozma, avvalgi natijani qaytar
  kelgan seq > oxirgi + 1   -> oraliq bor: xato (OutOfOrderSequence)

1. beginTransaction  (tranzaksion ID: "indekslovchi-3")
2. B ga yozuvlar      -> jurnalga yoziladi, lekin "tranzaksiyada" belgisi bilan
3. offset'ni commit   -> __consumer_offsets ga, xuddi shu tranzaksiyada
4. commitTransaction  -> koordinator har partition'ga "COMMIT" belgisini yozadi

O'quvchi "read_committed" rejimida:
  faqat COMMIT belgisi kelgan tranzaksiya yozuvlarini ko'radi;
  ABORT bo'lganlarini tashlab ketadi

Siqishdan oldin:   [42:Toshkent] [7:Buxoro] [42:Samarqand] [7:null] [9:Xiva]
Siqishdan keyin:   [42:Samarqand] [9:Xiva]           (7 o'chirilgan)
Offset'lar o'zgarmaydi — faqat "teshiklar" paydo bo'ladi

6. Replikatsiya: bitta yozuvning hayoti

6.1 Qadam-baqadam

5-bo‘limning 5–7-qadamlari natijani berdi. Bu yerda — bitta yozuv yetakchiga kelgandan tasdiqlangungacha nima bo‘lishini sekin ko‘ramiz. RF=3, min.insync.replicas=2, acks=all.

Bir muhim detal: yetakchi izdoshning LEO sini uning keyingi fetch so‘rovidan biladi (“menga offset 101 dan ber” — demak, 0..100 menda bor). Shuning uchun HW siljishi uchun odatda ikki fetch aylanishi kerak: birinchisida izdosh yozuvni oladi, ikkinchisida yetakchi buni bilib, HW ni siljitadi. Tasdiq kechikishi — bir necha millisekund.

6.2 ISR qachon kichrayadi

Izdosh replica.lag.time.max.ms (standart 30 soniya) davomida yetakchining jurnal oxiriga yetib olmasa, ISR dan chiqariladi. Sabablar: broker qulashi, tarmoq uzilishi, disk sekinligi, uzoq GC pauzasi, juda katta yuk.

ISR kichrayishi — yaxshi va yomon xabar birga. Yaxshi: bitta sekin izdosh butun partition’ni to‘xtatmaydi — HW qolgan ISR bo‘yicha siljiydi. Yomon: himoya kamayadi. ISR=2 (RF=3 da) — bitta broker yo‘qolishiga chidaydi; ISR=1 — min.insync.replicas=2 bilan yozish to‘xtaydi.

6.3 Yetakchi o‘lganda nima yo‘qoladi, nima qoladi

Ikkinchi qator nuqtai nazaridan muhim: Kafka standart bo‘yicha kutadi. Bu bank yoki to‘lov hodisalari uchun to‘g‘ri tanlov. Loglar yoki metrikalar uchun (bir necha daqiqalik yo‘qotish kechirimli) toza bo‘lmagan saylovni yoqish mavjudlikni oshiradi — lekin bu ongli qaror bo‘lishi kerak.

Ikki nusxa: A (yetakchi, 0-davr) va B.
1. A m1 (offset 0) va m2 (offset 1) ni yozadi, B ikkalasini ham oladi.
   A: HW = 2. B ning HW si hali 1 (yangilanish keyingi fetch'da keladi).
2. Elektr o'chadi — ikkala server ham qulaydi. B da m2 hali faqat operatsion
   tizim keshida edi (diskka yozilmagan) — B ning jurnali: [m1].
3. B birinchi bo'lib ishga tushadi va yetakchi bo'ladi (1-davr).
   B m3 ni qabul qiladi -> offset 1 = m3.   B: [m1, m3]
4. A ishga tushadi, izdosh bo'ladi. Eski qoida: "o'z HW'ing (=2) gacha kes" ->
   A hech narsa kesmaydi: [m1, m2]. Keyin fetch(2) — B da offset 2 yo'q.
   NATIJA: offset 1 da A da m2, B da m3 — nusxalar ABADIY ajralgan.

7. O‘quvchilar: offset, lag va semantika

7.1 Offset’ni qachon commit qilish

O‘quvchi xabarni oladi, ishlaydi (masalan, bazaga yozadi) va offset’ni commit qiladi. Qulash istalgan paytda bo‘lishi mumkin. Tartib natijani belgilaydi:

Amalda eng keng tarqalgani — kamida bir marta va idempotent ishlash: xabar ikki marta kelsa ham natija o‘zgarmaydi (masalan, bazaga UPSERT buyurtma raqami bo‘yicha). Bu Airbnb darsidagi idempotentlik kalitining aynan o‘zi.

7.2 Lag — asosiy sog‘liq ko‘rsatkichi

Lag — partition oxiri (LEO yoki HW) va o‘quvchining commit qilingan offset’i orasidagi farq. Lag o‘sib borsa — o‘quvchilar yozuvchilardan sekin.

Lag’ni xabarlarda emas, vaqtda o‘lchash qulayroq: “o‘quvchi 9 daqiqa orqada” har qanday topic uchun bir xil tushuniladi. Bu darsning skini ham shunday: o‘ng tomondagi “consumer lag” — qolgan daqiqalar.

poll() -> 500 ta xabar
har xabar: tashqi API chaqiruvi ~1 s   (sekin!)
500 x 1 s = 500 s > 300 s  -> o'quvchi guruhdan chiqariladi
  -> rebalance: uning partition'lari boshqasiga o'tadi
  -> commit qilinmagan 500 xabar QAYTA ishlanadi (boshqa o'quvchida)
  -> yangi o'quvchi ham 500 s ishlaydi -> yana chiqariladi ... cheksiz

7.3 Issiq kalit

Bir xil kalit — bir xil partition (2.3). Agar bitta kalit juda mashhur bo‘lsa (masalan, eng yirik mijozning barcha hodisalari), uning partition’i qiziydi, qolganlari bo‘sh turadi — va bu partition’ni guruhda faqat bitta o‘quvchi o‘qiy oladi.

Bu Airbnb darsidagi “mashhur uy” va Uber’dagi “issiq katak” bilan bir xil muammo: kalit bo‘yicha taqsimlash — kalitlar tekis bo‘lsagina tekis. Kalit tanlash — tartib kafolati va yuk taqsimoti orasidagi murosa.

8. Exactly-once: nima mumkin va nima mumkin emas

8.1 Takrorlar qayerdan keladi

“Aynan bir marta” ni tushunish uchun takrorlarning uchta manbaini ajratish kerak:

Uchinchi qator eng muhimi: Kafka faqat Kafka ichidagi holatni boshqaradi. Email, SMS, bank o‘tkazmasi, tashqi API chaqiruvi — ular tranzaksiyaga kirmaydi. Agar o‘quvchi email yuborib, offset’ni commit qilishdan oldin qulasa, email ikkinchi marta ketadi. Buning uchun email xizmatining o‘zi idempotent bo‘lishi kerak (masalan, “bu hodisa ID si uchun email allaqachon yuborilgan”).

8.2 Tranzaksiya qanday ko‘rinadi

offset: 100  101  102  103  104  105  106  107
        T1   T1   x    T2   T1   T2   T1c  y
T1 — tranzaksiya 1 yozuvlari, T1c — T1 ning COMMIT belgisi
T2 — hali ochiq tranzaksiya, x va y — tranzaksiyasiz yozuvlar

8.3 Qachon exactly-once kerak emas

9. Bugungi arxitektura

Diagrammadagi eng muhim xususiyat — ishlab chiqaruvchilar va iste’molchilar bir-birini bilmaydi. Ular faqat topic nomini va xabar formatini bilishadi. Yangi iste’molchi qo‘shish ishlab chiqaruvchilarga tegmaydi; ishlab chiqaruvchini almashtirish iste’molchilarga tegmaydi. 1-bo‘limdagi N × M muammosi N + M ga aylanadi.

Tarixdagi eng qiziq kuzatuv: Kafka rivojlanishining katta qismi jurnal g‘oyasini o‘zining ichiga qo‘llash. Offset’lar — jurnalda (__consumer_offsets). Tranzaksiya holati — jurnalda. Metadata — jurnalda (KRaft). Oqimli ishlov holati — siqilgan jurnalda. Bitta kuchli abstraksiya tizimning har qatlamida qayta ishlatiladi.

10. Ishonchlilik

10.1 Nosozliklar taksonomiyasi

Beshinchi qator Kafka’ga xos va jim: agar o‘quvchi 7 kundan ko‘p orqada qolsa, uning o‘qimagan xabarlari saqlash muddati tugagani uchun o‘chiriladi. Hech qanday xato yo‘q — ma’lumot shunchaki yo‘q. Lag ogohlantirishi saqlash muddatidan ancha oldin chalinishi kerak.

10.2 Bitta hodisa: disk to‘ldi

Hodisaning asosiy saboqi — bir mijoz umumiy resursni egallab oladi. Himoya ikki qatlamli: har topic uchun hajm chegarasi (retention.bytes, vaqt chegarasidan tashqari) va har mijoz uchun kvotalar (sekundiga baytlar). Kvota oshsa, broker mijozni sekinlashtiradi (javobni kechiktiradi), rad etmaydi — mijoz o‘zi sekinlashadi, boshqalar ta’sirlanmaydi.

3 AZ, 9 broker (har AZ da 3):
  partition 0: yetakchi az-a/b1, izdoshlar az-b/b4, az-c/b7
  partition 1: yetakchi az-b/b5, izdoshlar az-c/b8, az-a/b2
  ...
Bitta AZ yo'qolsa: har partition'da 2 nusxa qoladi -> ISR = 2
  min.insync.replicas = 2 -> yozish davom etadi

11. Xavfsizlik va ma’lumot sifati

11.1 Kim yozadi, kim o‘qiydi

Kafka ko‘pincha kompaniyaning barcha hodisalarini tashiydi: to‘lovlar, shaxsiy ma’lumotlar, parollarni tiklash tokenlari. Standart sozlamada esa Kafka ochiq: tarmoqqa ulangan har kim istalgan topic’ni o‘qiy va yoza oladi.

11.2 Zaharli xabar

Xavfsizlikning boshqa tomoni — noto‘g‘ri ma’lumot. Bitta ishlab chiqaruvchi formatni buzsa (maydon nomini o‘zgartirsa, JSON o‘rniga matn yuborsa), barcha o‘quvchilar shu xabarda xato beradi.

for xabar in poll():
    try:
        ishla(xabar)
    except FormatXatosi as e:           # qayta urinish yordam bermaydi
        dlq.send(xabar, sabab=str(e))   # alohida topic'ga
    except VaqtinchalikXato:            # tarmoq, baza band
        qayta_urin(xabar, kutish=eksponensial)   # bir necha marta
commit()

12. Iqtisod: bir GB/s qancha turadi

12.1 Klasterning to‘rt xarajati

Kafka klasteri hisobida odatda to‘rtta qator bor: serverlar (CPU va xotira), disklar, tarmoq (ayniqsa bulutda zonalararo trafik) va odamlar (boshqarish). Bulutda eng kutilmagani — uchinchisi.

Hisobning xulosasi: bulutda katta Kafka klasterining eng katta xarajati ko‘pincha serverlar ham, disklar ham emas, tarmoq. Shuning uchun uchta eng samarali optimallashtirish: siqish (3-qadam) — hamma narsani bir necha barobar kamaytiradi; izdoshdan o‘qish (10.1 Deep) — o‘quvchi trafigini yo‘q qiladi; va ishlab chiqaruvchilarni yetakchi joylashgan AZ ga yaqinlashtirish.

12.2 Disk va saqlash muddati

Tipik JSON hodisalari uchun (tartib jihatidan):
  algoritm   siqish nisbati   siqish tezligi    ochish tezligi
  gzip       ~5-6x            sekin             o'rtacha
  snappy     ~2.5-3x          juda tez          juda tez
  lz4        ~3x              juda tez          eng tez
  zstd       ~4-6x            tez               tez

13. Sig‘im rejalashtirish

13.1 Nechta broker

Oxirgi qator muhim tendensiyani ko‘rsatadi: tiered storage bilan brokerlar disk hajmidan ozod bo‘ladi va ular soni asosan tarmoq va CPU bo‘yicha belgilanadi. Bu yangi broker qo‘shish va buzilganini almashtirishni ham tezlashtiradi: ko‘chirish kerak bo‘lgan ma’lumot kam.

13.2 Nechta partition

- O'quvchilar parallelligi chegaralangan (guruhda partition <= o'quvchi)
- Bitta partition bitta broker diskida — o'tkazuvchanlik chegarasi
- Issiq kalitlar ko'proq to'qnashadi

- Har partition = bir necha ochiq fayl (segmentlar, indekslar) + xotira
- Yetakchi saylovlari: broker o'lganda uning 10 000 partition'i uchun
  10 000 ta saylov (KRaft da tez, ZooKeeper davrida sekin edi)
- Producer to'plamlari partition bo'yicha — ko'p partition = kichik
  to'plamlar = yomon siqish va ko'proq so'rovlar
- Rebalance sekinroq, har o'quvchi ko'proq partition kuzatadi

14. Kuzatuv

14.1 Metrikalar

14.2 Uchidan-uchiga tekshiruv

Ichki metrikalar klaster sog‘ligini ko‘rsatadi, lekin mijoz tajribasini emas. Shuning uchun kanareyka (S3 darsidagi kabi): har AZ da doimiy ravishda maxsus topic’ga vaqt belgili xabar yozadigan va o‘qiydigan kichik jarayon. U “yozishdan o‘qishgacha necha ms” ni to‘g‘ridan-to‘g‘ri o‘lchaydi va har qanday qatlamdagi muammoni (tarmoq, broker, kontroller, TLS sertifikati muddati) bitta raqamda ko‘rsatadi.

15. Antinaqshlar

Birinchi qator — eng keng tarqalgani. Kafka — jurnal, navbat emas: partition ichida xabarlar tartib bilan ishlanadi va bitta xabar keyingisini kutadi. Agar vazifalar turli vaqt olsa (bittasi 10 ms, boshqasi 10 daqiqa), sekin vazifa uning ortidagi hammani ushlab turadi. Vazifalar navbati uchun (har vazifani mustaqil ishchi oladi, tartib muhim emas) klassik navbat tizimlari yoki Kafka’ning yangi “share group” imkoniyati (16-bo‘lim) mosroq.

Ikkinchi qator sezilmaydigan xavf: hamma narsa ishlaydi, test o‘tadi, va faqat yetakchi to‘satdan o‘lganda bir necha ming xabar yo‘qoladi — hech qanday xato xabarisiz.

Uchinchi qator avtomatik commit bilan tasodifan paydo bo‘ladi: ba’zi mijozlarda offset’lar fonda davriy commit qilinadi — xabar hali ishlanmagan bo‘lishi mumkin. Muhim oqimlar uchun commit’ni ishlashdan keyin, qo‘lda qilish kerak.

To‘rtinchi qator — “global tartib” talabi. Ko‘pincha u haqiqatan kerak emas: tartib bitta ob’ekt (buyurtma, foydalanuvchi, hisob) ichida kerak, va kalit shu ob’ekt ID si bo‘lsa, tartib saqlanadi va yuk tarqaladi.

Beshinchi qator 13-bo‘limdagi Check’ning amaliy natijasi.

Kafka BERADI:                         Kafka BERMAYDI:
- ishonchli, tartibli jurnal            - kalit bo'yicha tez qidiruv
- kalit bo'yicha oxirgi qiymat          - ikkinchi darajali indekslar
  (siqilgan topic, to'liq o'qish orqali) - so'rovlar (filtr, JOIN)
- hodisalarni qayta o'ynash             - bir nechta kalit ustida tranzaksiya
                                          (mustaqil ilova holati bilan)

16. Trade-off‘lar

Jadvaldagi har juftlik ikki o‘q orasida: kechikish va o‘tkazuvchanlik (to‘plash) yoki mavjudlik va saqlanish (acks, min ISR). Kafka’ning kuchi — bu tanlovni har topic, hatto har ishlab chiqaruvchi uchun alohida qilish imkoniyati: to‘lov hodisalari qat’iy, metrikalar va loglar tez va arzon.

Oddiy consumer group:  partition -> aynan bitta o'quvchi, tartib bilan
Share group:           partition -> bir nechta o'quvchi birga o'qiydi,
                       har xabar alohida "qarzga olinadi" (acquire),
                       ishlangach tasdiqlanadi yoki muddati o'tsa
                       boshqa o'quvchiga qaytariladi

Butun dars o‘nta gapda

1. Kafka — faqat oxiriga yoziladigan jurnal: yozuvlar o‘zgarmaydi, o‘quvchining holati — bitta son (offset) (2-bo‘lim).
2. Markaziy jurnal N × M integratsiyani N + M ga aylantiradi: manbalar va iste’molchilar bir-birini bilmaydi (1.1).
3. Disk sekin emas — tasodifiy disk sekin: ketma-ket yozish, to‘plash, operatsion tizim keshi va nol-nusxa Kafka tezligining asosi (3–4-qadamlar).
4. Partition — parallellik va tartib birligi: tartib faqat partition ichida, kalit partition’ni belgilaydi (1-qadam, 2.3).
5. Tasdiqlangan = high watermark o‘tgan: ISR dagi hamma nusxada bor, yetakchi o‘lsa ham yo‘qolmaydi (5-qadam, 6-bo‘lim).
6. acks=all + min.insync.replicas=2 — xavfsiz sozlama; ISR kichrayganda tizim yozishni to‘xtatadi, lekin yolg‘on tasdiq bermaydi (6-qadam).
7. Leader epoch — nusxalar “qayergacha kesish kerak”ni HW dan emas, yetakchilik davridan biladi; aks holda yo‘qotish va ajralish (7-qadam).
8. Offset’ni qachon commit qilish — semantikani belgilaydi: ishlashdan keyin commit + idempotent ishlov — eng keng tarqalgan yo‘l (7.1).
9. Exactly-once — Kafka ichida: idempotent producer + tranzaksiyalar + read_committed; tashqi tizimlar uchun — sizning idempotentligingiz (8-bo‘lim).
10. Jurnal g‘oyasi hamma joyda: offset’lar, tranzaksiyalar, metadata (KRaft) — hammasi Kafka ichida jurnal sifatida saqlanadi (9-bo‘lim).

17. Intervyu savollari

17.1 Jurnal va partition

17.2 Replikatsiya va tasdiq

17.3 O‘quvchilar, semantika va ekspluatatsiya

18. Amaliyot

To‘rt daraja. Ikkinchi daraja uchun kod docs/amaliyot/kafka/ da: replication.py — yetakchi va izdosh mantiqi, yettita funksiya TODO; model.py — tayyor Record, Replica va LeaderState; sim.py — uch brokerli simulyator (qulash, qaytish, tarmoq uzilishi, toza saylov, elektr o‘chishi); check.py — 16 ta tekshiruv, taxminan bir soniya. Faqat Python standart kutubxonasi.

1. xaos:      tasodifan broker qulaydi yoki qaytadi, izdosh tarmoqdan uziladi
2. saylov:    yetakchi o'lgan bo'lsa -> ISR dagi tirik nusxadan yangisi, davr + 1
3. kesish:    yangi yetakchiga ulangan izdoshlar dumini kesadi
              (end_offset_for_epoch -> truncate)
4. yozish:    uch ishlab chiqaruvchi append qiladi; javob yo'qolsa -> qayta yuboradi
5. o'qish:    o'quvchi HW gacha o'qiydi (consumer_read)
6. fetch:     har izdosh ~50% ehtimol bilan yetakchidan nusxa oladi
              (on_fetch + on_response)
7. tasdiq:    HW yozuvdan o'tgan bo'lsa -> ishlab chiqaruvchiga "yozildi"

1. Tasdiqlangan xabar yo'qolmaydi:
     ishlab chiqaruvchi "yozildi" olgan har xabar yakuniy jurnalda, HW dan oldin
2. Takror yo'q:        har qiymat jurnalda bir marta
3. Nusxalar bir xil:   tinchlangandan keyin uch jurnal bayt-baqayt teng
4. Arvoh o'qish yo'q:  o'quvchi ko'rgan har (offset, qiymat) yakuniy jurnalda
                       aynan shu joyda turadi
5. Tiriklik:           xaos tugagach, tizim cheklangan vaqtda tinchlanadi

                     Raft (5 nusxa)        Kafka ISR (RF=3, min.isr=2)
disk va trafik       5x                    3x
tasdiq kutadi        ko'pchilikni (3)      ISR ning hammasini (2-3)
sekin nusxa          kutilmaydi            ISR dan chiqariladi (30 s)
2 nosozlik           chidaydi              ma'lumot chidaydi, yozish to'xtaydi
                                           (ISR < min.isr) — ongli tanlov
metadata             o'zida                tashqi kontrollerda (KRaft)

19. Lug‘at

20. Raqamlar manbasi

Klasterlar hajmi va oqimlar, xabar hajmlari, kechikishlar, broker va tarmoq tezliklari, bulut narxlari (zonalararo trafik, disk, ob’ekt ombori), o‘quvchi tezliklari va partition sonlari — illyustratsiya uchun taxminiy. Haqiqiy qiymatlar apparat, bulut provayderi va sozlamalarga qarab bir necha barobar farq qiladi. Asosiy xulosalar — ketma-ket yozish tasodifiydan yuzlab barobar tez; to‘plash so‘rovlar sonini keskin kamaytiradi; ishonchlilik fsync emas, replikatsiyadan keladi; o‘quvchi faqat HW gacha ko‘radi; bulutda asosiy xarajat ko‘pincha zonalararo trafik — bu raqamlarning bir necha barobarlik xatosiga ham chidamli.

21. Manbalar

• Jay Kreps, Neha Narkhede, Jun Rao (2011), “Kafka: a Distributed Messaging System for Log Processing”, NetDB
• Jay Kreps (2013), “The Log: What every software engineer should know about real-time data’s unifying abstraction”, LinkedIn Engineering
• LinkedIn Engineering (2019), “How LinkedIn customizes Apache Kafka for 7 trillion messages per day”
• Apache Kafka hujjatlari: Design (persistence, efficiency, replication), Operations, Configuration
• KIP-98: Exactly Once Delivery and Transactional Messaging
• KIP-101: Alter Replication Protocol to use Leader Epoch rather than High Watermark for Truncation
• KIP-279: Fix log divergence between leader and follower after fast leader fail over
• KIP-392: Allow consumers to fetch from closest replica
• KIP-405: Kafka Tiered Storage
• KIP-429: Kafka Consumer Incremental Rebalance Protocol
• KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum
• KIP-848: The Next Generation of the Consumer Rebalance Protocol
• KIP-932: Queues for Kafka
• Neha Narkhede (2017), “Exactly-once Semantics Are Possible: Here’s How Kafka Does It”, Confluent blog
• Diego Ongaro, John Ousterhout (2014), “In Search of an Understandable Consensus Algorithm”, USENIX ATC (Raft)
• Kyle Kingsbury (2013), “Jepsen: Kafka”, aphyr.com