Xabar brokerlari

1) Nima uchun xabarlar brokerlari

• Cho’qqilarni buferlash va tekislash, backpresher.
• Oʻqish/yozishni mustaqil ravishda kattalashtirish.
• Hodisalarni kuzatish va takrorlash.
• Arxitektura patternlari: event-driven, CQRS, event sourcing, outbox/inbox.

2) Bazaviy modellar va atamalar

2. 1 Kafka (log modeli)

Topik → partiyalar (tartibga solingan loglar) → konsumerlarda ofsetlar.
Consumer Group: o’qish parallelligi, partiyalarni muvozanatlash.
Vaqt/hajm bo’yicha Retenshn; kalit bo’yicha kompaksiya.
Semantika: minimal - at-least-once, sozlamalarda - effectively exactly-once (idempotent prodyuserlar + tranzaksiyalar).
Tartib: partiya ichida kafolatlanadi.

2. 2 NATS (mavzular/subjects, past kechikish)

Subject (mavzu) - iyerarxiya va wildcarts (’foo.’,’foo. >`).
Rejimlar: pub/sub, queue-groups (ish taqsimoti bilan fan-aut), request-reply (tezkor RPC).
Core NATS - efemer, o’ta past latentlik; JetStream - persistentlik/retenshn/takrorlash.
Tartib: eng yaxshi kuch bilan, kuchli global kafolatsiz; JetStream bilan - oqimda tartibga solish, lekin rad etilganda kamdan-kam tartibga solish mumkin.

3) Yetkazib berish semantikasi va muvofiqlik

Idempotentlik va dedup - Kafkadagi «exactly-once» da ham ilova/sink javobgarligi.

4) Tartib, partiyalashtirish va kalitlar

Kafka

Xabar kalitini tanlash partiyani belgilaydi → kuchli lokal tartib.
Ключи: `aggregate_id`, `tenant_id`, `order_id`. Issiq kalitlardan qoching.
Balans: N partiyalari ≈ o’qish parallelligi darajasi.

NATS

Core balansini queue-group tashkil qiladi.
JetStream Stream subjects; kichik kechikish bilan keng fan-aut/fan-inga e’tibor qaratish.

5) Retenshn, replay va kompaksiya

Kafka

Retention: `retention. ms/bytes`.
Compaction: «oxirgi kalit qiymatini» saqlaydi (snapshotlar/keshlar uchun mos keladi).
Replay: Har qanday konsumer ofsetni qaytarishi mumkin.

JetStream

Streams: fayl/xotiralar, vaqt/bayt/xabar soni boʻyicha saqlash siyosati.
Consumers: pull/push, durable/ephemeral, subject-prefikslar boʻyicha filter.
Replay: redelivery yoki boshidan oʻqish/offset-like (sequence).

6) Tranzaksiyalar, outbox va muvofiqlik

Kafka

Idempotent Producer (`enable. idempotence = true’): dubllardan himoya qilish.
Transactions: bir nechta partiyalarning atom yozuvi + kommit consumer-offsets → pattern read-process-write «teshiklarsiz».
Transactional Outbox: biznes voqealari va outbox satrlarini bitta DB-tranzaksiyada yozib olish, vorker Kafka-da e’lon qiladi.

NATS

Kafkadagi kabi «oqimli» tranzaksiyalar yo’q; outbox/inbox va idempotent konsumerlardan (kalitlar, dedup stor) foydalaning.

7) RPC va so’rov-javob

Kafka RPC uchun noqulay (yuqori overhead, tartib/javoblar qiyinroq). Asinxron buyruqlar/hodisalardan foydalaning.
NATS: request-reply (milisaniye, korelatsiya, taymautlar) uchun ideal.

go resp, err:= nc. Request("profile. get", []byte(`{"id":42}`), 200time. Millisecond)

8) Foydalanish va topologiyalar

8. 1 Kafka

Klaster: brokerlar + ZooKeeper (eski versiyagacha) yoki KRaft (yangi metadata).
Replikatsiya: RF ≥ 3 zonalar bo’yicha, ISR/nazoratchilar.
Multiregion: MirrorMaker 2/Cluster Linking; aktiv-passiv/qarama-qarshi siyosatchilar bilan aktiv-aktiv.
Disk/tarmoq sig’imi:’throughput × retention × replicas’dan hisoblansin.

