Kafka-Architektur erklärt: Kernkomponenten und ihre Rollen

Apache Kafka ist eine leistungsstarke, verteilte Event-Streaming-Plattform, die für die Verarbeitung von Datenströmen mit hohem Durchsatz und Fehlertoleranz konzipiert ist. Seine Architektur ist grundlegend für das Verständnis, wie es Datensätze zuverlässig verarbeitet und speichert. Unabhängig davon, ob Sie einen grundlegenden Proof-of-Concept einrichten oder eine geschäftskritische Anwendung skalieren, ist das Verständnis der Rollen seiner Kernkomponenten – Broker, Topics, Producer, Consumer und ZooKeeper – für eine effektive Bereitstellung und Verwaltung unerlässlich.

Dieser Leitfaden analysiert systematisch die Architektur von Kafka und beschreibt, wie diese Komponenten zusammenwirken, um ein robustes, skalierbares System für Echtzeit-Datenbewegung und -speicherung zu bilden.

Die Kernkomponenten der Kafka-Architektur

Kafka arbeitet als verteiltes System, was bedeutet, dass seine Funktionalität zur Skalierbarkeit und Ausfallsicherheit auf mehrere Maschinen (Knoten) verteilt ist. Die Kernarchitektur basiert auf dem koordinierten Zusammenspiel von fünf primären Entitäten:

1. Kafka-Broker (Die Server)

Ein Kafka-Cluster besteht aus einem oder mehreren Servern, den sogenannten Brokern. Diese Broker sind für die Speicherung der Daten (Protokolle) und die Verarbeitung von Client-Anfragen (Lesen und Schreiben) verantwortlich.

• Rolle: Broker empfangen Nachrichten von Produzenten, speichern sie in Topic-Partitionen und stellen diese Nachrichten Konsumenten zur Verfügung. Sie bilden das Rückgrat des Clusters.
• Fehlertoleranz: Fällt ein Broker aus, werden seine Partitionen von Replikat-Brokern übernommen, um die Datenverfügbarkeit zu gewährleisten, sofern die Replikation korrekt konfiguriert ist.
• Skalierung: Das Hinzufügen weiterer Broker zu einem Cluster ermöglicht es dem System, horizontal zu skalieren, wodurch die Last und die Speicherkapazität verteilt werden.

2. Topics (Die Datenkategorien)

Topics sind der primäre Mechanismus zur Kategorisierung von Datenströmen in Kafka. Sie sind analog zu Tabellen in einer Datenbank oder Ordnern in einem Dateisystem.

• Definition: Ein Topic ist ein Feed-Name, in den Datensätze veröffentlicht werden. Daten innerhalb eines Topics sind immer chronologisch geordnet.
• Partitionen: Um Parallelität und Skalierbarkeit zu erreichen, wird ein Topic in Partitionen unterteilt. Jede Partition ist eine geordnete, unveränderliche Sequenz von Datensätzen.
  • Daten innerhalb einer Partition sind streng geordnet und erhalten eine inkrementelle ID, die als Offset bezeichnet wird.
  • Nachrichten werden basierend auf einem Schlüssel (sofern angegeben) oder im Round-Robin-Verfahren auf die Partitionen verteilt.
• Replikation: Für die Fehlertoleranz werden Partitionen über mehrere Broker repliziert. Der Broker, der die aktive, primäre Kopie enthält, ist der Leader, und die anderen sind Follower.

Beispiel: Topic-Konfiguration

Beim Erstellen eines Topics definieren Sie die Anzahl der Partitionen und den Replikationsfaktor. Um beispielsweise ein Topic namens user_activity mit 3 Partitionen und einem Replikationsfaktor von 3 zu erstellen:

kafka-topics.sh --create --topic user_activity --bootstrap-server localhost:9092 --partitions 3 --replication-factor 3

3. Producer (Die Datenschreiber)

Producer sind Client-Anwendungen, die Streams von Datensätzen in Kafka Topics veröffentlichen (schreiben).

• Funktionalität: Producer formatieren Datensätze in Schlüssel-Wert-Paare (mit optionalem Zeitstempel und Headern) und senden sie an den Kafka-Cluster.
• Partitionszuweisung: Ein Producer bestimmt, in welche Partition eine Nachricht gelangt. Wenn eine Nachricht einen Schlüssel hat, verwendet Kafka einen Hash-Mechanismus auf dem Schlüssel, um sie konsistent derselben Partition zuzuordnen. Wenn kein Schlüssel angegeben ist, werden die Nachrichten im Round-Robin-Verfahren verteilt.
• Bestätigungen (Acks): Producer konfigurieren das erforderliche Maß an Dauerhaftigkeit mithilfe der Einstellung acks, die festlegt, wie viele Broker den Empfang bestätigen müssen, bevor der Schreibvorgang als erfolgreich gilt (z. B. gewährleistet acks=all maximale Dauerhaftigkeit).

4. Consumer (Die Datenleser)

Consumer sind Client-Anwendungen, die ein oder mehrere Topics abonnieren und die darin veröffentlichten Datenströme verarbeiten.

