Apache Kafka Clients richtig konfigurieren

batch.size= z.B. 900000: (Standard: 16KiB) Dieser Wert ist für die meisten Anwendungsfälle zu klein. Erhöhe ihn auf bis zu 1 MB. Dies ermöglicht es deinem Producer, mehr Daten in einer einzigen Netzwerkanfrage zu senden, was den Overhead reduziert und den Durchsatz verbessert.

linger.ms=5, 10 oder 100: (Standard: 0ms) Diese Einstellung arbeitet Hand in Hand mit batch.size. Sie weist den Producer an, bis zu einer bestimmten Zeit (Standard: 0 ms) zu warten, bis sich ein Batch gefüllt hat, bevor er es sendet. Eine Erhöhung auf wenige Millisekunden kann den Durchsatz erheblich verbessern, ohne die Latenz stark zu beeinträchtigen.

compression.type=lz4 oder zstd: (Standard: none) Das Komprimieren deiner Nachrichten, bevor sie an Kafka gesendet werden, kann die Netzwerkbandbreite sparen und den Durchsatz verbessern. Mit Algorithmen wie LZ4 oder Zstd kannst du hervorragende Ergebnisse erzielen.

transactional.id={hostname}: Diese Einstellung wird nur benötigt, wenn du Producer-Transaktionen verwendest. Die transactional.id muss für jede Producer-Instanz eindeutig, aber über Neustarts hinweg persistent sein. Wenn eine Producer-Instanz neu startet, verwendet Kafka diese ID, um zu verhindern, dass „Zombie“-Producer Transaktionen committen. Nutze in Kubernetes StatefulSets für transaktionale Producer.

partitioner=murmur2_random: (Standard: Murmur2Partitioner in Java, consistent_random in librdkafka) Der Partitioner bestimmt, an welche Partition eine Nachricht gesendet wird. Wenn du sowohl Java- als auch Nicht-Java-Producer verwendest, stelle bitte sicher, dass alle Producer den Partitioner auf murmur2_random setzen, um eine konsistente Partitionierung zu gewährleisten.

group.instance.id={hostname}: Stellt sicher, dass ein Consumer sich nach einem Neustart an sein vorheriges Assignment "erinnert" und somit teure Rebalances vermieden werden. Aber: Der Neustart muss innerhalb der session.timeout.ms stattfinden.

session.timeout.ms= z.B. 60000: (Standard: 30000) Diese Einstellung definiert die maximale Zeit, die ein Consumer nicht verfügbar sein darf, bevor er als ausgefallen betrachtet wird und die Consumer-Gruppe rebalanced wird. Erhöhe diesen Wert auf einen Wert, bei dem ein Consumer seinen Ausfall leicht erkennen, herunterfahren und den Pod neu starten kann. Konfiguriere die Einstellung nur zusammen mit group.instance.id.

group.protocol=consumer: (Standard: classic) Verwende die neue Generation des Consumer-Rebalance-Protokolls (lies KIP-848 für weitere Informationen). Erfordert Kafka 4.0 oder höher. Macht das Rebalancing viel schneller!

client.rack={dc-name}: Wenn du deinen Kafka-Cluster und deine Clients in einer Cloud-Umgebung mit mehreren Verfügbarkeitszonen (AZ) betreibst, kannst du die client.rack sowohl auf den Brokern als auch auf den Consumern festlegen. Dies ermöglicht es dem Consumer, es zu bevorzugen, von einer Replica in derselben AZ zu lesen, was die Datenübertragungskosten zwischen den AZs erheblich senken kann.

num partitions: Die Anzahl der Partitionen wirkt sich direkt auf die Parallelität und Skalierbarkeit deines Topics aus. Die Faustregel lautet, mindestens so viele Partitionen wie Mitglieder deiner Consumer-Gruppe zu haben. Für eine detailliertere Anleitung schaue dir unseren Artikel zu diesem Thema an.

replication-factor=3: (Standard: 1) Die Anzahl, wie oft die Daten einer Partition über Broker hinweg repliziert werden. 3 ist der Goldstandard für die meisten Produktionsumgebungen, da er eine hohe Verfügbarkeit zu vernünftigen Kosten bietet.

min.insync.replicas=2: (Standard: 1) Wie viele In-Sync-Replicas verfügbar sein müssen, damit Producer in eine Partition schreiben können. Bei einem Replikationsfaktor von 3 bedeutet ein Wert von 2, dass ein Broker ausfallen kann, ohne die Produktion zu beeinträchtigen, und ein weiterer ausfallen kann, ohne Daten zu verlieren.

cleanup.policy: (Standard: delete) Dies definiert, wie Kafka mit alten Nachrichten umgeht. Der Standardwert ist delete, was bedeutet, dass Nachrichten nach einer festgelegten Zeit gelöscht werden. Für Anwendungsfälle wie Change Data Capture oder Event Sourcing könntest du compact verwenden, was alte Nachrichten für denselben Key entfernt.

retention.hours: (Standard: 168 Stunden (7 Tage)) Diese Einstellung steuert, wie lange Kafka Nachrichten aufbewahrt, bevor sie gelöscht werden. Der Standardwert beträgt 7 Tage, aber du solltest diesen basierend auf deinen Business-Anforderungen anpassen.