Хабар брокерлері

1) Неліктен брокерлер хабарлар

• Пиктерді буферлеу және тегістеу, бэкпресер.
• Оқуды/жазуды дербес масштабтау.
• Оқиғаларды бақылау және көрсету (replay).
• Сәулет үлгілері: event-driven, CQRS, event sourcing, outbox/inbox.

2) Базалық модельдер мен терминдер

2. 1 Kafka (логтық үлгі)

Топик → партия (реттелген логтар) → консюмерлердегі офсеттер.
Consumer Group: оқу параллелизмі, партияларды теңестіру.
Уақыт/көлем бойынша ретеншн; кілт бойынша компакция.
Семантика: ең төменгі - at-least-once, теңшеу кезінде - effectively exactly-once (демпотенттік продюсерлер + транзакциялар).
Тәртiп: партия iшiнде кепiлдiк берiледi.

2. 2 NATS (тақырыптар/subjects, төмен кідіріс)

Subject (тақырып) иерархиясы мен вайлдкарталары бар ('foo.', 'foo. >`).
Режимдер: pub/sub, queue-groups (жұмысты бөлумен фан-аут), request-reply (жылдам RPC).
Core NATS - эфемерлік, өте төмен латенттілік; JetStream - персистенттілік/ретеншн/қайталау.
Тәртіп: күшті жаһандық кепілдіксіз ең жақсы күш-жігер; JetStream - ағында ретке келтіру, бірақ істен шыққан кезде сирек ретке келтіру мүмкін.

3) Жеткізу семантикасы және келісу

Идемпотенттік және дедуп - Kafka-дағы «exactly-once» кезінде де қолданбаның/синктің жауапкершілігі.

4) Тәртіп, партиялану және кілттер

Kafka

Хабар кілтін таңдау партияны анықтайды → күшті жергілікті тәртіп.
Ключи: `aggregate_id`, `tenant_id`, `order_id`. Ыстық кілттерден аулақ болыңыз.
Баланс: Партияның N ≈ оқу параллелизмінің деңгейі.

NATS

Core теңгерімін queue-group жасайды.
JetStream Stream subjects бойынша шардингіленеді; кішігірім кідіріспен кең фан-аут/фан-инге екпін.

5) Ретеншн, реплика және компакция

Kafka

Retention: `retention. ms/bytes`.
Compaction: «соңғы кілт мәнін» сақтайды (snapshots/кэштер/сағаттар үшін жарамды).
Replay: Кез келген консюмер офсетті «кері қарай» алады.

JetStream

Streams: файл/мемори бэкендтер, уақыт/байт/хабар саны бойынша сақтау саясаты.
Consumers: pull/push, durable/ephemeral, subject-префикстер бойынша сүзгі.
Replay: redelivery немесе басынан оқу/offset-like (sequence).

6) Транзакциялар, outbox және келісу

Kafka

