Apache Kafka

Stell dir das Nervensystem einer Firma vor. Früher wurden Daten per Batch kopiert (nachts um 3 Uhr). "Wie viele Klicks hatten wir gestern?" Heute will man es jetzt wissen. Kafka ist ein Hochgeschwindigkeits-Rohr für Ereignisse (Events). User klickt -> Event in Kafka -> Analyse-Tool liest es (Millisekunden später). Es ist extrem robust. Du kannst Millionen Events pro Sekunde reinfeuern, Kafka speichert sie sicher ("Log") und lässt hunderte Verbraucher gleichzeitig lesen.

Merksatz: Eine verteilte Event-Streaming-Plattform, die verwendet wird, um Datenströme in Echtzeit mit extrem hohem Durchsatz zu speichern, zu verarbeiten und zu verteilen.

Praxis-Nachtrag: Nutze Apache Kafka in einem Mini-Szenario. Eine kleine App soll einen Nutzer anmelden, eine Liste laden oder eine Bestellung speichern. Frage: An welcher Stelle taucht Apache Kafka auf, was würde ohne diesen Baustein fehlen, und welchen Fehler würdest du als Anfänger wahrscheinlich sehen? Diese Denkweise macht den Begriff sofort greifbarer als eine reine Definition.

Das Prinzip: Pub/Sub (Publisher / Subscriber).

Producer: Der Webserver sendet "Klick".
Topic: Der Kanal ("Klicks-Topic").
Consumer: Das Data Warehouse liest. Der Fraud-Detector liest auch. Das Marketing-Dashboard liest auch. Alle lesen vom gleichen Log, aber jeder in seinem Tempo.

Technik-Nachtrag: Prüfe bei Apache Kafka immer Eingabe, Verarbeitung, Ausgabe und Fehlerfall. Welche Daten kommen hinein? Welche Regel wird angewendet? Welche Antwort entsteht? Was passiert bei ungültigen Daten, Zeitüberschreitung, fehlender Berechtigung oder Netzwerkausfall? Diese vier Fragen verbinden den Begriff mit echter Backend-Arbeit und zeigen, warum er im Lehrpfad nicht isoliert gelernt werden sollte.

1. Partitioning

Ein Topic (Log) kann zu groß für einen Server werden. Man teilt es in Partitionen. Partition 1 auf Server A, Partition 2 auf Server B. Das erlaubt paralleles Lesen und Schreiben (Massive Scalability). Wichtig: Die Reihenfolge der Nachrichten ist nur innerhalb einer Partition garantiert.

2. Log Compaction

Kafka löscht alte Daten normalerweise nach 7 Tagen. Mit Compaction behält es immer den letzten Zustand pro Key. Perfekt, um Datenbank-Tabellen zu spiegeln (Change Data Capture).

1. Zero-Copy (sendfile syscall) und OS Page Cache

Kafka läuft auf der JVM. Müsste es Gigabytes von RAM konsumieren, würde die Garbage Collection (OOM Kills) das Tool zerstören. Das Genie von Kafka ist der radikale Bypass der Applikationsschicht via Linux sendfile() Systemcall (Zero Copy). Eine Nachricht poppt im Linux Socket Buffer (NIC) auf und das OS flucht sie stumpf in den Kernel-Mode OS Page-Cache, ohne dass der Java-Heap-Space sie jemals überhaupt anfässt (Garbage Collector ignoriert alles). Liest ein Consumer (Consumer Pull Request), kommandiert Kafka das Betriebssystem, den File-Deskriptor von der SSD Plakette quer-horizontal sofort wieder in den Netzwerk-Socket Buffer als DMA-Stream rauszuspülen. Die JVM fungiert in Kafka nur als schlanker Traffic-Cop (Verwaltung/Clusterlogik), aber fasst Byte-Streams als User-Space Context nie aktiv an. Das treibt den Durchsatz ans absolute I/O Blech-Limit der Cloud Disks (NIC Saturation, 100 GBit/s).

2. Raft Konsens (KRaft) und das Zookeeper-Ende

Jahrelang galt Kafka als Pain, da Administratoren nebenbei zwingend 3 Nodes "Apache Zookeeper" aufbauen mussten. Zookeeper hielt alle Meta-Secrets ("Wer ist Topic Leader für Partition 1?"). Architekturbruch KIP-500 beseitigt diese Legacy. Das sogenannte KRaft System implementiert das Raft Consensus Protocol nun nativ und direkt im Core. Das Kafka-Broker Meta Quorum teilt Controller-Verantwortung autark unter sich. Als Resultat erholen sich Cluster aus harten Reboots nun 10-Mal schneller unter extremen Partitions-Loads (Millionen Partitionsgrenzen), da der TCP-Rundgang durch das schwache Zookeeper-Zentrum entfällt und Split-Brain Bugs massiv der Vergangenheit angehören.

3. Log Structured Segment Files & O(1) Reads

Trotz gigantischer Menge verhält sich Kafka niemals wie eine SQL-DB mit B-Tree-Indizes (welche langsam $\mathcal{O}(\log N)$ updaten). Kafka modelliert Disks exklusiv im "Append-Only" File System Record (Log-Structured Immutable Files). Jeder geschriebener Broker-Index mutiert in rollierende segment-10023.log Dump-Dateien, getrieben mit O(1) Schreib-Time (der Nadelkopf der HDD rödelt nicht rum). Für Consumer-Queries operiert man ausschließlich mit einem plumpen binären Integer Offset Index (Binary Search per Sparse Mapped Index). Selbst wenn du 5 Terabytes als Backpressure in Topic 4 hast, feuert Kafka die Next-Message bei $\mathcal{O}(1)$ ohne jeden Performance Einbruch wie einen Pfeil raus.