• Verbrauchsmechanismus: Consumer lesen Daten sequenziell basierend auf dem Offset innerhalb einer Partition. Sie sind dafür verantwortlich, zu verfolgen, welchen Offset sie erfolgreich verarbeitet haben.
• Consumer Groups: Consumer arbeiten typischerweise innerhalb einer Consumer Group. Kafka stellt sicher, dass jede Partition nur von einer Consumer-Instanz innerhalb einer bestimmten Consumer Group verbraucht wird. Dies ermöglicht die horizontale Skalierung von Lesevorgängen durch Hinzufügen weiterer Instanzen bis zur Anzahl der Partitionen.

Beispiel: Consumer-Offsets

Wenn ein Consumer Nachrichten verarbeitet, committet er periodisch seinen zuletzt verarbeiteten Offset zurück an Kafka (normalerweise in einem internen Topic gespeichert, __consumer_offsets). Wenn der Consumer abstürzt, setzt er beim Neustart innerhalb derselben Gruppe die Lesevorgänge ab dem zuletzt committeten Offset fort, wodurch Datenverlust oder doppelte Verarbeitung verhindert wird (abhängig von der Commit-Strategie).

5. Apache ZooKeeper (Koordinationsdienst)

Historisch gesehen war Apache ZooKeeper für die Verwaltung der Metadaten und des Zustands des Kafka-Clusters unerlässlich. Obwohl Kafka auf eine selbstverwaltete Metadaten-Architektur umgestellt wird (Kafka Raft Metadata Mode oder KRaft), bleibt ZooKeeper in vielen bestehenden, weit verbreiteten Clustern eine kritische Komponente.

• Metadatenspeicherung: ZooKeeper speichert die Cluster-Konfiguration, einschließlich der Liste der aktiven Broker, der Zuordnung von Partitionen zu Brokern und Konfigurationsdetails für Topics.
• Controller-Wahl: ZooKeeper verwaltet die Wahl des Kafka Controllers. Der Controller ist ein Broker, der gewählt wird, um Änderungen der Partitionsführerschaft, die Replikatsynchronisation und Änderungen des allgemeinen Cluster-Zustands zu verwalten.

Datenfluss und Abhängigkeiten

Die Architektur funktioniert, indem klare Verantwortlichkeitsflüsse etabliert werden:

1. Producer-Initialisierung: Ein Producer stellt eine Verbindung zu einem beliebigen Broker im Cluster her (der als Gateway fungiert) und fragt nach Metadaten zum Ziel-Topic.
2. Leader-Umleitung: Der Broker leitet den Producer zur aktuellen Leader-Replikation für die Zielpartition weiter.
3. Datenschreiben: Der Producer sendet den Datensatz an den Leader-Broker.
4. Replikation: Der Leader-Broker schreibt den Datensatz in sein lokales Protokoll, weist ihm einen Offset zu und repliziert dann den Datensatz an alle vorgesehenen Follower-Replikate.
5. Bestätigung: Sobald die konfigurierte Anzahl von Replikaten (acks-Level) den Empfang bestätigt hat, bestätigt der Leader den Erfolg an den Producer zurück.
6. Verbrauch: Consumer fragen den Leader-Broker der Partition ab, an der sie interessiert sind, und fordern Datensätze ab einem angegebenen Offset an.

Wichtige Überlegung: Datenaufbewahrung

Im Gegensatz zu herkömmlichen Warteschlangen ist Kafka im Grunde ein verteiltes Commit-Protokoll. Daten werden für einen konfigurierten Zeitraum (Standard ist oft 7 Tage) oder bis eine Größenbeschränkung erreicht ist, auf den Broker-Festplatten aufbewahrt, unabhängig davon, ob Consumer sie gelesen haben. Diese Persistenz ermöglicht es neuen oder verzögerten Consumern, historische Daten zu lesen.

Best Practice: Konfigurieren Sie log.retention.hours oder log.retention.bytes für Ihre Topics sorgfältig, um den Speicherplatz basierend auf den Wiederherstellungsanforderungen Ihrer Anwendung effektiv zu verwalten.

Skalierung und Ausfallsicherheit

Die Architektur von Kafka ist inhärent auf horizontale Skalierung und Ausfallsicherheit ausgelegt:

• Skalierung von Schreib-/Lesevorgängen: Wird durch Hinzufügen weiterer Broker und Erhöhen der Anzahl von Partitionen für hochfrequentierte Topics erreicht.
• Fehlertoleranz: Wird durch Replikation erreicht. Fällt der Leader-Broker einer Partition aus, erkennt ZooKeeper (oder der KRaft-Mechanismus) den Ausfall, und die verbleibenden Follower koordinieren sich, um einen neuen Leader zu wählen, wodurch die kontinuierliche Verfügbarkeit bei minimaler Ausfallzeit für Producer und Consumer gewährleistet wird.

Durch die Beherrschung dieser Kernkomponenten der Architektur – wie Broker Partitionen speichern, wie Producer Nachrichten über Schlüssel weiterleiten und wie Consumer Groups Offsets verwalten – erhalten Sie die notwendige Grundlage, um Kafka für hochperformantes Event-Streaming bereitzustellen und zu optimieren.