Mesaj brokerləri

1) Niyə broker mesajlar

• Tamponlama və hamarlama zirvələri, backpresher.
• Müstəqil oxu/yazını ölçmək.
• Hadisə müşahidə və replay.
• Memarlıq nümunələri: event-driven, CQRS, event sourcing, outbox/inbox.

2) Əsas modellər və şərtlər

2. 1 Kafka (Log modeli)

Topik → partiyalar (nizamlı qeydlər) → konsumerlərdə ofsetlər.
Consumer Group: oxu paralelliyi, partiyalar balansı.
Retenshn vaxt/həcm; açar kompaksiyası.
Semantika: minimum - at-least-once, parametrlər - effectively exactly-once (idempotent istehsalçıları + əməliyyatlar).
Sifariş: partiya daxilində zəmanət verilir.

2. 2 NATS (mövzular/subjects, aşağı gecikmə)

Hiyerarxiya və wildcarts ('foo.', 'foo. >`).
Rejimlər: pub/sub, queue-groups (iş paylanması ilə fan-out), request-reply (sürətli RPC).
Core NATS - efemer, ultra aşağı gecikmə; JetStream - persistentlik/retenshn/təkrar.
Sifariş: güclü qlobal zəmanət olmadan ən yaxşı səy; JetStream ilə - axını qaydaya salmaq, lakin uğursuzluqlar zamanı nadir qaydaya salmaq mümkündür.

3) Çatdırılma semantikası və uyğunluq

İdempotentlik və dedup - Kafka-da «exactly-once» ilə belə app/sink məsuliyyəti.

4) Sıra, Partizan və Açarlar

Kafka

Mesaj açarının seçilməsi partiyanı müəyyən edir → güclü yerli nizam.
Ключи: `aggregate_id`, `tenant_id`, `order_id`. İsti açarlardan çəkinin.
Balans: N partiya ≈ oxu paralellik səviyyəsi.

NATS

Core balans queue-group edir.
JetStream Stream subjects; kiçik gecikmə ilə geniş fan-out/fan-in diqqət.

5) Retenshn, replay və kompaksiya

Kafka

Retention: `retention. ms/bytes`.
Compaction: «Son açar dəyərini» saxlayır (snapshot/caches/sage üçün uygundur).
Replay: Hər hansı bir konsumer ofseti «geri çəkə» bilər.

JetStream

Streams: fayl/memory backends, vaxt/bayt/mesaj sayı saxlama siyasəti.
Consumers: pull/push, durable/ephemeral, subject prefiksləri ilə filter.
Replay: redelivery və ya əvvəldən oxu/offset-like (sequence).

6) əməliyyatlar, outbox və uyğunluq

Kafka

