Message Broker

1) Warum Message Broker

• Pufferung und Glättung von Spitzen, Backpresher.
• Skalieren Sie Lesen/Schreiben unabhängig.
• Beobachtung und Wiedergabe (Replay) von Ereignissen.
• Architekturmuster: event-driven, CQRS, event sourcing, outbox/inbox.

2) Grundlegende Modelle und Begriffe

2. 1 Kafka (Logmodell)

Topik → Parteien (geordnete Protokolle) → Versätze bei den Consumern.
Verbrauchergruppe: Parallelität des Lesens, Balancieren der Parteien.
Retention nach Zeit/Volumen; Compact nach Schlüssel.
Semantik: Minimum - at-least-once, bei Einstellungen - effectively exactly-once (idempotente Produzenten + Transaktionen).
Ordnung: innerhalb der Partei garantiert.

2. 2 NATS (Themen/Themen, geringe Latenz)

Subject (Thema) mit Hierarchie und Wildcards ('foo.', 'foo. >`).
Modi: pub/sub, queue-groups (Fan-out mit Job-Verteilung), request-reply (schneller RPC).
Core NATS - ephemere, ultraniedrige Latenz; JetStream - Persistenz/Retention/Wiederholungen.
Auftrag: beste Anstrengung, ohne starke globale Garantie; mit JetStream - Ordnung im Stream, aber seltene Nachbestellungen bei Ausfällen sind möglich.

3) Liefersemantik und Konsistenz

Idempotenz und Dedup liegen in der Verantwortung der App/Sync, auch bei „exactly-once“ bei Kafka.

4) Reihenfolge, Partitionierung und Schlüssel

Kafka

Die Wahl des Nachrichtenschlüssels bestimmt die Partei → eine starke lokale Ordnung.
Ключи: `aggregate_id`, `tenant_id`, `order_id`. Vermeiden Sie heiße Schlüssel.
Balance: N-Parteien ≈ das Niveau der Parallelität des Lesens.

NATS

Bei Core macht die Queue-Gruppe die Balance.
In JetStream wird Stream durch subjects sharding; Betonung auf breites Fan-Out/Fan-In mit geringer Latenz.

5) Retention, Replies und Compaction

Kafka

Retention: `retention. ms/bytes`.
Compaction: speichert den „letzten Wert nach Schlüssel“ (geeignet für Snap Shots/Cashes/Sagen).
Wiederholung: Jeder Consumer kann Offsets „abspulen“.

JetStream

Streams: Datei/Memory Backends, Aufbewahrungsrichtlinien nach Zeit/Bytes/Anzahl der Nachrichten.
Verbraucher: pull/push, durable/ephemeral, Filter nach Subject-Präfixen.
Replay: Umleitung oder Lesen von Anfang an/offset-like (Sequenz).

6) Transaktionen, Outbox und Konsistenz

Kafka

