Kafka-Architekturdiagramm: Broker, Partitionen, Replikas und Consumer Groups

Kafka lässt sich leicht als ein Kasten mit der Aufschrift „Kafka“ zeichnen, mit Pfeilen hinein und heraus, und dieser Kasten verbirgt jede Eigenschaft, auf die sich Leute verlassen: was geordnet ist und was nicht, wie viele Kopien der Daten existieren, was passiert, wenn ein Broker ausfällt, und wie mehrere Services denselben Stream lesen können, ohne sich gegenseitig in die Quere zu kommen.

Dieser Artikel zeichnet einen Kafka-Cluster mit den Teilen, die zählen: Broker, Topics und Partitionen, Leader- und Follower-Replikas, Producer mit Keys, Consumer Groups und Offsets sowie die KRaft-Controller, die den Cluster verwalten.

Topics, Partitionen und Broker

Ein Topic ist ein benannter Strom von Records, etwa orders. Jedes Topic ist in Partitionen aufgeteilt, und jede Partition ist ein Append-only-Log, in dem jeder Record einen steigenden Offset bekommt.

Partitionen sind die Einheit für alles:

• Reihenfolge: Records sind innerhalb einer Partition geordnet, nie über Partitionen hinweg.
• Parallelität: Ein Topic kann von höchstens so vielen Consumern einer Gruppe gelesen werden, wie es Partitionen hat.
• Platzierung: Partitionen sind über die Broker verteilt, die Server des Clusters.

Wähle die Partitionszahl nach dem Durchsatz, den du pro Topic brauchst, und der Zahl der Consumer, die du parallel betreiben willst, mit Reserve. Partitionen lassen sich später hinzufügen, aber das ändert, auf welche Partition ein Key abgebildet wird.

Replikation

Jede Partition hat einen Replikationsfaktor, meist 3. Eine Replika ist der Leader und bedient Lese- und Schreibzugriffe; die anderen sind Follower, die das Log des Leaders kopieren. Follower, die auf dem aktuellen Stand sind, bilden das In-Sync-Replica-Set (ISR). Fällt der Broker eines Leaders aus, wird ein aktueller Follower zum neuen Leader.

Die Einstellungen, die über die Haltbarkeit entscheiden:

Mit Faktor 3, min.insync.replicas=2 und acks=all liegt ein bestätigter Write auf mindestens zwei Brokern, und der Cluster nimmt auch mit einem ausgefallenen Broker weiter Writes an. Die Kafka-Dokumentation behandelt diese Einstellungen und ihr Zusammenspiel.

Producer und Keys

Producer wählen für jeden Record eine Partition. Mit Key hasht der Standard-Partitioner den Key, sodass alle Records mit demselben Key in derselben Partition landen und geordnet bleiben. Ohne Key werden Records zur Lastverteilung gestreut und verlieren jede Reihenfolge untereinander.

Wähle Keys nach der Entität, deren Events geordnet bleiben müssen: eine Bestell-ID, eine Konto-ID. Schreib den Key im Diagramm an den Producer; er ist die folgenreichste Einstellung, die ein Producer hat. Vermeide Keys mit wenigen riesigen Werten, denn ein Hot Key überlastet eine Partition, egal wie viele du hast.

Retries können Records duplizieren. Aktuelle Kafka-Versionen aktivieren standardmäßig idempotente Producer, was Duplikate durch Producer-Retries innerhalb einer Partition entfernt; Duplikate durch Retries deiner eigenen Anwendung sind weiterhin möglich, also sollten auch Consumer idempotent sein.

Consumer Groups und Offsets

Eine Consumer Group ist eine Menge von Consumern, die sich die Arbeit für einen Zweck teilen. Kafka weist jede Partition genau einem Consumer der Gruppe zu, also können drei Partitionen höchstens drei Consumer beschäftigen; ein vierter säße untätig herum. Wenn Consumer beitreten oder gehen, wird die Gruppe neu ausbalanciert, und Partitionen wandern.

Jede Gruppe verfolgt ihre eigene Position, den committeten Offset pro Partition, den Kafka in einem internen Topic speichert. So lesen mehrere Services denselben Stream unabhängig: Fulfillment und Analytics haben jeweils ihre eigene Gruppe und ihre eigenen Offsets, und keiner beeinflusst den anderen.

Committe Offsets nach der Verarbeitung, nicht davor, dann bekommst du At-least-once-Verarbeitung: Nach einem Absturz verarbeitet der Consumer die Records seit dem letzten Commit erneut. Mach die Verarbeitung idempotent, damit die Wiederholungen harmlos sind.

Retention und Compaction

Kafka behält Records, nachdem sie gelesen wurden. Zeit- oder größenbasierte Retention löscht alte Segmente, etwa nach 7 Tagen. Log Compaction behält stattdessen für immer den neuesten Record pro Key, was ein Topic in ein Changelog des aktuellen Zustands verwandelt. Entscheide pro Topic: Events nutzen meist Retention, Zustand wie „neueste Adresse pro Kunde“ nutzt Compaction.