Idempotent Producer (`enable. idempotence = true '): dubl müdafiəsi.
Transactions: bir neçə partiyanın atom yazısı + kommit consumer-offsets → «deşik» olmadan nümunə read-process-write.
Transactional Outbox: biznes hadisə və bir DB-əməliyyat outbox-line qeyd, worker Kafka dərc edir.

NATS

Kafka kimi «axın» əməliyyatları yoxdur; outbox/inbox və idempotent konsumerləri istifadə edin (açarlar, dedup store).

7) RPC və sorğu-cavab

Kafka RPC üçün əlverişsizdir (yüksək overhead, sifariş/cavablar daha mürəkkəbdir). Asenkron əmrlərdən/hadisələrdən istifadə edin.
NATS: request-reply (milisaniyələr, korelasiya, taymautlar) üçün idealdır.

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

8) Əməliyyat və topologiyalar

8. 1 Kafka

Klaster: brokerlər + ZooKeeper (köhnə versiyalara qədər) və ya KRaft (yeni metadata).
Replikasiya: RF ≥ 3 zonaları, ISR/Controller.
Multiregion: MirrorMaker 2/Cluster Linking; aktiv-passiv/münaqişə siyasətçiləri ilə aktiv-aktiv.
Disk/şəbəkə tutumu: 'throughput × retention × replicas'.

8. 2 NATS

Cluster: periferiya/edge üçün bir çox düyünlər, super-cluster (geo-paylama), leafnodes.
JetStream: düyün dəstləri üzrə axınların yerləşdirilməsi (placement), replikasiya (R = 1.. 5).
WAN: proqnozlaşdırıla bilən aşağı gecikmələr, yüngül federasiya.

9) Təhlükəsizlik

Kafka

TLS (mTLS), SASL: SCRAM, OAuthBearer.
Topiklər/qruplar/əməliyyatlar üçün ACL.
Yalnız şifrələmə (OS/disklər) + şəbəkə siyasəti.

NATS

nkey/JWT şəxsiyyət, operator hesabları, per-subject ACL.
mTLS qovşaqlar və müştərilər arasında.
İcarəçilərin təcrid olunması (accounts) + limitlər.

10) Müşahidə və istismar metrikası

Kafka

Брокер: `BytesIn/Out`, `RequestQueue`, `UnderReplicatedPartitions`, GC/FS stats.
Topik/partiya: 'logEndOffset', consumer lag (kritik).
Prodüser/konsumer: retrai, 'batch. size`, `linger. ms`, `fetch. min. bytes ', səhvlər.
Alətlər: JMX, Cruise Control (yenidən balans), Schema Registry.

NATS/JetStream

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

11) Performans və sazlama

Kafka

Böyük batches və 'linger. ms 'throughput yaxşılaşdırmaq və p99 sıxmaq.
Kompressiya (lz4/zstd) şəbəkə/disk qənaət edir.
num. istehlakçıların/nüvələrin sayına görə partitions, lakin aşmaq deyil (overhead).
Disklər: 'noatime' ilə XFS/EXT4 NVMe-yə üstünlük verilir.

NATS

Kiçik mesajlar, çoxlu birləşmələr - norma; queue groups «geniş» saxlayın.
JetStream: tune `max_ack_pending`, pull vs push, size of batches.
Backpressure: `FlowControl`, `IdleHeartbeat`, server-side limits.

12) İnteqrasiya nümunələri

Outbox/Inbox (və Kafka, və NATS).
SAGA: hadisə orkestri; dedup 'saga _ id + step'.
Change Data Capture (CDC): Debezium → Kafka; NATS-də - «DB-trigger/loqlardan publisher» patterni.
Stream processing: Kafka Streams/Flink/Spark; NATS - üçüncü tərəf prosessorları/funksiyaları, JetStream consumers.
Dead Letter Queue (DLQ) və retry-siyasətlər (eksponensial backoff + jitter).

13) Konfiqurasiya nümunələri

13. 1 Kafka: topika yaratmaq və prodüser

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: İdempotent emalı (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 seçimi: sürətli istinad

Replica, uzun müddətli retenshn, kompaksiya, ağır axın prosesləri → Kafka lazımdır.
Sürətli RPC, mikro patentli fan-out/fan-in, sadə əməliyyat, edge/IoT → NATS (Core) lazımdır.
Davamlı + fan-out lazımdır, lakin ağır «log» platforması olmadan → NATS JetStream.
Açar və əməliyyatlar → Kafka.

15) Tutumun planlaşdırılması (sadələşdirilmiş)

Kafka

1. Keçid: 'inbound _ MBps × RF × retention_days × 86400' → disklər.
2. Partiya: 'target _ concurrency' × ehtiyatı 1. 5–2×.
3. Şəbəkə: p99 + replikasiya + kompressor istehsalçısı.

NATS/JetStream

1. Mesajlar/san və orta ölçüsü → throughput.
2. Retention×replicas → storage.
3. Limitlər consumers (ack-pending, redeliveries), serializasiya üçün CPU.

16) Təhlükəsiz əməliyyat: çek siyahısı

• TLS/mTLS daxil, sirləri fırlanır.
• ACL/hesablar/kvotalar (per-tenant).
• Konsumerlərdə idempotentlik, DLQ və jitter ilə retraj.
• lag/throughput/səhvlərin monitorinqi; URP (Kafka), redelivery-fırtına (NATS).
• Capacity dashboards: parties, storage, p99.
• Düyün/zona, game-days, replay/backfill imtahanları.
• Partizan və sxem açarları sənədləşdirilmişdir (Schema Registry/JSON Schema).
• Retenshn/kompaksiya/TTL siyasətləri komplayenslə razılaşdırılmışdır.
• Brokerlərin/müştərilərin versiyaları müntəzəm olaraq yenilənir; wire-protokol uyğunluğu yoxlanılır.

17) Anti-nümunələr

Hot Key (bütün hadisələr bir ID) → bir «qaynayan» axın. Şard/bufer.
İdempotentlik olmadan retraj → cüt effektlər.
Böyük mesajlar (MB-onlarca) → GC parçalanma/fasilələr. Obyektdə payload saxlayın, linkləri göndərin.
Kafka → mürəkkəb həyat dövrü/sifariş RPC və axını qarışdırın.
JetStream kimi «uzunmüddətli DWH» → təyinatsız; obyekt/sütun yığınlarında uzun müddət saxlayın.
No DLQ → «zəhərli» mesajlar sonsuz fırlanır.
Unudulmuş retrenshn → disklər dolu, klasterin dayandırılması.

18) FAQ

Q: payplaynın sonunda «exactly-once» etmək olarmı?
A: Praktikada - effektiv bəli: Kafka (idempotent prodüser + əməliyyatlar) və idempotent sinki (açar, upsert). NATS-də - tətbiqdə idempotentlik/dedup vasitəsilə.

Q: bir milyon kiçik RPC/san üçün nə seçmək lazımdır?
A: NATS Core: mikro-patentlik, request-reply, yüngül konnektlər və queue-groups.

Q: kompaksiya və vəziyyət snapshot lazımdır?
A: Kafka с `cleanup. policy = compact ', açar = aqreqat/resurs.

Q: Lag ilə necə mübarizə aparmaq olar?
A: Partiyalar/işçilərin sayını artırın, emal vaxtını, batches və prefetch azaltın, deserializasiyanı optimallaşdırın, brokerləri/diskləri şaquli şəkildə gücləndirin.

Q: Multi-region və DR?
A: Kafka - MirrorMaker 2/Cluster Linking, ≈ saniyə RPO ilə aktiv-passiv. NATS — supercluster/leafnodes; JetStream güzgü/replika zonaları.

19) Nəticələr

Kafka və NATS müxtəlif rejimləri bağlayır: Kafka - uzunmüddətli hadisə jurnalları, yüksək throughput, əməliyyat və replica; NATS - aşağı gecikmələr, RPC və sadə fan-out üçün ultra yüngül şin, persistentlik üçün JetStream ilə. Çatdırılma semantikası, sifariş və gecikmə, gecikmə və əməliyyat xərclərindən seçim edin. Açarlar/partiyalar, retenshn, DLQ və müşahidə - və hadisə arxitekturası proqnozlaşdırıla bilən, ölçülə bilən və etibarlı olacaq.