Idempotent Producer (`enable. idempotence = true'): Schutz vor Doppelungen.
Transaktionen: atomare Aufzeichnung mehrerer Parteien + Commit-Consumer-Offsets → Read-Process-Write-Muster ohne „Löcher“.
Transactional Outbox: Aufzeichnung eines Geschäftsereignisses und einer Outbox-Zeile in einer einzigen DB-Transaktion, die der Worker in Kafka veröffentlicht.

NATS

Es gibt keine „Interstream“ -Transaktionen wie in Kafka; Verwenden Sie Outbox/Inbox und idempotente Consumer (Schlüssel, Dedup-Stor).

7) RPC und Anfrage-Antwort

Kafka für RPC ist unbequem (hoher Overhead, Reihenfolge/Antworten sind schwieriger). Verwenden Sie asynchrone Befehle/Ereignisse.
NATS: ideal für request-reply (Millisekunden, Corellation, Timeouts).

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

8) Betrieb und Topologien

8. 1 Kafka

Cluster: Broker + ZooKeeper (vor älteren Versionen) oder KRaft (neue Metadaten).
Replikation: Zonen- RF≥3, ISR/Controller.
Mehrere Regionen: MirrorMaker 2/Cluster Linking Asset-Passiv/Asset-Asset mit Konfliktpolitiken.
Festplatten-/Netzwerkkapazität: Zähle von „throughput × retention × replicas“.

8. 2 NATS

Cluster: viele Knoten, Super-Cluster (Geo-Distribution), Leafnodes für Peripherie/Edge.
JetStream: Platzierung von Streams nach Knotensätzen (Platzierung), Replikation (R = 1.. 5).
WAN: vorhersehbar niedrige Latenz, leichte Föderation.

9) Sicherheit

Kafka

TLS (mTLS), SASL: SCRAM, OAuthBearer.
ACL auf Topics/Gruppen/Transaktionen.
Ruheverschlüsselung (OS/Laufwerke) + Netzwerkrichtlinien.

NATS

nkey/JWT Identität, Operator-Konten, Per-Subject ACL.
mTLS zwischen Knoten und Clients.
Isolierung von Mietern (Konten) + Grenzen.

10) Beobachtbarkeit und Leistungsmetriken

Kafka

Брокер: `BytesIn/Out`, `RequestQueue`, `UnderReplicatedPartitions`, GC/FS stats.
Topic/Party: 'logEndOffset', Verbraucherverzug (kritisch).
Produzent/Consumer: retrai, 'batch. size`, `linger. ms`, `fetch. min. bytes', Fehler.
Werkzeuge: JMX, Cruise Control (Re-Balance), Schema Registry.

NATS/JetStream

Server: conn/msgs/sec, RTT, CPU/mem, slow consumer detection.
JetStream: per stream/consumer — lag, redeliveries, acks, storage bytes.
Überwachung: integrierter Endpunkt, nsc/adm-CLI, Dashboards.

11) Leistung und Tuning

Kafka

Große Batchi und 'Linger. ms' verbessern throughput und komprimieren p99.
Kompression (lz4/zstd) spart Netzwerk/Festplatte.
num. Partitionen nach Anzahl der Verbraucher/Kerne, aber nicht zu weit (overhead).
Laufwerke: NVMe werden bevorzugt, XFS/EXT4 mit 'noatime'.

NATS

Kleine Nachrichten, viele Verbindungen - die Norm; halten queue Gruppen „breit“.
JetStream: tune `max_ack_pending`, pull vs push, size of batches.
Backpressure: `FlowControl`, `IdleHeartbeat`, server-side limits.

12) Integrationsmuster

Outbox/Inbox (sowohl in Kafka als auch in NATS).
SAGA: Orchestrierung durch Veranstaltungen; dedup durch 'saga _ id + step'.
Change Data Capture (CDC): Debezium → Kafka; in NATS ein "publisher from DB triggers/logs' -Muster.
Stream processing: Kafka Streams/Flink/Spark; in NATS - Prozessoren/Funktionen von Drittanbietern, JetStream-Verbraucher.
Dead Letter Queue (DLQ) und Retry-Richtlinien (exponentieller Backoff + Jitter).

13) Beispiele für Konfigurationen

13. 1 Kafka: Topic-Kreation und Produzent

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: idempotente Bearbeitung (Skizze)

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 Auswahl: eine schnelle Referenz

Wir brauchen Replikate, lange Retention, Kompression, schwere Stream-Prozesse → Kafka.
Sie benötigen einen schnellen RPC, ein Fan-Out/Fan-In mit Mikrolatenz, einfache Bedienung, Edge/IoT → NATS (Core).
Wir brauchen Persistenz + Fan-out, aber ohne die schwere „Log“ -Plattform → NATS JetStream.
Strikte Reihenfolge nach Schlüssel und Transaktion → Kafka.

15) Kapazitätsplanung (vereinfacht)

Kafka

1. Durchlass-: ' inbound_MBps × RF × retention_days × 86400 ' → die Disks.
2. Parteien: „target _ concurrency“ × Lager 1. 5–2×.
3. Netzwerk: p99 + replication + producer compression.

NATS/JetStream

1. Nachrichten/sec und Durchschnittliche Größe → throughput.
2. Retention×replicas → storage.
3. Grenzen der Verbraucher (ack-pending, redeliveries), CPU auf Serialisierung.

16) Sicherer Betrieb: Checkliste

• TLS/mTLS eingeschaltet, Geheimnisse rotieren.
• ACL/Konten/Quoten (per-tenant).
• Idempotenz bei Consumern, DLQ und Retrays mit Jitter.
• Monitoring lag/throughput/error; alert auf URP (Kafka), einem Redelivery-Storm (NATS).
• Kapazität Dashboards: Parteien, Lagerung, p99.
• Knoten-/Zonenfehlertests, Spieltage, Replikate/Backfill.
• Partitionierungsschlüssel und Schemata sind dokumentiert (Schema Registry/JSON Schema).
• Die Richtlinien für Retention/Compaction/TTL sind mit der Compliance abgestimmt.
• Die Versionen der Broker/Kunden werden regelmäßig aktualisiert; Die Kompatibilität des Wire-Protokolls wurde geprüft.

17) Anti-Muster

Hot Key (alle Ereignisse einer ID) → ein „kochender“ Thread. Scharren/puffern.
Retrays ohne Idempotenz → Doppeleffekte.
Riesige Nachrichten (MB-Zehner) → GC-Fragmentierung/Pausen. Speichern Sie payload im Objekt, senden Sie Links.
Das Mischen von RPC und Streaming in Kafka → einen komplexen Lebenszyklus/Auftrag.
JetStream als „langfristige DWH“ → nicht bestimmungsgemäß; lange in Objekt-/Säulensektoren lagern.
Es gibt kein DLQ → „giftige“ Nachrichten drehen sich endlos.
Vergessene Retention → Scheiben voll, Cluster-Stopp.

18) FAQ

F: Kann man „exactly-once“ am Ende einer Pipeline machen?
A: In der Praxis - effektiv ja: Kafka (idempotent producer + transactions) und idempotent syncs (key, upsert). In NATS - durch idempotency/dedup in der Anwendung.

F: Was soll ich für eine Million kleine RPC/s wählen?
A: NATS Core: Mikrolatenz, Anfrage-Antwort, einfache Anschlüsse und Queue-Gruppen.

F: Brauchen Sie Kompression und Schnappschüsse des Staates?
A: Kafka с `cleanup. policy = compact', key = Aggregat/Ressource.

F: Wie gehe ich mit der Verzögerung um?
A: Erhöhen Sie die Anzahl der Parteien/Worker, reduzieren Sie die Bearbeitungszeit, Batchi und Prefetch, optimieren Sie die Deserialisierung, verstärken Sie Makler/Laufwerke vertikal.

F: Multiregion und DR?
A: Kafka - MirrorMaker 2/Cluster Linking, Asset-Liability mit RPO≈sekundy. NATS — supercluster/leafnodes; JetStream Spiegelung/Replikation nach Zonen.

19) Ergebnisse

Kafka und NATS schließen verschiedene Modi: Kafka - langlebige Ereignisprotokolle, hohe Durchdringung, Transaktionalität und Replikationen; NATS ist ein ultraleichter Bus für niedrige Latenz, RPC und einfaches Fan-Out, mit JetStream für Persistenz. Wählen Sie aus der Semantik der Lieferung, Reihenfolge und Retention, Latenz und Betriebskosten. Entwerfen Sie Schlüssel/Parties, Retention, DLQ und Observability - und Ihre Event-Architektur ist vorhersehbar, skalierbar und zuverlässig.