Hauptkomponenten von Apache Kafka
- Broker - ist ein Knoten, der für die Speicherung und Verarbeitung von Nachrichten verantwortlich ist. Er empfängt Nachrichten von Producern, speichert sie und überträgt sie an Consumer
- Zookeeper - wird zur Verwaltung und Koordination von Broker-Knoten im Kafka-Cluster verwendet. Er ist verantwortlich für die Verfolgung des Broker-Status, die Verwaltung von Zugriffsberechtigungen und die Koordination von Partition-Leadern
- Ab Kafka 2.8.0 erschien der KIP-500-Modus - ein Betriebsmodus ohne Zookeeper, und ab Kafka 3.3+ wurde dieser Modus stabil und empfohlen. In neuen Installationen verwenden sie Kafka KRaft (Kafka Raft Metadata Mode) anstelle von Zookeeper
- Producer - eine Anwendung oder ein Prozess, der Nachrichten generiert und an Kafka sendet.
- Consumer - eine Anwendung oder ein Prozess, der Nachrichten von Kafka empfängt und verarbeitet.
- Topic - ein Thema oder eine Kategorie, in der Nachrichten gespeichert werden. Producer sendet Nachrichten an ein bestimmtes Topic, und Consumer liest Nachrichten aus diesem Topic.
- Partition - Ein Topic kann aus mehreren Partitionen bestehen. Jede Partition ist ein geordnetes unveränderliches Log von Nachrichten. Partitionen ermöglichen es Kafka, Schreib- und Lesevorgänge horizontal zu skalieren.
- Consumer Group - ist eine Gruppe von Consumern, die zusammen ein Topic lesen
Kafka vs Rabbit
Sie haben unterschiedliche Nachrichtenzustellungsmodelle. Kafka holt selbst die benötigte Nachricht aus dem Topic - Pull.
Rabbit – implementiert ein Push-Modell, d.h. der Server pusht die Nachricht selbst.
Kafka fügt Nachrichten zum Log hinzu, und Consumer lesen es selbst, während
Rabbit die Nachricht nach ihrer Verarbeitung löscht, und Kafka sie weiter speichert, bis die geplante Löschung eintritt.
Arten von Nachrichtenzustellungsgarantien
| Semantik | Was garantiert wird | Besonderheiten |
| At-most-once | 0 oder 1 Mal | Nachricht kann verloren gehen, aber keine Duplikate. |
| At-least-once | ≥1 Mal | Nachricht ist garantiert zugestellt, aber es kann Duplikate geben. |
| Exactly-once | genau 1 Mal | Kafka selbst implementiert kein vollständiges Exactly-Once: um dies zu erreichen, ist ein zusätzlicher Mechanismus erforderlich. Zum Beispiel: Outbox Pattern + Tabelle auf der Consumer-/Service-Seite, um bereits verarbeitete Nachrichten-IDs zu filtern. |
Idempotenz in Kafka
Idempotenz in Apache Kafka ist eine Funktionalität, die garantiert, dass Nachrichten nicht mehr als einmal verarbeitet werden. Dies ist wichtig, um eine sichere und zuverlässige Datenübertragung zwischen Producern und Consumern im Kafka-System zu gewährleisten.
Consumer Group Leader
In Apache Kafka ist der Consumer-Leader eine Consumer-Instanz, die für das Lesen von Daten aus dem Topic und die Koordination der Nachrichtenverarbeitung durch andere Consumer verantwortlich ist. Der Consumer-Leader verfolgt den Lesefortschritt und verbreitet Informationen über Offsets zwischen Consumern in der Gruppe.
Wie wird der Leader gewählt?
- Wenn sich ein Consumer mit der Gruppe verbindet, benachrichtigt der Kafka Coordinator (ein spezieller Broker für die Gruppe) alle Consumer über die Gruppenzusammensetzung.
- Einer der Consumer wird automatisch zum Leader gewählt (normalerweise nach Auswahlalgorithmus - der zuerst verbundene oder per Konsens in der Gruppe).
- Der Leader erhält aktuelle Informationen über Partitionen der Topics, die die Gruppe abonniert hat.
- Der Leader erstellt ein Assignment - Verteilung von Partitionen zwischen Consumern.
Was macht der Leader beim Rebalancing?
- Erhält vom Kafka Coordinator ein Rebalancing-Ereignis (neuer Consumer tritt der Gruppe bei, Consumer verlässt/fällt aus, Topics ändern sich, die die Gruppe abonniert hat).
- Berechnet neue Partitionsverteilung zwischen Consumern (Assignment).
- Sendet jedem Consumer seine Liste von Partitionen.
- Alle Consumer wenden das neue Assignment an, lesen weiter vom gespeicherten Offset.
Welche Optionen gibt es für Offset-Verschiebung
- Nachricht wird beim Senden und Empfangen automatisch verschoben
- Verschiebung erfolgt nach Verarbeitung durch Consumer-Leader
- Verschiebung erfolgt nach Verarbeitung durch alle Consumer. Erfordert Koordination (Quorum) zwischen Consumern
commitSync() und commitAsync()
commitSync()
- Synchroner Commit. Consumer wartet auf Antwort vom Broker, bis Offset bestätigt wurde.
- Wird verwendet, wenn garantierte Offset-Fixierung vor Fortsetzung der Verarbeitung erforderlich ist.
- Normalerweise macht man dies nach Nachrichtenverarbeitung/Batch, um keine Daten zu verlieren.
commitAsync()
- Asynchroner Commit. Consumer sendet Offset an Broker, wartet aber nicht auf Bestätigung.
- Normalerweise macht man dies nach erfolgreicher Verarbeitung, aber es kann auch nach dem Lesen erfolgen - das Risiko, die letzte Nachricht zu verlieren, ist minimal.
Was passiert, wenn es mehr/weniger Partitionen als Consumer gibt?
- Mehr Partitionen als Consumer = einige Consumer lesen mehrere Partitionen.
- Weniger Partitionen als Consumer = überschüssige Consumer sind untätig, da eine Partition nur einem Consumer in der Gruppe gehören kann.
- Jede Partition muss genau einem Consumer in der Gruppe zugewiesen werden.
Wie wird Fehlertoleranz in Apache Kafka gewährleistet
- Partitionsreplikation - Jede Partition hat einen Leader und N Replikate, die Daten kopieren
- Lesen und Schreiben über Replikate - Schreiben geht an den Leader, wird dann auf die anderen repliziert. Lesen kann vom Leader oder von Replikaten bedient werden (abhängig von den Einstellungen).
- Quorum (ack) - Schreiboperation gilt als erfolgreich erst nach Bestätigung von der erforderlichen Anzahl von Replikaten (
acks=all). Garantiert Datenkonsistenz. - Broker-Spiegelung (MirrorMaker) - Ermöglicht Backup-Cluster und schnelle Wiederherstellung nach Ausfall.
- Überwachung und Auto-Wiederherstellung - Quorum-Controller überwacht den Broker-Status, wählt automatisch neuen Leader bei Ausfall.
Schema Registry + Avro/Protobuf in Kafka
- Schema Registry - Service, der Nachrichtenschemas speichert und ihre Versionierung verwaltet.
- Avro/Protobuf - Serialisierungsformate, die Schemas für die Nachrichtenstruktur verwenden.
Klassische Probleme
Kafka hat klassische Probleme, mit denen fast jeder Entwickler konfrontiert war:
| Problem | Was passiert | Ursachen / Warum | Kurze Lösung |
|---|---|---|---|
| Message duplication | Nachrichten können mehrmals ankommen | At-least-once, Consumer-Ausfall | Idempotent Producer, Transaktionen, Filterung nach ID |
| Consumer lag | Consumer bleibt zurück, Backlog wächst | Langsame Verarbeitung, zu wenig Partitionen | Partitionen hinzufügen, mehr Consumer, Verarbeitungsoptimierung |
| Stuck partitions | Consumer hängt bei Partition | Blockierende Verarbeitung, langer Commit | Asynchrone Verarbeitung, Session-Timeouts, separate Threads für schwere Aufgaben |
| Hot partitions (skew) | Last ist ungleichmäßig verteilt | Unausgewogene Nachrichtenschlüssel | Gleichmäßige Schlüssel verwenden, mehr Partitionen, Custom Partitioner |
| Rebalancing storm | Häufige Gruppenrebalances | Häufiges An-/Abmelden von Consumern, kurzes session.timeout.ms | session.timeout.ms erhöhen, stabile Consumer-Instanzen |
Kafka Streams
Wird sehr selten gefragt, aber Bescheid zu wissen schadet nicht)
Kafka Streams ermöglicht die Arbeit mit Datenströmen aus Kafka-Topics in Echtzeit, Anwendung von Funktionen wie map, filter, reduce und Datenaggregierung ohne separaten Cluster. Perfekt geeignet für große Event-Ströme, wo Transformationen und Aggregationen “on the fly” erforderlich sind.
Fazit
Heute haben wir Schlüsselaspekte und Probleme bei der Arbeit mit Kafka behandelt. All dies wird häufig in Interviews gefragt. Die Themenliste basiert auf meiner Erfahrung und der Erfahrung von Kollegen, die Interviews für Positionen von Junior bis Senior durchlaufen haben.