8. 2 NATS

Cluster: koʻp tugunlar, super-cluster (georaylash), leafnodes/edge.
JetStream: uzellar toʻplami boʻyicha oqimlarni joylashtirish (placement), replikatsiya (R = 1.. 5).
WAN: past kechikishlar, engil federatsiya.

9) Xavfsizlik

Kafka

TLS (mTLS), SASL: SCRAM, OAuthBearer.
Topiklar/guruhlar/tranzaktsiyalar uchun ACL.
Shifrlash «tinch» (OS/disklar) + tarmoq siyosati.

NATS

nkey/JWT identifikatsiya, operator-hisoblar, per-subject ACL.
mTLS uzellar va mijozlar o’rtasida.
Ijarachilarni izolyatsiya qilish (accounts) + limitlar.

10) Kuzatuvchanlik va ekspluatatsiya metrikasi

Kafka

Брокер: `BytesIn/Out`, `RequestQueue`, `UnderReplicatedPartitions`, GC/FS stats.
Topik/partiya:’logEndOffset’, consumer lag (tanqidiy).
Prodyuser/konsumer: retrai,’batch. size`, `linger. ms`, `fetch. min. bytes’, xatolar.
Asboblar: JMX, Cruise Control (re-balans), Schema Registry.

NATS/JetStream

Server: conn/msgs/sec, RTT, CPU/mem, slow consumer deteksiya.
JetStream: per stream/consumer — lag, redeliveries, acks, storage bytes.
Monitoring: ichki endpoint, nsc/adm-CLI, dashbordlar.

11) Unumdorlik va tyuning

Kafka

Katta batchi va’linger. ms’throughput ni yaxshilaydi va p99 ni siqadi.
Siqish (lz4/zstd) tarmoq/diskni tejaydi.
num. partitions iste’molchilar/yadrolar soni bo’yicha, lekin haddan tashqari (overhead).
Disklar: NVMe’noatime’bilan XFS/EXT4.

NATS

Kichik xabarlar, ko’p birikmalar - norma; queue groups «keng» saqlang.
JetStream: tune `max_ack_pending`, pull vs push, size of batches.
Backpressure: `FlowControl`, `IdleHeartbeat`, server-side limits.

12) Integratsiya patternlari

Outbox/Inbox (Kafka va NATS).
SAGA: voqealar bilan orkestrlash; dedup po’saga _ id + step’.
Change Data Capture (CDC): Debezium → Kafka; NATSga - «DB-trigger/loglardan publisher» patterni.
Stream processing: Kafka Streams/Flink/Spark; NATS - uchinchi tomon protsessorlari/funksiyalari, JetStream consumers.
Dead Letter Queue (DLQ) va retry-siyosati (eksponensial backoff + jitter).

13) Konfiguratsiya namunalari

13. 1 Kafka: topika yaratish va prodyuser

bash kafka-topics. sh --create --topic orders \
--partitions 12 --replication-factor 3 \
--config cleanup. policy=delete \
--config retention. ms=604800000 # 7d

properties producer. properties bootstrap. servers=broker:9092 acks=all enable. idempotence=true batch. size=65536 linger. ms=10 compression. type=zstd

13. 2 Kafka Streams: idempotent ishlov berish (eskiz)

java builder. <String, Order>stream("orders")
.groupByKey()
.aggregate(/... /)
.toStream()
.to("orders-agg");

13. 3 NATS JetStream: stream + consumer (nats CLI)

bash nats stream add ORDERS --subjects "orders. " --retention limits \
--storage file --max-bytes 100GB --replicas 3 --discard old

nats consumer add ORDERS ORDERS-WORKERS --filter "orders. created" \
--deliver pull --ack explicit --max-deliver 6 --backoff "1s,5s,30s,2m"

13. 4 NATS Request-Reply (Go)

go nc, _:= nats. Connect("tls://nats:4222", nats. Secure(tlsConf))
sub, _:= nc. QueueSubscribe("calc. sum", "workers", func(m nats. Msg) {
//... process...
m. Respond([]byte("42"))
})

14) Kafka vs NATS tanlash: tezkor yo’nalish

