Kafka Transaktionen und Exactly-Once-Semantik

In einem verteilten System müssen wir immer davon ausgehen, dass einzelne Komponenten ausfallen. Es ist in verteilten Systemen im Allgemeinen nicht möglich, eine Nachricht exakt einmal zu senden.

Es ist relativ einfach, eine Nachricht höchstens einmal zuzustellen. In Kafka setzen wir dafür acks=0 im Producer. Der Producer sendet die Nachricht und wartet nicht auf eine Bestätigung. Ob die Nachricht ankommt oder nicht, ist in diesem Modus egal. Wenn sie ankommt, dann genau einmal. Wenn nicht, wird nicht erneut versucht. Also kommt sie höchstens einmal an.

At-least-once ist ebenfalls relativ einfach umzusetzen. Wir setzen acks=all im Producer. Der Producer sendet eine Nachricht und wartet auf die Bestätigung des Leaders. Bevor der Leader bestätigt, wartet er darauf, dass alle In-Sync Replicas die Nachricht erhalten haben. Wenn der Producer die Bestätigung erhält, weiß er, dass die Nachricht angekommen ist und unter vernünftigen Annahmen auch lesbar bleibt, selbst wenn der Leader ausfällt.

Exactly-once ist etwas anspruchsvoller. Wir können Nachrichten nicht einfach exakt einmal senden, da das Netzwerk jederzeit ausfallen kann. Dennoch erreichen wir auf Producer-Seite mit acks=all, min.insync.replicas=2 und enable.idempotence=true eine Exactly-Once-Semantik - solange derselbe Producer aktiv ist.

Wie funktioniert das genau? Der Producer sendet in jeder Nachricht eine Sequenznummer mit. Sie beginnt bei 0 und wird mit jeder Nachricht inkrementiert. Wenn der Leader die Sequenznummer 2 vor der Sequenznummer 1 erhält, erkennt er die Lücke und lehnt die 2 zunächst ab. Der Producer sendet dann sowohl 1 als auch 2 erneut. Wenn die Nachrichten in der richtigen Reihenfolge ankommen, werden sie nach der Replikation bestätigt. Was passiert, wenn der Producer das Ack nicht erhält? Er sendet die Nachricht erneut. Da der Leader dieselbe Sequenznummer bereits verarbeitet hat, verwirft er das Duplikat und bestätigt nur noch.

Mit Idempotenz stellen wir also sicher, dass eine Nachricht pro Producer-Session nicht doppelt geschrieben wird und die Reihenfolge erhalten bleibt. Aber nur, solange der Producer lebt und nicht in den Timeout delivery.timeout.ms läuft.

Reicht das schon für End-to-End-Exactly-Once? Noch nicht.

Mit Producer-Idempotenz allein können wir nicht sicherstellen, dass eine Nachricht genau einmal verarbeitet wird.

Stellen wir uns einen Service vor, der Nachrichten aus Kafka liest, verarbeitet und anschließend in ein anderes Topic schreibt.

Hier fehlt ein wichtiger Teil: Jede Leseoperation in Kafka ist zugleich auch eine Schreiboperation, weil wir Offsets committen müssen. Um eine Exactly-Once-Verarbeitung sicherzustellen, brauchen wir eine Methode, mehrere Schreiboperationen atomar auszuführen. Kurz: Wir brauchen Transaktionen.

Und genau das können wir mit Transaktionen in Kafka sicherstellen:

Mehrere Schreiboperationen atomar auszuführen. Nicht mehr und nicht weniger. Hier ein Pseudo-Code-Beispiel:

Das Problem dabei: Consumer nehmen nicht an Transaktionen teil, das heißt, sie können auch keine Offsets innerhalb einer Transaktion committen. Die Lösung dafür ist, dass der Producer an Stelle des Consumers die Offsets schreibt.

Aber haben wir nicht gesagt, dass Nachrichten im Log immutable sind? Ja - und tatsächlich werden Nachrichten auch bei später abgebrochenen Transaktionen ins Log geschrieben. Sie werden nicht gelöscht, sondern beim Konsumieren nur übersprungen. Dafür muss allerdings isolation.level=read_committed gesetzt sein, und das ist nicht der Standard.

Schauen wir uns eine Implementierung an. Wir nutzen hier Python mit der Confluent-Kafka-Python-Bibliothek, um den Code kompakt zu halten. In Java funktioniert das Prinzip genauso.

Wenn ich an Transaktionen denke, denke ich primär an ACID-Transaktionen in relationalen Datenbanken. Kafka-Transaktionen sind (leider) deutlich weniger mächtig als klassische ACID-Transaktionen. Aber schauen wir uns das genauer an:

Kurz zusammengefasst: In Kafka bekommen wir ein starkes A, ein eingeschränktes I und ein solides D. Wenn du vollständige ACID-Eigenschaften brauchst, kommst du an relationalen Datenbanken nicht vorbei.

Idempotenz ist ein wichtiger Baustein. Für End-to-End-Exactly-Once brauchst du in Read-Process-Write-Szenarien zusätzlich Transaktionen und korrekt konfigurierte Consumer mit read_committed. Wenn du diese Komplexität nicht selbst tragen willst, ist Kafka Streams häufig der pragmatischere Weg.