Idempotent Producer (`enable. idempotence = true '): қосарланудан қорғау.
Transactions: бірнеше партиялардың атомарлық жазбасы + коммит consumer-offsets → паттерн read-process-write «тесіксіз».
Transactional Outbox: бизнес-оқиғаларды және outbox-жолдарды бір БД-транзакцияда жазу, воркер Kafka-да жариялайды.

NATS

Kafka сияқты «ағымдық» транзакциялар жоқ; outbox/inbox және демпотенттік консумерлерді (кілттер, дедуп-стор) пайдаланыңыз.

7) RPC және сұрау-жауап

RPC үшін Kafka ыңғайсыз (жоғары overhead, тәртіп/жауаптар күрделі). Асинхронды командаларды/оқиғаларды пайдаланыңыз.
NATS: request-reply (милисекундтар, корелляция, таймауттар) үшін тамаша.

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

8) Пайдалану және топологиялар

8. 1 Kafka

Кластер: брокерлер + ZooKeeper (ескі нұсқаларға дейін) немесе KRaft (жаңа метадаттар).
Репликация: аймақтар бойынша RF ≥ 3, ISR/бақылаушылар.
Мультирегион: MirrorMaker 2/Cluster Linking; актив-пассив/дау-саясаткерлермен актив-актив.
Дискілік/желілік сыйымдылық: 'throughput × retention × replicas' -тен санау.

8. 2 NATS

Cluster: бірнеше тораптар, super-cluster (геораспределение), периферия/edge үшін leafnodes.
JetStream: тораптар жиыны бойынша ағындарды орналастыру (placement), репликалау (R = 1.. 5).
WAN: болжамды төмен кідірістер, жеңіл федерация.

9) Қауіпсіздік

Kafka

TLS (mTLS), SASL: SCRAM, OAuthBearer.
Топиктер/топтар/транзакциялар үшін ACL.
«Тыныштықта» шифрлау (OS/дискілер) + желілік саясат.

NATS

nkey/JWT сәйкестігі, оператор-аккаунттар, пер-subject ACL.
mTLS тораптар мен клиенттер арасында.
Жалдаушыларды оқшаулау (accounts) + лимиттер.

10) Бақылау және пайдалану метрикасы

Kafka

Брокер: `BytesIn/Out`, `RequestQueue`, `UnderReplicatedPartitions`, GC/FS stats.
Топик/партия: 'logEndOffset', consumer lag (сыни).
Продюсер/консюмер: ретраи, 'batch. size`, `linger. ms`, `fetch. min. bytes ', қателер.
Құралдар: JMX, Cruise Control (ре-баланс), Schema Registry.

NATS/JetStream

Сервер: conn/msgs/sec, RTT, CPU/mem, slow consumer детекциясы.
JetStream: per stream/consumer — lag, redeliveries, acks, storage bytes.
Мониторинг: кіріктірілген endpoint, nsc/adm-CLI, дашбордтар.

11) Өнімділік және тюнинг

Kafka

Үлкен батчилер және 'linger. ms 'throughput жақсартады және p99 қысады.
Компрессия (lz4/zstd) желіні/дискіні үнемдейді.
num. тұтынушылар/ядролар саны бойынша partitions, бірақ асып кетпеу (overhead).
Дискілер: NVMe таңдалған, XFS/EXT4 'noatime'.

NATS

Ұсақ хабарламалар, қосылыстар көп - норма; queue groups «кең» ұстаңыз.
JetStream: tune `max_ack_pending`, pull vs push, size of batches.
Backpressure: `FlowControl`, `IdleHeartbeat`, server-side limits.

12) Интеграция паттерндері

Outbox/Inbox (Kafka және NATS).
SAGA: оқиғалармен оркестрлеу; дедуп бойынша 'saga _ id + step'.
Change Data Capture (CDC): Debezium → Kafka; NATS-ке - «ДБ-триггерлерден/логдардан publisher» үлгісі.
Stream processing: Kafka Streams/Flink/Spark; NATS - сыртқы процессорлар/функциялар, JetStream consumers.
Dead Letter Queue (DLQ) және retry-саясат (экспоненциалды backoff + jitter).

13) Конфигурация мысалдары

13. 1 Kafka: топик жасау және продюсер

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: іспеттес өңдеу (эскиз)

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 таңдау: жылдам бағдар

Реплика, ұзақ ретеншн, компакция, ауыр стрим-процестер қажет → Kafka.
Жылдам RPC, микролатенттілігі бар фан-аут/фан-ин, қарапайым пайдалану, edge/IoT → NATS (Core) қажет.
Тұрақтылық + жанкүйер-аут қажет, бірақ ауыр «логтық» платформасыз → NATS JetStream.
Кілт және транзакция бойынша қатаң тәртіп → Kafka.

15) Сыйымдылықты жоспарлау (оңайлатылған)

Kafka

1. Өткізу: 'inbound _ MBps × RF × retention_days × 86400' → дискілер.
2. 'target _ concurrency' × қор 1. 5–2×.
3. Желі: p99 + репликация + компрессор продюсері.

NATS/JetStream

1. Хабарламалар/сек және орташа өлшемі → throughput.
2. Retention×replicas → storage.
3. Серияландыруға арналған CPU, consumers (ack-pending, redeliveries) лимиттері.

16) Қауіпсіз пайдалану: чек-парақ

• TLS/mTLS қосылған, құпиялар айналады.
• ACL/шоттар/квоталар (per-tenant).
• Демпотенттік, DLQ және джиттермен ретраялар.
• lag/throughput/қателер мониторингі; URP (Kafka), redelivery-дауылға (NATS) арналған алерталар.
• Capacity dashboards: партия, storage, p99.
• Түйіндердің/аймақтардың, game-days, репликалардың/бэкфилдердің істен шығуына арналған тестілер.
• Партиялану және схема кілттері құжатталған (Schema Registry/JSON Schema).
• Ретеншн/компакция/TTL саясаты комплаенспен келісілген.
• Брокерлердің/клиенттердің нұсқалары үнемі жаңартылып отырады; wire-хаттаманың үйлесімділігі тексерілді.

17) Қарсы үлгілер

Ыстық кілт (барлық оқиғалар бір ID) → бір «қайнаған» ағын. Шардалаңыз/буферлеңіз.
Демпотентсіз ретрайлер → дубль-эффекттер.
Үлкен хабарламалар (MB-ондаған) → GC фрагментациясы/үзілісі. Payload бағдарламасын нысанда сақтаңыз, сілтемелерді жіберіңіз.
RPC және striming араластыру Kafka → күрделі өмірлік цикл/тәртіп.
JetStream «ұзақ мерзімді DWH» → мақсаты бойынша емес; объектілік/бағаналық соқпақтарда ұзақ сақтаңыз.
Жоқ DLQ → «улы» хабарлар шексіз айналады.
Ұмытылған ретеншн → дискілер толды, кластерді тоқтату.

18) FAQ

Q: Пайплайн соңында «exactly-once» жасауға бола ма?
A: Практикада - тиімді иә: Kafka (демпотенттік продюсер + транзакциялар) және демпотенттік синкалар (кілт, upsert). NATS-те - қосымшадағы идемпотенттілік/дедуп арқылы.

Q: миллион ұсақ RPC/сек үшін не таңдау керек?
A: NATS Core: микролатенттілік, request-reply, жеңіл коннектілер және queue-groups.

Q: Компакция және жай-күй снапшоты қажет пе?
A: Kafka с `cleanup. policy = compact ', кілт = агрегат/ресурс.

Q: Лагпен қалай күресуге болады?
A: Партиялардың/воркерлердің санын ұлғайту, өңдеу уақытын азайту, батч және prefetch, десериализацияны оңтайландыру, брокерлер/дискілерді тігінен күшейту.

Q: Көп аймақ және DR?
A: Kafka - MirrorMaker 2/Cluster Linking, RPO-мен актив-пассив ≈ секунд. NATS — supercluster/leafnodes; JetStream аймақтар бойынша зеркалау/реплика.

19) Қорытынды

Kafka және NATS түрлі режимдерді жабады: Kafka - ұзақ мерзімді оқиғалар журналы, жоғары throughput, транзакциялық және реплика; NATS - төмен кідірістер, RPC және қарапайым фан-аута үшін өте жеңіл шина, тұрақтылық үшін JetStream бар. Жеткізу семантикасынан, ретеншн тәртібінен, жасырындылықтан және операциялық шығындардан таңдау жасаңыз. Кілттерді/партияларды, ретеншн, DLQ және бақылау мүмкіндіктерін жобалаңыз - оқиғаның архитектурасы болжамды, масштабталатын және сенімді болады.