Kafka

Apache Kafka ist eine verteilte Streaming- und Messaging-Plattform, die große Datenmengen in Echtzeit verarbeiten kann. Sie wird genutzt, um Nachrichten zwischen Systemen asynchron und zuverlässig auszutauschen.

RabbitMQ ist ein Message Queue-System mit Push-Mechanismus und Fokus auf garantierte Zustellung. Kafka ist ein Distributed Log System, das Nachrichten auf Partitionen speichert und von Consumer-Gruppen abruft. Kafka ist besser skalierbar und für Event-Streaming oder Datenanalyse optimiert.

Producer senden Nachrichten in Topics. Broker verwalten Topics und Partitionen. Consumer lesen Nachrichten. Zookeeper verwaltete früher Metadaten und wird heute durch den Kafka Controller ersetzt.

Ein Topic ist ein Nachrichtenkanal. Producer schreiben Nachrichten in Topics, Consumer lesen sie. Topics werden in Partitionen unterteilt, um paralleles Schreiben und Lesen zu ermöglichen.

Partitionen ermöglichen horizontale Skalierung. Jede Partition ist eine geordnete, unveränderliche Sequenz von Nachrichten. Sie erlauben parallele Verarbeitung und Lastverteilung.

Producer schreiben Nachrichten in partitionierte Topics. Partitionen liegen verteilt auf mehreren Brokern. Consumer lesen sequenziell und speichern ihren Fortschritt als Offset. Nachrichten werden erst nach Ablauf der Retention Time gelöscht.

Ein Consumer liest Nachrichten aus einem Topic. Eine Consumer Group besteht aus mehreren Consumern, die sich Partitionen teilen. Jede Nachricht wird pro Gruppe genau einmal verarbeitet.

Kafka nutzt Replikation über mehrere Broker. Mit acks=all wird eine Nachricht erst bestätigt, wenn alle Replikate geschrieben haben. min.insync.replicas schützt zusätzlich vor Datenverlust.

Ein Offset ist der Positionszeiger innerhalb einer Partition. Er zeigt an, welche Nachricht zuletzt gelesen wurde. Offsets werden meist im internen Topic __consumer_offsets gespeichert.

Innerhalb einer Partition sind Nachrichten strikt geordnet. Über mehrere Partitionen gibt es keine globale Reihenfolge. Ein geeigneter Partition Key stellt Reihenfolge für zusammengehörige Nachrichten sicher.

@KafkaListener dient zum Empfangen von Nachrichten als Consumer. KafkaTemplate wird verwendet, um Nachrichten als Producer zu senden.

Consumer Lag ist die Differenz zwischen dem neuesten Offset und dem gelesenen Offset. Ein hoher Lag zeigt, dass der Consumer nicht schnell genug verarbeitet.

Ich verwende ein Schema-Registry-System. Damit werden Versionierung und Abwärtskompatibilität sichergestellt.

Idempotenz verhindert doppelte Nachrichten bei Wiederholungen. Transaktionen stellen sicher, dass mehrere Nachrichten atomar geschrieben werden. Zusammen ermöglichen sie Exactly-Once-Delivery.

Wenn sich die Consumer einer Gruppe ändern, werden Partitionen neu verteilt. Kafka sorgt dafür, dass jede Partition genau einem Consumer zugeordnet ist.

Ein Broker ist ein Kafka-Server, der Nachrichten speichert und bereitstellt. Ein Cluster besteht aus mehreren Brokern. Sie sorgen gemeinsam für Skalierung und Ausfallsicherheit.

Die Retention Time bestimmt, wie lange Nachrichten gespeichert bleiben. Nachrichten werden zeit- oder größenbasiert gelöscht. Lesen hat keinen Einfluss auf die Löschung.

Log Compaction hält pro Key nur den letzten Wert. Alte Werte werden entfernt, nicht aber der Key. Das ist nützlich für Zustandsdaten.

Der Partition Key bestimmt, in welche Partition eine Nachricht geschrieben wird. Gleiche Keys landen immer in derselben Partition. Das ist wichtig für Reihenfolge.

Exactly-Once garantiert, dass Nachrichten genau einmal verarbeitet werden. Kafka erreicht das mit Idempotenz und Transaktionen. Es ist besonders wichtig bei Finanz- oder Zustandsdaten.

Nachrichten können mehrfach verarbeitet werden. Das System garantiert aber, dass keine Nachricht verloren geht. Consumer müssen idempotent sein.

Nachrichten werden höchstens einmal verarbeitet. Datenverlust ist möglich. Dafür ist die Latenz gering.

Kafka Connect ist ein Framework zur Anbindung externer Systeme. Es ermöglicht einfache Datenimporte und -exporte. Beispiele sind Datenbanken oder Cloud-Systeme.

Kafka Streams ist eine Library zur Stream-Verarbeitung. Sie erlaubt Transformationen direkt auf Kafka-Daten. Kein separates Cluster ist nötig.

Ein State Store speichert lokalen Zustand für Stream-Verarbeitung. Er wird für Aggregationen und Joins genutzt. Kafka repliziert diesen Zustand.

Neue Kafka-Versionen ersetzen Zookeeper durch den internen Controller. Das vereinfacht Betrieb und Architektur. Metadaten werden intern verwaltet.

Kafka selbst kennt keine Backpressure. Consumer steuern ihre Geschwindigkeit über Polling. Das Design verhindert Überlastung durch Pull-Mechanismus.

Ein Dead Letter Topic speichert fehlerhafte Nachrichten. Dadurch gehen sie nicht verloren. Fehler können später analysiert werden.

Man erhöht die Anzahl der Consumer in einer Gruppe. Die maximale Parallelität ist durch die Anzahl der Partitionen begrenzt. Mehr Consumer als Partitionen bringen keinen Vorteil.

ISR steht für In-Sync Replicas. Nur diese Replikate gelten als aktuell. Sie sind entscheidend für acks=all.

Throttling begrenzt Durchsatz für Producer oder Consumer. Es schützt das Cluster vor Überlastung. Es wird häufig in Multi-Tenant-Umgebungen genutzt.

Man überwacht Lag Durchsatz und Broker-Status. Tools wie Prometheus oder Kafka UI werden genutzt. Monitoring ist entscheidend für Stabilität.

Sie definiert Anzahl und Schlüsselwahl. Gute Strategien vermeiden Hot Partitions. Sie sind wichtig für Performance.

Schema Evolution beschreibt kontrollierte Änderungen an Nachrichtenformaten. Sie muss abwärts- oder vorwärtskompatibel sein. Schema Registry unterstützt das.

Kafka ist ungeeignet für einfache Request-Response-Kommunikation. Auch sehr kleine Systeme profitieren oft nicht. Der Betrieb ist komplexer als klassische Queues.