xkafka — So nutzt man Kafka in Go einfacher

• xkafka ist eine Open-Source-Bibliothek, mit der sich Kafka in einer Go-Umgebung so einfach wie ein HTTP-Service nutzen lässt
• Bei der bisherigen Nutzung von confluent-kafka-go waren komplexe Verarbeitungsschleifen und viel Boilerplate-Code nötig, aber xkafka ermöglicht mit der Struktur aus Handler, Middleware und Message, sich auf die Kernlogik zu konzentrieren
• Nachrichten veröffentlichen und konsumieren lässt sich so intuitiv wie mit einem HTTP-Request/Response-Muster verarbeiten; zudem verbirgt xkafka viel von der Kafka-Komplexität wie Offset-Management, Nebenläufigkeits-Konfiguration und Error Handling
• Verschiedene in Produktivsystemen benötigte Muster wie Streaming/Batch-Verarbeitung, sequentielle/asynchrone Verarbeitung sowie At-most-once-/At-least-once-Garantien werden einfach unterstützt
• Praxisrelevante Muster wie hierarchisches Error Handling und Middleware-basiertes Retry/Logging/Metrics lassen sich leicht anwenden

---

HTTP-ähnliches Kafka

• xkafka ist eine Bibliothek, die Kafka in Go wie einen HTTP-Service abstrahiert
  • Message ähnelt einer HTTP-Anfrage und umfasst Topic/Partition/Offset/Key/Value/Header/Callback usw.
  • Handler verarbeitet wie ein HTTP-Handler die Business-Logik
  • Middleware ermöglicht es, Zusatzfunktionen wie Logging, Metrics und Retry getrennt von der Business-Logik anzuwenden

Nachrichten veröffentlichen (Publishing Messages)

• Mit xkafka.NewProducer wird ein Producer erstellt, danach wird ein Nachrichtenobjekt erzeugt und mit der Funktion Publish veröffentlicht
• Asynchrones Veröffentlichen (AsyncPublish) und die Registrierung von Callbacks sind möglich, was hohe Performance oder asynchrone Event-Verarbeitung erleichtert
• Eine Hintergrund-goroutine übernimmt die Zustellung der Nachrichten, und über Callbacks lässt sich der Zustellstatus verfolgen

Nachrichten konsumieren (Consuming Messages)

• Beim Erstellen eines Consumers werden Handler-Funktion sowie Topic/Broker/Konfiguration usw. festgelegt
• Mit consumer.Use() kann zusätzliche Middleware eingebunden werden
• Mit consumer.Run(ctx) wird der Nachrichtenkonsum gestartet

Streaming vs. Batch

• Streaming: Jede eintreffende Nachricht wird sofort einzeln verarbeitet. Vorteilhaft bei geringerem Durchsatz, zum Sparen von Speicher oder für starke Verarbeitungsgarantien
• Batch: Verarbeitung gebündelt nach einer bestimmten Anzahl oder einem Zeitintervall. Vorteilhaft für Systeme mit hohem Durchsatz oder zur Entlastung von Downstream-Systemen

Sequentiell oder asynchron

• Standard ist die sequentielle Verarbeitung (Sequential) — erst wenn eine Verarbeitung abgeschlossen ist, wird die nächste Nachricht gelesen
• Mit xkafka.Concurrency(N) wird ein asynchroner (Async) Modus unterstützt, in dem N Nachrichten (oder Batches) gleichzeitig verarbeitet werden

Offset-Management

• Im Kafka-Standardverhalten wird der Offset direkt nach der Nachrichtenzustellung weitergeschoben, wodurch es bei Ausfällen zu Nachrichtenverlust kommen kann
• xkafka setzt enable.auto.offset.store=false, sodass der Offset für eine Nachricht (oder einen Batch) erst nach abgeschlossener Verarbeitung gespeichert wird
• Auch ohne separate Verwaltung des Nachrichtenstatus in einer Datenbank oder Queue lassen sich so Verarbeitungszusagen in Kafka umsetzen

• At-Most-Once Guarantee

  • Standardmäßig werden Offsets entsprechend Kafkas enable.auto.commit=true im Hintergrund committet
  • Mit xkafka.ManualCommit(true) und sequentieller Verarbeitung wird der Offset vor dem Lesen jeder Nachricht bzw. jedes Batches committet, wodurch At-most-once garantiert wird

• At-Least-Once Guarantee

  • In Kombination aus xkafka.ManualCommit(true) und Nebenläufigkeit (N>1) werden Offsets auch bei paralleler Verarbeitung synchron und in Reihenfolge committet
  • Das Muster für At-least-once lässt sich dadurch leicht anwenden

Error Handling

• Auf Handler-Ebene

  • Innerhalb des Handlers können Applikationsfehler verarbeitet oder Nachrichten an eine Dead Letter Queue gesendet werden
  • Bei Erfolg msg.AckSuccess(), beim Überspringen msg.AckSkip(), bei Fehler msg.AckFail(err) — die Steuerung erfolgt explizit

• Auf Middleware-Ebene

  • In Middleware lassen sich gemeinsame Logiken wie Retry und Error-Logging über mehrere Handler hinweg wiederverwenden
  • Je nach Fehlerart können unterschiedliche Retry-Strategien oder Verarbeitungsweisen leicht angewendet werden

• Auf globaler Ebene

  • Fehler des Kafka-Brokers oder der Bibliothek werden zentral über die Pflichtoption xkafka.ErrorHandler verarbeitet
  • Gibt dieser Handler einen non-nil-Fehler zurück, wird der Betrieb von Consumer/Producer gestoppt

Fazit

• xkafka verwandelt die komplexe Nutzungserfahrung von Apache Kafka in eine für Go-Entwickler vertraute HTTP-Server-Struktur
• Es reduziert unnötige Boilerplate und schafft eine Umgebung, in der man sich nur auf die Business-Logik konzentrieren kann
• Im Vergleich zu bestehendem confluent-kafka-go-Code ist es deutlich kompakter und intuitiver
• Mit der offiziellen Dokumentation und den Beispielen kann man sofort loslegen

[penza1]

Hm, ich dachte eigentlich, dass in Golang
sarama eher bevorzugt wird ...
Kafka-Clients sind aber komplizierter als man denkt – bei Broker-Ausfällen oder Ausnahmen
ist es sehr komplex, alle Fälle abzudecken ...