IlmHamroh
Python kursi/Miqyos va unumdorlik5/10-dars19 daqiqa
Mundarija (22)

29.5-dars: Navbatlar (Kafka / RabbitMQ)

29-QISM — MIQYOS VA UNUMDORLIK · 5-dars


1. Kirish va motivatsiya

Celery 29.4-bob navbatlarni ishlatadi, lekin uning ostida broker turadi — xabarlarni saqlaydigan va yetkazadigan tizim. Ikki eng mashhur broker bor: RabbitMQ va Kafka — va ular tubdan farqli. Noto'g'ri brokerni tanlash — muammo: RabbitMQ ni katta hodisa oqimi uchun ishlatish (sekin), yoki Kafka ni oddiy vazifa navbati uchun (haddan murakkab). Ular turli muammolarni yechadi: RabbitMQ — an'anaviy navbat (vazifa yetkazish), Kafka — hodisa oqimi (katta ma'lumot, tarix). Brokerni tushunish — to'g'ri vositani tanlash.

Navbatlar (Kafka / RabbitMQ) — ikki xil xabar broker: RabbitMQ (an'anaviy xabar navbati — smart broker: xabarlarni yo'naltiradi, yetkazadi, o'chiradi; vazifa taqsimlash), Kafka (hodisa oqimi platformasi — dumb broker, smart consumer: xabarlar logda saqlanadi, consumerlar o'z tezligida o'qiydi; katta hajm, tarix). Tushunchalar: xabar yetkazish kafolatlari (at-most-once, at-least-once, exactly-once), pub-sub 27.10-bob, consumer group (Kafka), acknowledgment (RabbitMQ). Farq: RabbitMQ — xabar iste'mol qilinadi (o'chadi), Kafka — saqlanadi (qayta o'qish — 27.10 event streaming). Bu Celery (29.4 — broker), hodisaga asoslangan 27.10-bob bilan bog'liq. Broker tanlovi — muammoga qarab. Har broker — o'z ehtiyoji.

Real vaziyat. Bir tizimda barcha uchun RabbitMQ ishlatilardi, jumladan analitika hodisalari (har foydalanuvchi harakati — millionlab). RabbitMQ bunga mos emas edi (xabar iste'mol qilinadi, tarix yo'q, katta hajm sekin). Kafka qo'shildi: analitika hodisalari Kafka'ga (saqlanadi, katta hajm, ko'p consumer — analitika, ML, hisobot o'z tezligida o'qiydi), vazifalar RabbitMQ'da qoldi (email, rasm — vazifa yetkazish). To'g'ri broker to'g'ri ish uchun — tizim samarali bo'ldi. Broker tanlovi — muammoga mos.

Bu darsda Kafka va RabbitMQ ni o'rganamiz.

Bu darsda:

  • Broker nima (Celery ostida)
  • RabbitMQ (an'anaviy navbat)
  • Kafka (hodisa oqimi)
  • RabbitMQ vs Kafka farqi
  • Xabar yetkazish kafolatlari
  • Consumer group va partition
  • Broker tanlovi
  • Amaliy: broker modeli

ℹ Kafka/RabbitMQ alohida tizim; misollar Python bilan broker mantiqini modellashtiradi (deterministik).


2. Nazariya — chuqur tushuntirish

2.1. Broker nima (Celery ostida)

Xabarlarni saqlash va yetkazish:

Broker — xabar (vazifa/hodisa) saqlovchi va yetkazuvchi
   producer → BROKER → consumer/worker

Celery ostida: broker (Redis, RabbitMQ) — navbatni saqlaydi
   ikki mashhur: RabbitMQ (navbat), Kafka (oqim) — farqli!

Broker (xabar broker — message broker) — producer va consumer orasida xabarlarni (vazifa, hodisa) saqlovchi va yetkazuvchi vositachi 27.10-bob: producer xabar yuboradi → broker saqlaydi → consumer oladi. Sabab: producer va consumer to'g'ridan bog'lanmasin (ajratilgan — 27.10, 29.4), xabar yo'qolmasin (saqlash), yetkazish ishonchli. Ikki asosiy broker — RabbitMQ (an'anaviy navbat) va Kafka (hodisa oqimi) — tubdan farqli (turli muammo). Broker — Celery 29.4-bob, hodisa 27.10-bob ostida. Broker — xabar yetkazuvchi. Ikki xil — ikki maqsad.

2.2. RabbitMQ (an'anaviy navbat)

Smart broker — xabarni yo'naltiradi:

RabbitMQ (an'anaviy navbat):
   producer → exchange → navbat → consumer
   xabar consumer olganda O'CHADI (iste'mol qilinadi)
   broker "aqlli" — yo'naltiradi (routing), yetkazadi

foydalanish: vazifa taqsimlash (email, rasm)

RabbitMQ — an'anaviy xabar navbati (smart broker — aqlli vositachi): producer xabar yuboradi → exchange (yo'naltirgich — qaysi navbatga) → navbat → consumer oladi; xabar consumer olganda o'chadi (iste'mol qilinadi — bir marta). Broker "aqlli": yo'naltirish (routing — kalit bo'yicha), yetkazish, acknowledgment (consumer "oldim" desa o'chadi). Foydalanish: vazifa taqsimlash (email, rasm — bir vazifa bir consumer, iste'mol qilinadi — 29.4 Celery bilan). RabbitMQ — vazifa yetkazish (iste'mol qilinadigan). Smart broker — yo'naltiradi.

2.3. Kafka (hodisa oqimi)

Dumb broker — xabar saqlanadi:

Kafka (hodisa oqimi):
   producer → topic (log) → consumer o'z tezligida O'QIYDI
   xabar SAQLANADI (o'chmaydi — qayta o'qish mumkin)
   broker "sodda" — consumer aqlli (offset kuzatadi)

foydalanish: analitika, hodisa oqimi (katta hajm, tarix)

Kafka — hodisa oqimi platformasi (dumb broker, smart consumer): producer xabar yuboradi → topic (mavzu — log, ketma-ket saqlanadi) → consumer o'z tezligida o'qiydi; xabar saqlanadi (o'chmaydi — qayta o'qish mumkin, 27.10 event streaming). Broker "sodda" (faqat saqlaydi), consumer "aqlli" (offset — qayergacha o'qiganini kuzatadi). Foydalanish: analitika, hodisa oqimi (katta hajm — millionlab hodisa, ko'p consumer — har biri o'z tezligida, tarix — qayta o'qish, ML). Kafka — hodisalar log (saqlanadi, qayta o'qiladigan). Dumb broker — saqlaydi.

2.4. RabbitMQ vs Kafka farqi

Jihat RabbitMQ Kafka
Model Navbat (iste'mol) Log (saqlanadi)
Xabar Olganda o'chadi Saqlanadi (qayta o'qish)
Broker Aqlli (routing) Sodda (log)
Consumer Sodda Aqlli (offset)
Hajm O'rta Juda katta
Foydalanish Vazifa taqsimlash Hodisa oqimi, analitika

RabbitMQ vs Kafka — tub farq: RabbitMQ — navbat (xabar iste'mol qilinadi — olganda o'chadi; smart broker — routing; vazifa taqsimlash — email, rasm; o'rta hajm); Kafka — log (xabar saqlanadi — qayta o'qish; sodda broker, smart consumer — offset; hodisa oqimi — analitika, katta hajm — millionlab). Boshqacha: RabbitMQ "bir vazifa, bir consumer" (iste'mol), Kafka "bir hodisa, ko'p consumer o'z tezligida" (saqlanadi). Farq maqsadda (vazifa vs hodisa) va modelda (iste'mol vs saqlash). Tanlov — muammoga qarab. Farq — vazifa vs oqim.

2.5. Xabar yetkazish kafolatlari

Xabar necha marta yetkaziladi:

At-most-once (ko'pi bilan bir marta):
   xabar yo'qolishi mumkin, lekin takror emas (tez, ishonchsiz)

At-least-once (kamida bir marta):
   xabar yetkaziladi, lekin takror bo'lishi mumkin (idempotent!)

Exactly-once (aynan bir marta):
   ideal, lekin qiyin/qimmat (murakkab)

Xabar yetkazish kafolatlari: At-most-once (ko'pi bilan bir marta — xabar yo'qolishi mumkin, lekin takror emas; tez, ishonchsiz — muhim bo'lmagan hodisaga); At-least-once (kamida bir marta — xabar yetkaziladi, lekin takror bo'lishi mumkin — shuning uchun idempotentlik 26.9 zarur!); Exactly-once (aynan bir marta — ideal, lekin qiyin/qimmat — murakkab koordinatsiya). Sabab: taqsimlangan tizimda (27.9 — tarmoq, yiqilish) xabar yo'qolishi yoki takrorlanishi mumkin — kafolat darajasi tanlanadi (muhimlik vs narx). Ko'p tizim at-least-once + idempotent (amaliy). Kafolat — ishonchlilik darajasi. Takror bo'lsa — idempotent kerak.

2.6. Consumer group va partition

Kafka miqyoslash:

Kafka topic → partition (bo'laklar — parallel)
   consumer group → har consumer bir partition o'qiydi (parallel)

partition — miqyoslash (ko'p consumer parallel)
   tartib — bir partition ichida (butun topicda emas)

Consumer group va partition (Kafka miqyoslash): Partition (bo'lak) — topic bir necha bo'lakka bo'linadi (parallel o'qish uchun); Consumer group — consumerlar guruhi, har biri bir yoki bir necha partition o'qiydi (parallel — 29.6 miqyoslash). Sabab: bir consumer katta topicni o'qib ulgurmaydi (millionlab hodisa) — partition parallel qiladi (ko'p consumer). Tartib faqat bir partition ichida kafolatlanadi (butun topicda emas — parallel). Bu Kafka'ni yuqori hajmga miqyoslaydi. Consumer group — parallel iste'mol (miqyoslash). Partition — parallel o'qish.

2.7. Broker tanlovi

Broker tanlovi — muammoga qarab: RabbitMQ (yoki Redis — Celery bilan) — vazifa navbati (email, rasm, fon vazifa — 29.4), murakkab yo'naltirish (routing), o'rta hajm, bir vazifa bir consumer; Kafka — hodisa oqimi (analitika, log, katta hajm — millionlab, ko'p consumer, tarix — qayta o'qish, event sourcing — 27.11); Redis (oddiy — kichik navbat, kesh bilan — 29.3). Ehtiyot: Kafka'ni oddiy navbatga (haddan murakkab), RabbitMQ'ni katta oqimga (sekin, tarix yo'q) — noto'g'ri tanlov. Ko'p tizim ikkalasini ishlatadi (RabbitMQ vazifa, Kafka hodisa). Tanlov — vazifa turi, hajm, tarix ehtiyoji. Broker — muammoga mos. To'g'ri broker — samarali.

2.8. Broker — xabar arxitekturasining yuragi

Broker — xabar-asosli arxitekturaning yuragi: producer/consumer ajratish 27.10-bob, navbat 29.4-bob, hodisa oqimi 27.10-bob, event sourcing 27.11-bob — barchasi broker ustiga quriladi. RabbitMQ va Kafka — ikki paradigma: navbat (xabar iste'mol qilinadi — vazifa) va log (xabar saqlanadi — hodisa/tarix). To'g'ri tanlov muhim (noto'g'ri — sekin yoki murakkab). Bu mikroservis (27.9 — xizmatlararo xabar), hodisaga asoslangan 27.10-bob, CQRS/ES 27.11-bob uchun infratuzilma. Xabar yetkazish kafolatlari (at-least-once + idempotent) — ishonchlilik asosi. Broker — taqsimlangan tizimda xabar aloqasi. Yurak — xabar oqimi.


3. Tez ma'lumotnoma

RABBITMQ (an'anaviy navbat):
   producer → exchange (routing) → navbat → consumer
   xabar iste'mol qilinadi (olganda o'chadi)
   smart broker · vazifa taqsimlash (email, rasm)

KAFKA (hodisa oqimi):
   producer → topic (log, partition) → consumer (offset)
   xabar saqlanadi (qayta o'qish mumkin)
   smart consumer · analitika, hodisa oqimi (katta hajm, tarix)

YETKAZISH KAFOLATLARI:
   at-most-once (yo'qolishi mumkin, tez)
   at-least-once (takror mumkin — IDEMPOTENT!)
   exactly-once (ideal, qiyin/qimmat)

KAFKA MIQYOSLASH: partition (parallel) + consumer group

TANLOV:
   RabbitMQ/Redis — vazifa navbati (Celery — 29.4)
   Kafka — hodisa oqimi, analitika, tarix (event sourcing — 27.11)

Kafka / RabbitMQ xulosasi

Broker — xabar saqlovchi/yetkazuvchi (Celery ostida)
RabbitMQ — navbat (iste'mol, smart broker, vazifa)
Kafka — log (saqlanadi, smart consumer, hodisa oqimi)
Kafolatlar: at-least-once (takror — idempotent!) · exactly-once (qiyin)
Kafka miqyos: partition + consumer group · tanlov muammoga qarab

4. Batafsil misollar

Kafka/RabbitMQ alohida tizim; misollar Python bilan broker mantiqini modellashtiradi.

Misol 1 — RabbitMQ: xabar iste'mol qilinadi

python
"""RabbitMQ modeli: xabar consumer olganda o'chadi (iste'mol)."""
from collections import deque


class RabbitNavbat:
    def __init__(self) -> None:
        self.navbat: deque = deque()

    def yubor(self, xabar: str) -> None:
        self.navbat.append(xabar)

    def ol(self) -> str | None:
        # consumer oladi — xabar O'CHADI (iste'mol)
        return self.navbat.popleft() if self.navbat else None


def main() -> None:
    navbat = RabbitNavbat()

    print("=== 1. Xabarlar yuborish ===")
    for x in ["email-1", "email-2", "email-3"]:
        navbat.yubor(x)
    print(f"  navbatda: {len(navbat.navbat)}")

    print("\n=== 2. Consumer oladi (iste'mol) ===")
    x = navbat.ol()
    print(f"  olindi: {x}")
    print(f"  navbatda qoldi: {len(navbat.navbat)} (o'chdi)")

    print("\n=== 3. Qolgan xabarlarni olish ===")
    while True:
        x = navbat.ol()
        if x is None:
            break
        print(f"  {x} (bajarildi, o'chdi)")

    print("\n=== 4. Xabar qayta o'qib bo'lmaydi ===")
    print(f"  navbat bo'sh: {len(navbat.navbat)} (iste'mol qilingan)")
    print("  bir vazifa bir consumer (o'chadi)")
    print("  ⭐ RabbitMQ — xabar iste'mol qilinadi")


if __name__ == "__main__":
    main()

Natijaning muhim qismi:

text
=== 1. Xabarlar yuborish ===
  navbatda: 3

=== 2. Consumer oladi (iste'mol) ===
  olindi: email-1
  navbatda qoldi: 2 (o'chdi)

=== 3. Qolgan xabarlarni olish ===
  email-2 (bajarildi, o'chdi)
  email-3 (bajarildi, o'chdi)

=== 4. Xabar qayta o'qib bo'lmaydi ===
  navbat bo'sh: 0 (iste'mol qilingan)
  bir vazifa bir consumer (o'chadi)
  ⭐ RabbitMQ — xabar iste'mol qilinadi

Nima ko'rsatdi: 2.2-bo'lim.

Misol 2 — Kafka: xabar saqlanadi (qayta o'qish)

python
"""Kafka modeli: xabarlar logda saqlanadi, consumer offset bilan o'qiydi."""


class KafkaTopic:
    def __init__(self) -> None:
        self.log: list = []   # xabarlar SAQLANADI (o'chmaydi)

    def yubor(self, xabar: str) -> int:
        self.log.append(xabar)
        return len(self.log) - 1   # offset

    def oqi(self, offset: int) -> list:
        # offsetdan boshlab o'qish (qayta o'qish mumkin)
        return self.log[offset:]


def main() -> None:
    topic = KafkaTopic()

    print("=== 1. Hodisalar yuborish (saqlanadi) ===")
    for h in ["klik", "korish", "xarid", "klik"]:
        topic.yubor(h)
    print(f"  logda: {len(topic.log)} hodisa (saqlangan)")

    print("\n=== 2. Consumer 1 (boshidan o'qiydi) ===")
    for h in topic.oqi(0):
        print(f"  {h}")

    print("\n=== 3. Consumer 2 (2-offsetdan) ===")
    for h in topic.oqi(2):
        print(f"  {h}")

    print("\n=== 4. Qayta o'qish (tarix saqlangan) ===")
    print(f"  Consumer 1 qayta o'qiy oladi: {len(topic.oqi(0))} hodisa")
    print("  xabar o'chmaydi (ko'p consumer, o'z tezligida)")
    print("  ⭐ Kafka — xabar saqlanadi (qayta o'qish)")


if __name__ == "__main__":
    main()

Natijaning muhim qismi:

text
=== 1. Hodisalar yuborish (saqlanadi) ===
  logda: 4 hodisa (saqlangan)

=== 2. Consumer 1 (boshidan o'qiydi) ===
  klik
  korish
  xarid
  klik

=== 3. Consumer 2 (2-offsetdan) ===
  xarid
  klik

=== 4. Qayta o'qish (tarix saqlangan) ===
  Consumer 1 qayta o'qiy oladi: 4 hodisa
  xabar o'chmaydi (ko'p consumer, o'z tezligida)
  ⭐ Kafka — xabar saqlanadi (qayta o'qish)

Nima ko'rsatdi: 2.3-bo'lim.

Misol 3 — Yetkazish kafolatlari (at-least-once, idempotent)

python
"""Yetkazish kafolatlari: at-least-once takror mumkin → idempotentlik zarur."""


class IdempotentConsumer:
    def __init__(self) -> None:
        self.qayta_ishlangan: set = set()   # ID lar (takrorni aniqlash)
        self.natija: list = []

    def qabul(self, xabar_id: str, amal: str) -> str:
        # idempotent: bir xil ID qayta kelsa — o'tkazib yuboradi
        if xabar_id in self.qayta_ishlangan:
            return f"{xabar_id}: o'tkazib yuborildi (takror)"
        self.qayta_ishlangan.add(xabar_id)
        self.natija.append(amal)
        return f"{xabar_id}: {amal} bajarildi"


def main() -> None:
    consumer = IdempotentConsumer()

    print("=== 1. Xabarlar (at-least-once — takror mumkin) ===")
    print(f"  {consumer.qabul('msg-1', 'email')}")
    print(f"  {consumer.qabul('msg-2', 'sms')}")

    print("\n=== 2. Xabar takror keldi (tarmoq — qayta yetkazildi) ===")
    print(f"  {consumer.qabul('msg-1', 'email')}  (takror!)")

    print("\n=== 3. Idempotentlik ===")
    print(f"  bajarilgan amallar: {consumer.natija}")
    print("  msg-1 ikki marta keldi, lekin bir marta bajarildi")

    print("\n=== 4. Nega muhim ===")
    print("  at-least-once — takror bo'lishi mumkin")
    print("  idempotent 26.9-bob — takror zararsiz")
    print("  ⭐ Kafolat — takror mumkin (idempotent zarur)")


if __name__ == "__main__":
    main()

Natijaning muhim qismi:

text
=== 1. Xabarlar (at-least-once — takror mumkin) ===
  msg-1: email bajarildi
  msg-2: sms bajarildi

=== 2. Xabar takror keldi (tarmoq — qayta yetkazildi) ===
  msg-1: o'tkazib yuborildi (takror)  (takror!)

=== 3. Idempotentlik ===
  bajarilgan amallar: ['email', 'sms']
  msg-1 ikki marta keldi, lekin bir marta bajarildi

=== 4. Nega muhim ===
  at-least-once — takror bo'lishi mumkin
  idempotent 26.9-bob — takror zararsiz
  ⭐ Kafolat — takror mumkin (idempotent zarur)

Nima ko'rsatdi: 2.5-bo'lim.

Misol 4 — Consumer group va partition (parallel)

python
"""Partition: topic bo'laklarga bo'linadi, consumer group parallel o'qiydi."""


def partitionlash(hodisalar: list, partition_soni: int) -> dict:
    # hodisalarni partitionlarga taqsimlash (barqaror hash — belgilar yig'indisi)
    partitionlar: dict = {i: [] for i in range(partition_soni)}
    for h in hodisalar:
        p = sum(ord(c) for c in h) % partition_soni
        partitionlar[p].append(h)
    return partitionlar


def main() -> None:
    hodisalar = ["a", "b", "c", "d", "e", "f"]

    print("=== 1. Bir partition (bir consumer, ketma-ket) ===")
    bir = partitionlash(hodisalar, 1)
    print(f"  partition 0: {len(bir[0])} hodisa")

    print("\n=== 2. Uch partition (uch consumer, parallel) ===")
    uch = partitionlash(hodisalar, 3)
    for p, hlar in uch.items():
        print(f"  partition {p}: {len(hlar)} hodisa")

    print("\n=== 3. Consumer group (har consumer bir partition) ===")
    print("  consumer-1 → partition 0")
    print("  consumer-2 → partition 1")
    print("  consumer-3 → partition 2 (parallel)")

    print("\n=== 4. Miqyoslash ===")
    print("  ko'p partition → ko'p consumer (parallel — tez)")
    print("  tartib faqat bir partition ichida")
    print("  ⭐ Partition — parallel o'qish (miqyoslash)")


if __name__ == "__main__":
    main()

Natijaning muhim qismi:

text
=== 1. Bir partition (bir consumer, ketma-ket) ===
  partition 0: 6 hodisa

=== 2. Uch partition (uch consumer, parallel) ===
  partition 0: 2 hodisa
  partition 1: 2 hodisa
  partition 2: 2 hodisa

=== 3. Consumer group (har consumer bir partition) ===
  consumer-1 → partition 0
  consumer-2 → partition 1
  consumer-3 → partition 2 (parallel)

=== 4. Miqyoslash ===
  ko'p partition → ko'p consumer (parallel — tez)
  tartib faqat bir partition ichida
  ⭐ Partition — parallel o'qish (miqyoslash)

Nima ko'rsatdi: 2.6-bo'lim.


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

Noto'g'ri fikr To'g'risi
"RabbitMQ = Kafka" Navbat (iste'mol) vs log (saqlanadi)
"Xabar doim saqlanadi" RabbitMQ — iste'mol, Kafka — saqlaydi
"Bir broker hamma ishga" Muammoga qarab (vazifa vs oqim)
"Exactly-once oson" Qiyin/qimmat (at-least-once + idempotent)
"At-least-once — takror yo'q" Takror mumkin (idempotent!)
"Kafka oddiy navbatga" Haddan murakkab (RabbitMQ)
"Kafka tartibli (butun)" Bir partition ichida
"Broker — detal" Arxitektura yuragi

6. Keng tarqalgan xatolar va yechimlari

1. Kafka'ni oddiy navbatga

python
# email vazifasiga Kafka (haddan murakkab)          # ⚠️
# RabbitMQ/Redis (vazifa navbati — 29.4)             # ✅

2. RabbitMQ'ni katta oqimga

python
# millionlab analitika hodisasi RabbitMQ'da          # ⚠️
# Kafka (katta hajm, tarix)                           # ✅

3. At-least-once, idempotent emas

python
# takror xabar → ikki marta bajarildi                # ⚠️
# idempotent (xabar ID — takrorni aniqlash)           # ✅

4. Exactly-once ni kutish

python
# exactly-once oson deb kutish                        # ⚠️
# at-least-once + idempotent (amaliy)                  # ✅

5. Kafka tartibga tayanish (butun topic)

python
# butun topic tartibli deb kutish                     # ⚠️
# tartib bir partition ichida (kalit bilan)            # ✅

6. Broker monitoring yo'q

python
# navbat to'lyaptimi? consumer lag? (noma'lum)        # ⚠️
# monitoring (navbat uzunligi, lag — 28.10)            # ✅

7. Bitta partition (miqyoslanmaydi)

python
# bir partition (bir consumer — sekin)                # ⚠️
# ko'p partition (parallel consumer)                   # ✅

7. Integratsiya — bu bilim qayerda kerak bo'ladi

  • 29.4-dars (o'tilgan): Celery — broker (RabbitMQ/Redis)
  • 27.10-dars (o'tilgan): Hodisaga asoslangan — Kafka
  • 27.11-dars (o'tilgan): Event Sourcing — Kafka (log)
  • 27.9-dars (o'tilgan): Mikroservis — xizmatlararo xabar
  • 28.10-dars (o'tilgan): Monitoring — consumer lag

8. Eng yaxshi amaliyotlar

  1. RabbitMQ/Redis — vazifa navbati (Celery).

  2. Kafka — hodisa oqimi (katta hajm, tarix).

  3. At-least-once + idempotent (takror zararsiz).

  4. Idempotentlik (xabar ID — takrorni aniqlash).

  5. Kafka — ko'p partition (parallel miqyos).

  6. Monitoring (navbat uzunligi, consumer lag).

  7. To'g'ri broker (muammoga qarab).

  8. Tartib — bir partition ichida (kalit bilan).


9. Amaliy topshiriq

Vazifa 1: Bashorat qiling

python
1.  # broker nima?
2.  # RabbitMQ nima?
3.  # RabbitMQ xabari o'chadimi?
4.  # Kafka nima?
5.  # Kafka xabari o'chadimi?
6.  # RabbitMQ vs Kafka?
7.  # at-most-once nima?
8.  # at-least-once nima?
9.  # nega idempotent (at-least-once)?
10. # partition nima?
11. # consumer group nima?
12. # broker tanlovi?
Javoblar
  1. Xabar saqlovchi/yetkazuvchi vositachi
  2. An'anaviy navbat (smart broker)
  3. Ha (iste'mol qilinadi — olganda)
  4. Hodisa oqimi (log, saqlanadi)
  5. Yo'q (saqlanadi — qayta o'qish)
  6. Navbat (iste'mol) vs log (saqlanadi)
  7. Yo'qolishi mumkin, takror emas
  8. Yetkaziladi, takror mumkin
  9. Takror bo'lsa — bir marta bajarish
  10. Topic bo'lagi (parallel)
  11. Consumerlar guruhi (parallel o'qish)
  12. Muammoga qarab (vazifa vs oqim)

Vazifa 2: Xatolarni tuzating

python
1.  # email vazifasiga Kafka

2.  # millionlab hodisa RabbitMQ'da

3.  # takror xabar → ikki marta

4.  # exactly-once oson

5.  # butun topic tartibli
Javoblar
python
1.  RabbitMQ/Redis (vazifa)

2.  Kafka (katta hajm, tarix)

3.  idempotent (xabar ID)

4.  at-least-once + idempotent

5.  tartib bir partition ichida

Vazifa 3: RabbitMQ

Modellang:

  1. Navbat
  2. Yuborish
  3. Iste'mol
  4. O'chish

Vazifa 4: Kafka

Modellang:

  1. Log
  2. Offset
  3. O'qish
  4. Qayta o'qish

Vazifa 5: Kafolatlar

Modellang:

  1. At-least-once
  2. Takror
  3. Idempotent
  4. Bir marta

Vazifa 6: Partition

Modellang:

  1. Partitionlar
  2. Taqsimlash
  3. Consumer group
  4. Parallel

Vazifa 7: O'ylash

RabbitMQ (xabar iste'mol qilinadi) va Kafka (xabar saqlanadi) — ikki tub paradigma. Nima uchun "xabar saqlanadimi yoki iste'mol qilinadimi" degan bir farq shunchalik katta oqibatlarga olib keladi (butun arxitektura o'zgaradi), va nega "to'g'ri vosita to'g'ri ish uchun" tamoyili (bir universal yechim emas) muhandislikda takrorlanadi?

Javob

Qisqa javob: "Xabar saqlanadimi yoki iste'mol qilinadimi" tub farq, chunki u butun ma'lumot oqimi modelini belgilaydi: iste'mol (RabbitMQ) — xabar bir marta ishlatiladi, keyin yo'qoladi (vazifa — email yuborildi, tugadi; tarix kerak emas) — bu "hozir bajar" modeli (buyruq — 27.5 Command); saqlash (Kafka) — xabar log'da qoladi, ko'p consumer o'z tezligida o'qiydi, qayta o'qish mumkin (hodisa — "klik bo'ldi", ko'p tomon qiziqadi: analitika, ML, hisobot) — bu "bo'ldi, kim xohlasa" modeli (hodisa — 27.10). Bu farq oqibatlari katta: (1) consumer soni (iste'mol — bir consumer; saqlash — ko'p consumer); (2) tarix (iste'mol — yo'q; saqlash — bor, event sourcing — 27.11); (3) qayta ishlash (iste'mol — yo'q; saqlash — yangi consumer eski hodisalarni o'qiy oladi); (4) miqyos (turli — partition vs navbat). Ya'ni bir dizayn qarori (saqlash vs iste'mol) butun arxitekturani (consumer, tarix, miqyos) belgilaydi. "To'g'ri vosita to'g'ri ish uchun" muhandislikda takrorlanadi, chunki: universal yechim yo'q (har vosita muayyan muammoga optimallashtirilgan — savdolar bilan: RabbitMQ vazifaga tez/oddiy, lekin tarixsiz; Kafka oqimga kuchli, lekin murakkab); bir vositani hamma ishga ishlatish — noto'g'ri joyda savdolar (Kafka oddiy navbatga — murakkablik; RabbitMQ katta oqimga — sekin). Bu "oltin bolg'a" (golden hammer — bir vositani hamma muammoga) anti-namunasi. Muhandislik — muammoni tushunish, mos vositani tanlash (vosita muammoga xizmat qiladi, teskarisi emas). Bu 27.9 (monolit/mikroservis), 28.13 (cloud) da ham: kontekstga qarab tanlov. Muhandislik saboqlari: dizayn qarori (saqlash vs iste'mol) butun arxitekturani belgilaydi; universal yechim yo'q (har vosita — savdolar); to'g'ri vosita to'g'ri ish uchun (oltin bolg'adan saqlan); muammoni tushun, keyin vositani tanla.

1. Nega bir farq katta oqibat

Saqlash vs iste'mol — ma'lumot oqimi modelini belgilaydi. Iste'mol: "hozir bajar" (buyruq). Saqlash: "bo'ldi, kim xohlasa" (hodisa).

2. Oqibatlar

Jihat Iste'mol (RabbitMQ) Saqlash (Kafka)
Consumer Bir Ko'p
Tarix Yo'q Bor
Qayta o'qish Yo'q Bor

Bir qaror → butun arxitektura.

3. Nega universal yechim yo'q

Har vosita muayyan muammoga optimallashtirilgan (savdolar bilan). Bir vosita hamma ishga — noto'g'ri joyda savdolar.

4. Oltin bolg'a anti-namunasi

Bir vositani hamma muammoga (Kafka oddiyga, RabbitMQ kattaga). Vosita muammoga xizmat qilishi kerak.

5. Muhandislik saboqlari

  1. Dizayn qarori butun arxitekturani belgilaydi
  2. Universal yechim yo'q (savdolar)
  3. To'g'ri vosita to'g'ri ish uchun
  4. Muammoni tushun, keyin tanla

6. Xulosa

  1. Saqlash vs iste'mol — oqim modelini belgilaydi
  2. Bir qaror → consumer, tarix, miqyos
  3. Universal yechim yo'q (har vosita savdolar)
  4. To'g'ri vosita (oltin bolg'adan saqlan)

Nimani mustahkamlaydi: 2.4, 2.7-bo'limlar.


Xulosa

Bu darsda Kafka va RabbitMQ ni o'rgandik.

Eng muhim uch fikr:

  1. Broker, RabbitMQ, Kafka. Broker — producer va consumer orasida xabarlarni saqlovchi va yetkazuvchi vositachi (Celery 29.4, hodisa 27.10 ostida). RabbitMQ — an'anaviy navbat (smart broker): producer → exchange (routing) → navbat → consumer; xabar consumer olganda o'chadi (iste'mol qilinadi); vazifa taqsimlash (email, rasm). Kafka — hodisa oqimi (dumb broker, smart consumer): producer → topic (log) → consumer offset bilan o'qiydi; xabar saqlanadi (o'chmaydi — qayta o'qish, 27.10 event streaming); analitika, katta hajm, ko'p consumer, tarix.

  2. Farq va yetkazish kafolatlari. RabbitMQ vs Kafka: RabbitMQ — navbat (iste'mol — o'chadi, smart broker, o'rta hajm, bir vazifa bir consumer), Kafka — log (saqlanadi — qayta o'qish, smart consumer/offset, katta hajm, ko'p consumer). Yetkazish kafolatlari: at-most-once (yo'qolishi mumkin, takror emas — tez), at-least-once (yetkaziladi, takror mumkin — idempotentlik 26.9 zarur!), exactly-once (ideal, qiyin/qimmat); ko'p tizim at-least-once + idempotent (amaliy).

  3. Miqyoslash, tanlov, arxitektura yuragi. Kafka partition (topic bo'laklar — parallel) + consumer group (har consumer bir partition — parallel miqyoslash); tartib faqat bir partition ichida. Broker tanlovi muammoga qarab: RabbitMQ/Redis (vazifa navbati — Celery), Kafka (hodisa oqimi, analitika, tarix — event sourcing 27.11); Kafka'ni oddiy navbatga (haddan murakkab) yoki RabbitMQ'ni katta oqimga (sekin) — noto'g'ri. Broker — xabar-asosli arxitekturaning yuragi (27.10, 29.4, 27.11 ustiga quriladi). "Xabar saqlanadimi yoki iste'mol qilinadimi" — tub farq (butun arxitekturani belgilaydi: consumer, tarix, miqyos); "to'g'ri vosita to'g'ri ish uchun" (universal yechim yo'q — har vosita savdolar; oltin bolg'adan saqlan).

Keyingi darsda yuk taqsimlashni o'rganamiz: kirib kelayotgan so'rovlarni ko'p server orasida taqsimlash — load balancer, taqsimlash algoritmlari (round-robin), sog'liq tekshiruvi va gorizontal miqyoslash.

Ulashish:Telegram'da

Izohlar (0)

Izoh yozish uchun kiring.

  • Hozircha izoh yo'q. Birinchi bo'ling!
29.5-dars: Navbatlar (Kafka / RabbitMQ) — IlmHamroh