Brokerzy wiadomości

1) Dlaczego brokerzy wiadomości

• Szczytowe buforowanie i wygładzanie, backprescher.
• Czytaj/pisz skalowanie niezależnie.
• Obserwacja i powtarzalność wydarzeń.
• Wzorce architektoniczne: event-driven, CQRS, event sourcing, outbox/inbox.

2) Podstawowe modele i terminy

2. 1 Kafka (model dziennika)

Temat → strony (zamówione dzienniki) → offsety od konsumentów.
Grupa konsumentów: Czytaj paralelizm, balansowanie partii.
Retencja według czasu/objętości; zagęszczenie klucza.
Semantyka: minimum - co najmniej raz, z ustawieniami - skutecznie dokładnie raz (producenci + transakcje).
Zamówienie: Gwarantowane w ramach strony.

2. 2 NATS (pacjenci, niskie opóźnienia)

Temat (temat) z hierarchią i dzikimi kartami ("foo. „,” foo. >`).
Tryby: pub/sub, kolejka-grupy (fan-out z dystrybucją pracy), request-answer (fast RPC).
Rdzeń NATS - efemeryczne, ultra-niskie opóźnienie; JetStream - trwałość/retencja/powtórzenia.
Zamówienie: najlepszy wysiłek, brak silnej gwarancji globalnej; z JetStream - zamawianie na strumieniu, ale rzadkie ponowne zamawianie w przypadku awarii jest możliwe.

3) Semantyka dostawy i spójność

Idempotencja i dedup są odpowiedzialne za stosowanie/siniaki, nawet gdy „dokładnie raz” w Kafce.

4) Zamówienie, podział i klucze

Kafka

Wybór klucza wiadomości określa partię → silny porządek lokalny.
Клика: 'aggregate _ id',' tenant _ id', 'order _ id'. Unikaj gorących kluczy.
Równowaga: N partie, czytanie na poziomie paralelizmu.

NATS

W Core, grupa kolejki robi równowagę.
JetStream Stream jest zrzucany przez uczestników; nacisk na szeroki wentylator/wentylator z niskim opóźnieniem.

5) Zatrzymywanie, powtarzanie i zagęszczanie

Kafka

Zatrzymanie: "zatrzymanie. ms/bytes ".
Zagęszczenie: przechowuje „ostatnią wartość według klucza” (nadaje się do migawek/buforów/sagów).
Powtórka: Każdy użytkownik może „cofnąć” offsety.

JetStream

Strumienie: backendy pliku/notatki, zasady przechowywania według czasu/bajtów/liczby wiadomości.
Konsumenci: pull/push, trwały/efemeryczny, filtr według przedrostków tematycznych.
Powtórka: redelivery lub odczyt od początku/offset-like (sekwencja).

6) Transakcje, skrzynka odbiorcza i spójność

Kafka

Idempotent Producer ('enable. idempotence = true '): ochrona przed duplikatami.
Transakcje: nagrywanie atomowe kilku partii + popełnić konsument-offsets → czytaj-process-write wzór bez „dziur”.
Transactional Outbox: zapis zdarzenia biznesowego i linii outbox w jednej transakcji bazy danych, pracownik publikuje w Kafce.

NATS

Nie ma transakcji „cross-stream” jak w Kafce; używać skrzynki odbiorczej/skrzynki odbiorczej i konsumentów idempotent (klucze, deadstore).

7) RPC i odpowiedź na żądanie

Kafka jest niewygodny dla RPC (wysokie koszty ogólne, zamówienia/odpowiedzi są trudniejsze). Użyj asynchronicznych poleceń/zdarzeń.
NATS: idealny do odpowiedzi na prośbę (milisekundy, korelacja, timeouts).

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

8) Działanie i topologie

8. 1 Kafka

Klaster: brokerzy + ZooKeeper (przed starymi wersjami) lub KRaft (nowe metadane).

Replikacja - strefa RF ≥ 3, ISR/kontrolery

Multi-region: MirrorMaker 2/Cluster Linking; aktywa-pasywa/aktywa-aktywa z polityką konfliktu.
Pojemność dysku/sieci: odczyt z 'throughput × retention × repliki'.

8. 2 NATS

Klaster: wiele węzłów, super-klaster (geo-dystrybucja), węzły liściowe dla obwodników/krawędzi.
JetStream: umieszczenie strumieni według zestawów węzłów (rozmieszczenie), replikacja (R = 1.. 5).
WAN: przewidywalnie niskie opóźnienia, łatwa federacja.

9) Bezpieczeństwo

Kafka

TLS (mTLS), SASL: SCRAM, OAuthBearer.
ACL na tematy/grupy/transakcje.
Szyfrowanie „w spoczynku” (OS/disks) + zasady sieci.

NATS

Identyfikacje nkey/JWT, rachunki operatora, ACL na temat.
mTLS między węzłami a klientami.
Izolacja najemcy (rachunki) + limity.

10) Obserwowalność i wskaźniki wydajności

Kafka

Брокей: 'BytesIn/Out', 'Н Queue', 'UnderRepl Partitions', GC/FS stats.
Temat/część: 'logEndOffset', opóźnienie konsumenckie (krytyczne).
Producent/konsument: retrai ", partia. rozmiar ',' linger. ms ',' fetch. min. bajty, błędy.
Narzędzia: JMX, Cruise Control (re-balance), Schema Registry.

NATS/JetStream

Serwer: conn/msgs/sec, RTT, CPU/mem, powolne wykrywanie konsumentów.
JetStream: per stream/consumer - lag, redeliveries, acks, storage bytes.
Monitoring: wbudowany punkt końcowy, nsc/adm-CLI, deski rozdzielcze.

11) Wydajność i dostrajanie

Kafka