Ein durchgerechnetes Sizing-Beispiel

Angenommen, der Checkout erzeugt in der Spitze 3.000 Bestell-Events pro Sekunde, je etwa 1 KB, also 3 MB/s. Ein Consumer im Fulfillment-Service schafft 400 Events pro Sekunde. In der Spitze brauchst du mindestens 8 parallele Consumer, also mindestens 8 Partitionen; nimm 12, um Raum für Wachstum und für die Partitionen eines ausgefallenen Consumers zu lassen. Mit Replikationsfaktor 3 schreibt der Cluster 9 MB/s auf die Platten der Broker, und 7 Tage Retention bei dieser Rate würden bis zu etwa 5,4 TB replizierte Daten speichern. Der durchschnittliche Traffic liegt unter der Spitze, also betrachte das als Obergrenze für die Plattenplanung. Solche Zahlen gehören neben das Diagramm, denn sie bestimmen die Zahl der Broker und die Platten, nicht der Kasten mit der Aufschrift Kafka.

KRaft: kein ZooKeeper mehr

Ältere Cluster speicherten ihre Metadaten in ZooKeeper. Kafka verwaltet Metadaten jetzt selbst mit einem Raft-basierten Quorum von Controllern, genannt KRaft. Kafka 4.0, erschienen im März 2025, ist das erste Major-Release, das vollständig ohne ZooKeeper läuft. Zeichne im Diagramm das Controller-Quorum getrennt von den Brokern, auch wenn kleine Cluster beide Rollen auf denselben Maschinen betreiben.

Das Architekturdiagramm

So liest du es:

• Links: Zwei Producer senden Events mit der Bestell-ID als Key. Bestellung 8812 wird auf Partition 0 gehasht, Bestellung 9001 auf Partition 2.
• Mitte: drei Broker, jeder Leader für eine Partition und Follower für die beiden anderen. Gestrichelte Kanten zeigen die Replikation; die KRaft-Controller darunter verwalten Metadaten und Leader-Wahl.
• Rechts: Die Fulfillment-Gruppe hat drei Consumer, einen pro Partition. Der Analytics-Consumer gehört zu einer anderen Gruppe und liest daher jedes Event mit eigenen Offsets.
• Der Markdown-Block listet die Topic-Einstellungen, von denen das Bild abhängt.

Was in ein Kafka-Diagramm gehört

• Partitionen pro Topic und der Key, weil sie Reihenfolge und Parallelität festlegen.
• Replikationsfaktor und min.insync.replicas, weil sie die Haltbarkeit festlegen.
• Jede Consumer Group mit Namen, samt ihren Consumern.
• Retention oder Compaction pro Topic.
• Wer produziert und wer konsumiert, über Services hinweg, damit die Zuständigkeit klar ist.

Für die Muster, die auf Kafka aufbauen, siehe das Diagramm einer ereignisgesteuerten Architektur, das Transactional-Outbox-Pattern für zuverlässiges Publizieren aus einer Datenbank und das Architekturdiagramm einer Datenpipeline für Kafka als Zulieferer von Analytics.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem C4-Modell-Pack Container-Nodes für die Producer hinzu, mit ihrem Key in der Beschreibung.
3. Füge aus dem Daten-Pack drei Kafka-Nodes für die Broker hinzu, beschriftet mit den Partitionen, die sie führen und denen sie folgen, und einen Container für die KRaft-Controller.
4. Füge aus dem Basis-Pack einen Rahmen für die Consumer Group hinzu, mit einem Container pro Consumer, plus einen separaten Consumer für die zweite Gruppe.
5. Zeichne die Replikation als gestrichelte Kanten und füge einen Markdown-Block aus dem Basis-Pack mit den Topic-Einstellungen hinzu.

Das Beispiel nutzt 12 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Garantiert Kafka die Reihenfolge von Nachrichten? Innerhalb einer Partition ja, über Partitionen hinweg nein. Nutze einen Key, damit Records, die geordnet bleiben müssen, sich eine Partition teilen.

Wie viele Partitionen sollte ein Topic haben? Genug für den nötigen Durchsatz und die Zahl der Consumer, die du parallel betreiben willst, mit Raum zum Wachsen. Eine spätere Änderung der Zahl ändert, wie Keys auf Partitionen abgebildet werden.

Was passiert, wenn ein Broker ausfällt? Für jede Partition, deren Leader er war, wird ein aktueller Follower auf einem anderen Broker zum Leader. Mit Replikationsfaktor 3 und min.insync.replicas=2 gehen die Writes weiter.

Was ist eine Consumer Group? Eine Menge von Consumern, die sich die Partitionen eines Topics aufteilen. Verschiedene Gruppen lesen dasselbe Topic unabhängig, jede mit eigenen Offsets.

Braucht Kafka noch ZooKeeper? Nein. Kafka 4.0 und neuer laufen nur im KRaft-Modus, in dem ein Quorum von Controllern die Cluster-Metadaten verwaltet.

Kostenlos starten — ein Seat, keine Kreditkarte.