Kafka

Veröffentlicht am: 6. August 2026

Die wichtigsten Befehle zum Merken

kcat -L — Topic- und Partitionsmetadaten prüfen.
kcat -C — Datensätze aus der gewählten Partition lesen.

Befehle und Optionen

Befehl oder Option	Bedeutung
`timeout 10`	Einen noch laufenden Aufruf nach zehn Sekunden beenden.
`-b localhost:9092`	Diese Brokeradresse als Einstieg verwenden.
`-L -t lab-events`	Metadaten des vorhandenen Topics anfordern.
`-C -p 0`	Direkt aus Partition 0 lesen.
`-o beginning`	Beim frühesten noch verfügbaren Offset beginnen.
`-c 2 -e`	Nach zwei Datensätzen oder am Partitionsende stoppen.
`-f '…'`	Format: `%p` Partition, `%o` Offset, `%s` Wert, `\n` Zeilenumbruch.

Das zitierte Format verarbeitet kcat. Dieses direkte Partitionslesen tritt keiner Consumer Group bei und verschiebt keine gespeicherten Gruppen-Offsets.

Die entscheidenden Konzepte

1. Ein Topic besteht aus geordneten Partitionen

Kafka speichert Datensätze in Partitionen eines Topics. Jede Partition ist ein geordnetes Log. Jeder Datensatz besitzt einen Offset als Position innerhalb dieser Partition.

Offsets sind keine globalen Nachrichtennummern des Topics. Zwischen verschiedenen Partitionen besteht keine eingebaute Gesamtordnung. Partitionierung ermöglicht Parallelität; Schlüsselwahl und Verteilung bestimmen zugleich, welche zusammengehörigen Daten geordnet verarbeitet werden können.

2. Lesen löscht den Datensatz nicht

Ein Consumer liest das Log an einer gewählten Position. Der Broker bewahrt Daten nach Regeln wie Zeit, Größe oder Kompaktierung auf, statt sie nach jedem Lesen zu entfernen.

Andere Consumer können dieselben Daten lesen; vorhandene Historie lässt sich wiederholen. Aufbewahrung bleibt begrenzt. Kompaktierung kann ältere Werte eines Schlüssels entfernen. Der früheste Offset muss nicht null sein, und Lücken sind möglich.

3. Consumer Groups verteilen Verarbeitungsverantwortung

Innerhalb einer Consumer Group werden Partitionen auf aktive Mitglieder verteilt. Im üblichen Gruppenmodell gehört eine Partition gleichzeitig einem Mitglied. Mehr Consumer als Partitionen erhöhen deshalb nicht automatisch die nützliche Parallelität.

Gespeicherte Offsets beschreiben den Gruppenfortschritt für Wiederanlauf. Sie unterscheiden sich von der festen Datensatzposition. Zu frühes Bestätigen kann Arbeit überspringen; Verarbeitung vor Fortschrittsbestätigung kann nach Ausfall Wiederholung verursachen.

4. Replikation und Verarbeitungskorrektheit sind getrennt

Partitionsreplikate unterstützen Ausfalltoleranz gemäß Replikations- und Bestätigungsregeln. Sie machen externe Datenbankänderungen oder API-Aufrufe nicht automatisch exakt einmalig.

Idempotente Produktion und Transaktionen bieten abgegrenzte Garantien. Ein Consumer mit externem Dienstaufruf braucht weiterhin Wiederholungs-, Duplikat- und Koordinationsregeln. Erfolgreiches Lesen belegt Verfügbarkeit dieses Datensatzes, nicht die Korrektheit der gesamten Verarbeitungskette.

Ein kleines Beispiel

Optional: Nutze das vorhandene Testtopic und führe die Befehle einzeln aus. Die Zeitgrenze verhindert unbegrenztes Warten auf einen unerreichbaren Broker.

timeout 10 kcat -b localhost:9092 -L -t lab-events
timeout 10 kcat -b localhost:9092 -C -t lab-events -p 0 -o beginning -c 2 -e -f 'partition=%p offset=%o value=%s\n'
timeout 10 kcat -b localhost:9092 -C -t lab-events -p 0 -o beginning -c 2 -e -f 'partition=%p offset=%o value=%s\n'

Die Metadaten sollten Partition 0, Leader und Replikate nennen. Beide Leseaufrufe starten bewusst gleich. Bleiben Aufbewahrung und Kompaktierung unverändert, vergleiche wiederholte Partitions-/Offsetpaare und Werte.

Wiederholte Datensätze zeigen, dass Lesen sie nicht entfernt hat. Weniger als zwei können das Partitionsende bedeuten; Status 124 bedeutet Abbruch durch timeout. Der Test ändert keinen Gruppenfortschritt und belegt weder Rebalancing noch Replikatwiederherstellung oder exakt einmalige Gesamteffekte.

Merke dir: Kafka bewahrt ein partitioniertes Log auf. Consumer verfolgen ihre Position, statt Datensätze beim Lesen zu entfernen.