Duże buty i „linger”. ms 'improve przepustowość i kompresja p99.
Kompresja (lz4/zstd) zapisuje sieć/dysk.
liczba przegród przez liczbę konsumentów/rdzeni, ale nie napowietrzne.
Napędy: NVMe preferowane, XFS/EXT4 z „noatime”.

NATS

Małe wiadomości, wiele połączeń jest normą; utrzymać grupy kolejki „szeroki”.
JetStream: tune 'max _ ack _ pending', pull vs push, rozmiar partii.
Ciśnienie wsteczne: 'Z kontrolą', 'IdleHeartbeat', granice po stronie serwera.

12) Wzorce integracji

Skrzynka odbiorcza/skrzynka odbiorcza (zarówno w Kafce, jak i NATS).
SAGA: orkiestra imprez; dziadek przez 'saga _ id + step'.
Zmiana przechwytywania danych (CDC): Debezium → Kafka; w NATS - wzór „wydawca z bazy danych wyzwalaczy/dzienników”.
Przetwarzanie strumieni: Kafka Streams/Flink/Iskra; w NATS - procesory/funkcje firm trzecich, konsumenci JetStream.
Kolejka martwych listów (DLQ) i polityki retry (wykładnicze backoff + jitter).

13) Przykłady konfiguracji

13. 1 Kafka: Wykonanie tematu i producenta

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 strumienie Kafka: obróbka idempotentna (szkic)

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

13. 3 NATS JetStream: strumień + konsument (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 żądanie-odpowiedź (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 pick: Szybki przewodnik

Potrzebujemy powtórki, długoterminowej retencji, kompresji, ciężkich procesów strumieniowych → Kafka.
Potrzebujesz szybkiego RPC, wentylatora/wentylatora z mikrolatnością, prostą obsługą, krawędź/IoT → NATS (Core).
Potrzebujemy trwałości + fan-out, ale bez ciężkiej platformy „log” → NATS JetStream.
Ścisły klucz i zlecenie transakcji → Kafka.

15) Planowanie zdolności (uproszczone)

Kafka

1. Przepustowość: 'inbound _ MBps × RF × retention_days × 86400' → dyski.
2. Partie: „target _ concurrency” × stado 1. 5-2 ×.
3. Sieć: p99 + replikacja + kompresja producenta.

NATS/JetStream

1. Wiadomości/sek i średnia → przepustowość.
2. Retencja × repliki → przechowywanie.
3. Ograniczenia konsumentów (ack-pending, redeliveries), procesor do serializacji.

16) Bezpieczna obsługa: lista kontrolna

• Włączony TLS/mTLS, sekrety obracane.
• ACL/rachunki/kwoty (na najemcę).
• Idempotencja konsumentów, DLQ i jitter wycofuje się.
• Monitorowanie lag/przepustowości/błędów; wpisy o URP (Kafka), burza redelivery (NATS).
• Deski rozdzielcze pojemności: przegrody, przechowywanie, p99.
• Testy awarii węzła/strefy, dni gry, powtórka/zasypka.
• Klucze schematu/JSON Schema są udokumentowane.
• Polityka retencji/kompresji/TTL jest dostosowana do zgodności.
• Wersje brokera/klienta są regularnie aktualizowane; zweryfikowana zgodność protokołu drutu.

17) Anty-wzory

Gorący klucz (wszystkie wydarzenia z tego samego identyfikatora) → jeden „wrzący” strumień. Shardy/bufor.
Odwrót bez idempotencji → podwójne efekty.
Ogromne wiadomości (MB-dziesiątki) → GC fragmentacja/pauzy. Zapisz ładunek w obiekcie, wyślij linki.
Mieszanie RPC i strumieniowe w Kafce → złożony cykl życia/kolejność.
JetStream jako „długoterminowy DWH” → off-label; przechowywać przez długi czas w łóżkach obiektowych/kolumnowych.
Brak DLQ → „jadowite” wiadomości kręcą się bez końca.
Zapomniane retencje → dyski są pełne, klaster zatrzymać.

18) FAQ

P: Czy mogę zrobić „dokładnie raz” na końcu rurociągu?
Odp.: W praktyce - skutecznie tak: Kafka (idempotent producent + transakcje) i idempotent sinks (klucz, upsert). W NATS - poprzez idempotencję/dedup w aplikacji.

P: Co wybrać dla miliona małych RPC/s?
Odp.: NATS Core: Mikrolatność, odpowiedź na żądanie, połączenia światła i grupy kolejek.

P: Potrzebujesz zagęszczenia i migawki fortuny?
Odp.: Sprzątanie Kafki. policy = compact ', key = aggregate/resource.

P: Jak radzić sobie z opóźnieniem?
Odp.: Zwiększyć liczbę partii/pracowników, skrócić czas przetwarzania, partię i prefetch, zoptymalizować deserializację, pionowo wzmocnić maklerów/napędów.

P: Wielobranżowe i DR?
Odp.: Kafka - MirrorMaker 2/Cluster Linking, asset-liability z RPO w sekundę. NATS - superkluster/węzły liściowe; JetStream lustrzane/repliki według strefy.

19) Kwoty całkowite

Kafka i NATS zamykają różne tryby: Kafka - trwałe dzienniki zdarzeń, wysoka przepustowość, transakcyjność i powtórka; NATS jest ultralekkim autobusem dla niskich opóźnień, RPC i prostego wentylatora, z JetStream dla trwałości. Dokonaj wyboru z semantyki dostawy, zamówienia i zatrzymywania, opóźnienia i kosztów operacyjnych. Klucze/imprezy projektowe, retencja, DLQ i obserwowalność - a Twoja architektura wydarzeń będzie przewidywalna, skalowalna i niezawodna.