Kafka: Wie du Datenverlust beim Produzieren garantiert vermeidest

Die erste Stellschraube für zuverlässiges Produzieren ist die Acknowledgment-Strategie (acks). Dieser Parameter definiert, auf wie viele Bestätigungen der Producer wartet, bevor er eine Nachricht als erfolgreich gesendet betrachtet.

acks=0: Der Producer sendet die Nachricht und wartet auf keinerlei Bestätigung. Maximale Performance, aber hohes Risiko für Datenverlust.

acks=1: Der Producer wartet auf die Bestätigung des Leader-Brokers der jeweiligen Partition. Das war der Standard bis Kafka 3.4. Die Nachricht ist sicher, solange der Leader nicht genau nach der Bestätigung, aber vor der Replikation ausfällt.

acks=all (oder -1): Der Producer wartet, bis der Leader und alle In-Sync Replicas (ISRs) die Nachricht erhalten haben. Dies ist der neue Standard seit Kafka 3.4. Dies bietet die höchste Garantie gegen Datenverlust.

Für maximale Zuverlässigkeit ist acks=all also Pflicht. Doch das allein reicht nicht aus. Was passiert, wenn der Producer eine Bestätigung aufgrund eines temporären Netzwerkproblems nicht erhält und die Nachricht erneut sendet? Ohne weitere Vorkehrungen hättest du die Nachricht doppelt im Topic.

Hier kommt die Idempotenz ins Spiel. Indem du enable.idempotence=true (Standard seit Kafka 3.4) setzt, weist der Producer jeder Nachricht eine Sequenznummer zu. Der Broker speichert die letzte Sequenznummer pro Producer und Partition und verwirft Duplikate automatisch.

Mit dieser Kombination stellst du sicher, dass Nachrichten garantiert ankommen und nicht dupliziert werden.

Diese beiden Einstellungen sind die Grundlage für eine "Exactly-Once"-Semantik auf Producer-Seite.

Wir haben acks=all gesetzt, was bedeutet, der Producer wartet auf die Bestätigung aller In-Sync Replicas. Aber was genau bedeutet "in-sync" und wie viele Replicas brauchen wir?

Ein Replica gilt als "in-sync", wenn es nicht zu weit hinter dem Leader zurückliegt. Fällt ein Broker aus oder wird zu langsam, entfernt der Controller ihn aus der ISR-Liste für die betroffenen Partitionen. acks=all wartet also nicht auf alle konfigurierten Replicas, sondern nur auf die, die aktuell als gesund gelten. Das ist ein cleverer Mechanismus, denn sonst würde der Ausfall eines einzigen Brokers den gesamten Schreibvorgang blockieren.

Jetzt kommt die entscheidende Frage: Was passiert, wenn zu viele Broker ausfallen und nur noch der Leader übrig ist? acks=all wäre dann mit acks=1 identisch, und wir verlieren unsere Sicherheitsgarantie.

Um dieses Szenario zu verhindern, konfigurieren wir auf Broker- oder Topic-Ebene den Parameter min.insync.replicas. Dieser Wert legt fest, wie viele Replicas mindestens in der ISR-Liste sein müssen, damit ein Produce-Request überhaupt akzeptiert wird.

Unsere Empfehlung für Topics:

Mit dieser Konfiguration kann ein Broker ausfallen, ohne dass die Produktion beeinträchtigt wird. Fallen zwei Broker aus, stoppt der Producer die Produktion für die betroffenen Partitionen, da die Bedingung min.insync.replicas=2 nicht mehr erfüllt ist. Der Broker wirft eine NotEnoughReplicasException. Das ist genau das, was wir wollen: Lieber die Produktion anhalten, als einen potenziellen Datenverlust zu riskieren.

Selbst mit der perfekten Konfiguration kann es zu Fehlern kommen. Der Producer könnte abstürzen oder in einen Timeout laufen (delivery.timeout.ms), bevor er die Bestätigung vom Broker erhält. Wie gehst du damit um?

Falscher Ansatz: Stumpfes Neu-Senden Einfach die Nachricht in einem Callback erneut zu senden, ist eine schlechte Idee. Die interne Retry-Logik der Kafka-Client-Bibliothek ist weitaus intelligenter und respektiert die Idempotenz-Garantie. Ein manueller Retry hebelt diese Garantien aus und führt zu Duplikaten oder Reihenfolgeproblemen.

Bessere Ideen:

Es ist wichtig zu verstehen, was unsere Konfiguration leistet – und was nicht.

Was, wenn mehrere Nachrichten atomar geschrieben werden müssen? Wenn du mehrere Nachrichten, möglicherweise sogar in verschiedene Topics, als eine einzige, unteilbare Einheit ("all or nothing") schreiben musst, benötigst du Producer-Transaktionen. Dies ist ein fortgeschrittenes Thema, das den Rahmen dieses Artikels sprengen würde.

Für Consume-Process-Produce-Szenarien ist Kafka Streams mit der Einstellung processing.guarantee=exactly_once_v2 oft die beste und einfachste Lösung, da es Transaktionen intern verwaltet.

Zuverlässigkeit in verteilten Systemen ist kein Zufall, sondern das Ergebnis bewusster Architekturentscheidungen und sorgfältiger Konfiguration. Um sicherzustellen, dass deine Producer keine Nachrichten verlieren, hast du gelernt, die drei wichtigsten Hebel zu bedienen:

Für den Fehlerfall haben wir gesehen, dass ein kontrollierter Neustart durch die Infrastruktur oft die sauberste Lösung ist. Denk daran, dass diese Garantien auf den Producer beschränkt sind. Für End-to-End-Szenarien sind weiterführende Konzepte wie Kafka Streams oder Producer-Transaktionen der nächste logische Schritt.