Bizga reple, uzoq muddatli retenshn, kompaksiya, og’ir oqim jarayonlari kerak → Kafka.
Tezkor RPC, mikro patentli fan-out/fan-in, oddiy foydalanish, edge/IoT → NATS (Core) kerak.
Sizga persistentlik + fan-out kerak, ammo og’ir «log» platformasisiz → NATS JetStream.
Kalit va tranzaksiya bo’yicha qat’iy tartib → Kafka.

15) Sig’imni rejalashtirish (soddalashtirilgan tarzda)

Kafka

1. O’tkazish:’inbound _ MBps × RF × retention_days × 86400’→ disklar.
2. Partitsii:’target _ concurrency’× zaxira 1. 5–2×.
3. Tarmoq: p99 + replikatsiya + kompresssiya ishlab chiqaruvchisi.

NATS/JetStream

1. Xabarlar/sek va oʻrtacha oʻlcham → throughput.
2. Retention×replicas → storage.
3. Consumers (ack-pending, redeliveries), seriallashtirish uchun CPU limitlari.

16) Xavfsiz foydalanish: chek-varaq

• TLS/mTLS yoqilgan, sirlar aylantiriladi.
• ACL/akkauntlar/kvotalar (per-tenant).
• Konsumerlar, DLQ va jitter bilan retrajda idempotentlik.
• lag/throughput/xato monitoringi; URP (Kafka), redelivery-bo’ronga (NATS) alertlar.
• Capacity dashboards: partiyalar, storage, p99.
• Uzel/zona, game-days, replay/backfill muvaffaqiyatsiz tugun testlari.
• Partiyalash kalitlari va sxemalari (Schema Registry/JSON Schema) hujjatlashtirilgan.
• Retenshn/kompaksiya/TTL siyosati komplayens bilan kelishilgan.
• Brokerlar/mijozlar versiyalari muntazam ravishda yangilanib turadi; wire-protokolning mosligi tekshirildi.

17) Anti-patternlar

Issiq kalit (barcha voqealar bitta ID) → bitta «qaynoq» oqim. Shard/bufer.
Idempotentsiz retraylar → dubl effektlari.
Katta xabarlar (MB-oʻnlab) → GC parchalanishi/pauzalari. Payloadni obʼektda saqlang, havolalarni yuboring.
Kafkada RPC va strimingni aralashtirish → murakkab hayot sikli/tartibi.
JetStream «uzoq muddatli DWH» sifatida → boshqa maqsadlarda; obʼekt/kolonochnыy storlarda uzoq vaqt saqlang.
DLQ yo’q → «zaharli» xabarlar cheksiz aylanadi.
Unutilgan retenshn → disklar toʻldirildi, klaster toʻxtadi.

18) FAQ

Q: Payplaynning oxirida «exactly-once» qilish mumkinmi?
A: Amalda - samarali ha: Kafka (idempotent prodyuser + tranzaksiyalar) va idempotent sinki (kalit, upsert). NATSda - ilovadagi idempotentlik/dedup orqali.

Q: bir million kichik RPC/sek uchun nimani tanlash kerak?
A: NATS Core: mikrolatentlik, request-reply, yengil konnektlar va queue-groups.

Q: Kompaksiya va snapshotlar kerakmi?
A: Kafka с `cleanup. policy = compact’, kalit = agregat/resurs.

Q: Lagga qarshi qanday kurashish mumkin?
A: Partiyalar/voryerlar sonini ko’paytirish, ishlov berish vaqtini qisqartirish, batch va prefetch, deserializatsiyani optimallashtirish, brokerlar/disklarni vertikal ravishda kuchaytirish.

Q: Ko’p mintaqa va DR?
A: Kafka - MirrorMaker 2/Cluster Linking, RPO bilan aktiv-passiv ≈ soniya. NATS — supercluster/leafnodes; JetStream oynalari/replikalari.

19) Yakunlar

Kafka va NATS turli rejimlarni yopadi: Kafka - uzoq muddatli voqealar jurnallari, yuqori throughput, tranzaksion va replay; NATS - past kechikishlar, RPC va oddiy fan-aut uchun juda yengil shinalar, persistentlik uchun JetStream bilan. Yetkazib berish semantikasi, tartib va retenshn, yashirin va operatsion xarajatlardan tanlang. Kalitlar/partiyalar, retenshn, DLQ va kuzatish qobiliyatini loyihalashtiring - va voqea arxitekturasi oldindan aytib bo’ladigan, ko’paytiriladigan va ishonchli bo’ladi.