Kafka im Produktivbetrieb: Partitionen, Consumer Lag und sichere Wiederherstellung

In einer Demo sendet ein Producer eine Nachricht und ein Consumer gibt sie aus. Im Produktivbetrieb fallen Broker aus, Consumer werden langsam und Ereignisschemata ändern sich. Entscheidend ist dann, ob Bestellungen weiterhin nachvollziehbar verarbeitet werden und ob sich ein Fehler sicher beheben lässt.

Als Beispiel dient ein Bestellsystem mit dem Topic orders.placed.v1, einer Consumer Group für die Reservierung von Bestand und einer weiteren für Analysen. Alle Zahlen sind Beispiele. Miss die eigenen Nutzdaten, Lastspitzen und Wiederherstellungsziele, bevor du die Clustergröße festlegst.

Beschreibe die Last zuerst

Erfasse Ereignisse pro Sekunde im Mittel und in Spitzen, typische sowie große Datensätze, Aufbewahrungsdauer, unabhängige Lesergruppen und tolerierbare Verarbeitungsverzögerung. Lege fest, wie schnell der Dienst nach dem Ausfall eines Consumers oder Brokers wieder aufholen muss. Oft ist die Reihenfolge pro Bestellung nötig, aber keine globale Reihenfolge aller Bestellungen.

Bei 2.000 Ereignissen pro Sekunde und durchschnittlich 1 KB entstehen grob 2 MB/s rohe Nutzdaten. Sieben Tage davon ergeben deutlich mehr als ein Terabyte. Das ist keine exakte Plattenberechnung: Kompression, Indizes, Replikate, Protokollaufwand und Lastspitzen verändern den Bedarf. Teste mit realistischen Datensätzen und plane Reserve ein.

Ein Consumer, der im Normalbetrieb nur so schnell wie der Eingang arbeitet, kann einen nach einem Ausfall entstandenen Rückstand nie abbauen. Berücksichtige deshalb zusätzliche Verarbeitungskapazität für das Aufholen.

Der Partition Key bestimmt die Reihenfolge

Kafka erhält die Reihenfolge innerhalb einer Partition. Wenn Ereignisse derselben Bestellung nacheinander verarbeitet werden müssen, ist orderId ein sinnvoller Key. customerId verspricht dagegen Reihenfolge pro Kunde. Ein konstanter Key überlastet eine einzelne Partition; zufällige Keys verteilen zwar die Last, verlieren aber die Reihenfolge zusammengehöriger Ereignisse.

Acht Partitionen erlauben für dieses Topic höchstens acht gleichzeitig aktive Consumer in derselben Group. Das heißt nicht, dass alle gleich viel Arbeit bekommen. Ein besonders häufiger Key kann eine Partition überlasten. Betrachte Durchsatz, Verzögerung und Lag deshalb pro Partition und nicht nur im Durchschnitt des Topics.

Wer die Partitionszahl später erhöht, kann zukünftige Ereignisse eines Keys auf eine andere Partition lenken. Bei strenger, langfristiger Reihenfolge braucht die Umstellung einen Plan, möglicherweise ein neues Topic und einen kontrollierten Wechsel. Auch eine vorsorgliche Flut von Partitionen kostet Clusterressourcen und erschwert den Betrieb.

Replikation, Acks und Grenzen von Transaktionen

Der Replikationsfaktor legt fest, wie viele Kopien einer Partition der Cluster hält. Drei Kopien über geeignete Ausfallbereiche verteilt sind oft sinnvoll. Die wirkliche Haltbarkeit hängt aber auch von Platzierung und Zustand der Replikate, acks beim Producer und min.insync.replicas ab. Prüfe diese Einstellungen gemeinsam; acks=all allein beschreibt das Versprechen nicht vollständig.

Ein idempotenter Producer kann Duplikate durch erneute Sendeversuche an Kafka begrenzen. Er macht weder zwei unabhängige Geschäftsanforderungen zu einer noch eine PostgreSQL Transaktion mit einem Kafka Publish atomar. Kafka Transaktionen können in einer Kafka zu Kafka Verarbeitung Ausgabedatensätze und Consumer Offsets koordinieren. Zahlungen, E-Mails und externe Datenbankschreibvorgänge benötigen eigene Idempotenzregeln.

Schalte in einer repräsentativen Testumgebung einen Broker ab und prüfe Fehlermeldungen, Erholungszeit und Consumer Verhalten. Ein lokaler Einzelbroker ist zum Lernen geeignet, beweist aber keine Ausfallsicherheit. Kafka 4.x nutzt KRaft; der ZooKeeper Modus wurde mit Kafka 4.0 entfernt. Veraltete Betriebsanleitungen müssen zur eingesetzten Version passen.

Lag und Geschäftsdauer zusammen messen

Eine Consumer Group speichert ihre Position über Offset Commits. Lag vergleicht diese Position mit dem letzten verfügbaren Offset je Partition. Die Zahl ist hilfreich, aber keine Zeitangabe: Tausend kleine Datensätze lassen sich rasch verarbeiten, während tausend langsame API Aufrufe Stunden dauern können. Miss zusätzlich das Alter des ältesten unbearbeiteten Ereignisses und die Zeit bis zum Geschäftsergebnis.

Signal	Mögliche Ursache	Erste Prüfung
Lag steigt überall	Eingang wächst oder Verarbeitung stockt	Eingangs- und Verarbeitungsrate vergleichen
Eine Partition hängt	Häufiger Key oder fehlerhafter Datensatz	Key, Offset und Fehler finden
Häufige Rebalances	Neustarts oder verspäteter Poll	Mitgliedschaft und Laufzeiten ansehen
Outbox Alter wächst	Veröffentlichung vor Kafka stockt	Publisher und Fehler prüfen
Unterreplizierte Partitionen	Broker, Platte oder Netzwerk gestört	Clusterzustand prüfen
Fehlerqueue wächst	Ungültiges Ereignis oder Schema	Erste fehlerhafte Version suchen

Richte Alarme nach fachlicher Toleranz aus. Muss Bestand innerhalb von zwei Minuten reserviert sein, miss die Dauer vom Ereignis bis zur Reservierung. Group und Partition sind nützliche Dashboard Labels. Eine eigene Metrikserie für jede orderId treibt dagegen die Kardinalität hoch.

Rebalances und Wiederholungen kontrollieren

Wenn die Group Mitgliedschaft wechselt, verteilt Kafka Partitionen neu. Ein Consumer darf bei einem Batch im Speicher nicht voraussetzen, dass er seine Partition weiter besitzt. Verwende die dokumentierten Rebalance Hooks des Clients, beende laufende Arbeit geordnet und committe nur abgeschlossene Verarbeitung. Blockieren lange Aufgaben den Poll, kann eine begrenzte Worker Pipeline mit sorgfältigem Offset Tracking helfen.

Mehr Consumer helfen nur bei freien Partitionen und einem passenden Engpass. Wenn alle auf dieselbe langsame Datenbank oder externe API warten, verstärkt zusätzliche Parallelität die Störung. Begrenze gleichzeitige Aufrufe, verwende Backpressure und erwäge ein gezieltes Pausieren von Partitionen, wenn der Client das unterstützt.

Stürzt ein Consumer nach dem Datenbankschreiben, aber vor dem Offset Commit ab, wird das Ereignis erneut geliefert. Nutze eine stabile eventId und beispielsweise einen Unique Constraint oder eine Tabelle verarbeiteter Vorgänge. Ein Commit vor der Nebenwirkung kann bei einem Absturz Arbeit verlieren. Für beliebige externe Effekte gibt es keinen universellen „exactly once“ Schalter.

Aufbewahrung, Replay und Schemaverträge

Die Retention bestimmt, wie lange Kafka Datensätze behält, unabhängig vom Lesefortschritt. Sie muss erwartete Ausfälle und das versprochene Replay Fenster mit Reserve abdecken. Fällt eine Group hinter den frühesten noch gespeicherten Offset zurück, kann sie die verlorene Geschichte nicht mehr aus Kafka lesen. Alarme vor diesem Zeitpunkt und eine andere Archivquelle sind gegebenenfalls nötig.

Compaction bewahrt bei Zustandstopics langfristig den neuesten Wert pro Key, ersetzt aber kein vollständiges Ereignisarchiv. Eine Projektionstabelle neu aufzubauen unterscheidet sich erheblich davon, E-Mails oder Abbuchungen erneut auszulösen. Dokumentiere für Replay die Startposition, Group, deaktivierten Nebenwirkungen, Prüfung des Ergebnisses und Rückkehr zum Normalbetrieb.

Ein Ereignisvertrag benennt Eigentümer, Bedeutung, Key, eventId, Ereigniszeit, Version, Pflichtfelder und Kompatibilitätsregel. Auch ein zusätzliches Feld kann einen strikten Decoder beschädigen. Teste Änderungen gegen Consumer, die noch eine ältere Version verwenden. Veröffentliche keine kompletten ORM Objekte oder Geheimnisse. Kläre, wer Retention, Partitionszahl, Schemata und Zugriffsrechte ändern darf.

Sicherheit und Incident Runbook

Verschlüssele die Verbindung, authentifiziere Clients und vergib Rechte für Topics und Groups nach dem Minimalprinzip. Bewahre Zugangsdaten in einem Secret Store statt in Git auf und rotiere sie. Reduziere personenbezogene Daten in Ereignissen und vermeide vollständige Payloads in Logs. Trenne Entwicklungs- und Produktionszugriff.

Prüfe vor einem Release Schema Kompatibilität, realistische Lasttests und Dashboards für Producer Fehler, Outbox Alter, Lag, Rebalance Rate und Geschäftsdauer. Entscheide bewusst, ob eine neue Group bei earliest oder latest beginnt. Plane einen Rollback, der die Ereignisbedeutung nicht stillschweigend ändert.

Steigt der Lag plötzlich, gehe geordnet vor:

1. Bestimme Group, Topic und Partitionen. Ist der Eingang gestiegen oder die Verarbeitung gefallen?
2. Prüfe Deployments, Schemata, Broker Wartung, Abhängigkeiten und Berechtigungen.
3. Untersuche einen sicheren Datenausschnitt mit fehlerhaftem Offset und Fehlertyp, ohne sensible Payloads offenzulegen.
4. Schütze nachgelagerte Systeme: Drossele Parallelität oder pausiere eine Partition, wenn Retries den Ausfall verstärken.
5. Repariere Code oder Daten und starte mit Idempotenzprüfung neu oder spiele gezielt erneut ab.
6. Bestätige die tatsächlichen Reservierungen und anderen Ergebnisse. Sinkender Lag beweist noch keine fachliche Korrektheit.

Zur Produktionsfreigabe gehören geprobter Broker Ausfall, Consumer Absturz, fehlerhafter Datensatz und Replay. Erst diese Übungen zeigen, ob Partitionswahl, Kapazität, Nebenwirkungen und Wiederherstellung zusammenpassen.

Quellen

• Apache Kafka Einführung
• Apache Kafka Dokumentation
• Kafka Upgrade und KRaft
• Confluent Consumer Design