Kafka gegen NATS: Ein Vergleich für die Nachrichtenverarbeitung

In einer verteilten Architektur bilden Kommunikationen zwischen Systemen das Fundament der gesamten Infrastruktur. Die Leistungsfähigkeit, Skalierbarkeit und Zuverlässigkeit der Infrastruktur hängen stark davon ab, wie Ereignisse/Nachrichten/Daten ausgetauscht und persistiert werden.

Kafka und NATS sind zwei beliebte Tools für die Verarbeitung von Streams und Nachrichten. Sie haben unterschiedliche Architekturen und verschiedene Leistungsmerkmale. Sie sind für spezifische Anwendungsfälle geeignet. In diesem Artikel werden wir die Features von NATS mit Kafka vergleichen und die Anwendungsfälle erläutern, mit denen ich bei der Arbeit konfrontiert wurde.

1. Architektur und Komplexität

NATS

Die NATS Infrastruktur besteht aus zwei Hauptkomponenten:

Kern-NATS

Der Kern-NATS ist das Basis-Messaging-Framework. Dies unterstützt Publish-Subscribe (ermöglicht das Senden von Nachrichten an mehrere Abonnenten), Request-Reply (ermöglicht synchrone Kommunikation) und Queue Groups (ermöglicht die Lastverteilung unter mehreren Abonnenten innerhalb einer Gruppe). 

Dies ist für Einfachheit, geringe Latenz, hohe Leistung und Skalierbarkeit konzipiert. Es funktioniert sehr gut in Szenarien, die eine geringe Latenz und hohe Durchsatzraten erfordern. Allerdings bietet der Kern-NATS allein nur ungarantierte Zustellung, was bedeutet, dass Nachrichten nur an aktive Abonnenten gesendet werden. Daten gehen verloren, wenn die Abonnenten offline sind. Der Kern-NATS ist eine gute Option, wenn Geschwindigkeit und Skalierbarkeit Vorrang vor Haltbarkeit haben.

JetStream

JetStream bringt Persistenzfähigkeiten an die Spitze von Core NATS. Dies half, Nachrichtendauerhaftigkeit und -zuverlässigkeit bereitzustellen. Es ermöglicht, dass Nachrichten oder Ereignisse persistiert (auf Festplatte oder im Speicher) und wieder abgespielt werden. Persistierte Nachrichten können neuen oder wiederhergestellten Abonnenten erneut abgespielt werden. Mit JetStream erhalten Benutzer zusätzliche Funktionen:

1. Stream-Retention: Wie lange Nachrichten aufbewahrt werden. Es kann auf Größe, Zeit oder Verbrauchergrenzen basieren.
2. Verbraucherbeständigkeit: Ermöglicht Verbrauchern, dort fortzufahren, wo sie aufgehört haben.
3. Nachrichtenbestätigung: Dies stellt die Zuverlässigkeit der Zustellung sicher.

JetStream fügt Core NATS eine Schicht von Komplexität hinzu. Dies bringt jedoch das wichtige Feature mit sich, die Anwendungsfälle für garantierte Zustellung, Persistenz und Wiederabspielbarkeit zu unterstützen.

Kafka

Kafka ist ein verteiltes Messaging-System, das auf einer Log-basierten Broker-Architektur aufgebaut ist. Daten in Kafka sind in Themen organisiert und können mehrere Partitionen haben. Verbraucher sind mit diesen Partitionen verbunden. Diese Architektur ermöglicht es Kafka, die Nachrichtenverarbeitung für ein einzelnes Thema zu parallelisieren. Daten werden sequenziell zu einem Thema/Partition hinzugefügt. Kafka garantiert die Reihenfolge in einer Partition. In einem Kafka-Cluster können viele Broker vorhanden sein, von denen jeder eine Liste von Themen und Partitionen verwaltet. Um hohe Verfügbarkeit und Datenverlust zu verhindern, verlässt sich Kafka auf einen Replikationsfaktor, bei dem Partitionen über mehrere Kafka-Broker repliziert werden. Wie Sie sehen können, gibt es mehrere Komponenten, die verwaltet werden müssen, um eine hohe Durchsatzrate, Fehlertoleranz, Datenspeicherung und horizontale Skalierbarkeit zu erreichen. Dies erhöht die architektonische Komplexität von Kafka.

2. Hohe Verfügbarkeit und Leistung 

NATS 

Alle Knoten in einem Cluster sind in einem Mesh miteinander verbunden, und der Client kann sich mit jedem Knoten verbinden. Diese Konfiguration vermeidet einen einzelnen Ausfallpunkt. Wenn ein Knoten ausfällt, wird der Client automatisch mit den anderen Knoten verbunden, ohne manuelles Eingreifen. Dies wird als Selbstheilung in NATS bezeichnet. Ein JetStream-aktivierter Knoten verteilt die Streams auf alle Knoten. Streams werden innerhalb eines Mesh-Clusters hoch verwaltet und Lasten werden über die JetStream-aktivierten Knoten ausgeglichen. 

JetStream unterstützt auch die Spiegelung von Daten über mehrere Cluster oder Knoten hinweg. In JetStream werden Führer pro Stream gewählt. Die Replikation jedes Streams kann konfiguriert werden. All diese Dinge gewährleisten Haltbarkeit und Verfügbarkeit in NATS.

Kafka

Kafkas hohe Verfügbarkeit basiert auf der Replikation. Jedes Thema kann eine oder mehrere Partitionen haben. Jede Partition wird über Kafka-Broker repliziert. Dadurch wird die Datenredundanz und Verfügbarkeit gewährleistet. Kafka folgt einem Leader-Follower-Replikationsmechanismus. Ein Leader kümmert sich um Lese- und Schreibvorgänge. Der Follower arbeitet an der Replikation der Daten.

Kafka pflegt etwas, das ISR (In-Sync-Replikas) für jede Partition genannt wird. Wenn der Leader ausfällt, wird eines der ISR zum Leader. Zur Verwaltung von Cluster-Metadaten und zur Leader-Wahl verlässt sich Kafka auf Zookeeper (KRaft in den neueren Versionen).

3. Nachrichtenmuster

NATS

NATS verwendet nach Themen basierte Nachrichten. Dies ermöglicht es Diensten und Streams, Pub-Sub, Request-Reply und Warteschlangen-Abonnentenmuster zu verwenden. Themen in NATS können mit Hierarchie und Platzhaltern konstruiert werden. Ein einzelner NATS-Stream kann mehrere Themen speichern, und Client-Anwendungen können serverseitige Filterung verwenden, um nur die interessierten Themen zu empfangen. Die Verbindung in NATS ist bidirektional und ermöglicht es Clients, gleichzeitig zu veröffentlichen und zu abonnieren. NATS unterstützt auch Warteschlangenverwaltung, die der von RabbitMQ sehr ähnlich ist.

Kafka

Streams in Kafka unterstützen Pub-Sub und themenbasierte Nachrichten. Die Lastenverteilung kann durch Verbrauchergruppen und die Partitionierung der Themen erreicht werden.

4. Zustellungsgarantien

NATS

NATS unterstützt verschiedene Zustellungsgarantien. NATS allein kann eine Zustellungsgarantie „höchstens einmal“ unterstützen. NATS-Server mit aktiviertem JetStream können zwei weitere Arten von Garantien unterstützen. Es handelt sich um Garantien „mindestens einmal“ und „genau einmal“. NATS kann ‚Acks‘ an einzelne Nachrichten senden. Bitte beachten Sie die offizielle NATS-Dokumentation für die verschiedenen von ihr unterstützten ‚Acks‘. Basierend auf dem Typ des ‚Acks‘ kann NATS Nachrichten erneut zustellen.

Kafka

Kafka unterstützt Garantien mindestens einmal und genau einmal. Die Nachrichtenreihenfolge ist auf Partitionsebene garantiert. Eine globale Reihenfolge ist in Kafka nicht möglich.

5. Nachrichtenspeicherung und Persistenz

NATS

NATS unterstützt Speicherung im Arbeitsspeicher und auf Dateibasis. Es gibt mehrere Optionen, um die Nachrichten wiederzugeben. Die Wiedergabe von Nachrichten kann nach Zeit, Anzahl oder Sequenznummer erfolgen.

Kafka

KAFKA unterstützt nur dateibasierte Persistenz. Nachrichten können vom neuesten, frühesten oder einem spezifischen Offset wiedergegeben werden. Log-Komprimierung wird in KAFKA unterstützt.

6. Sprachen und Plattform

NATS

48 bekannte Client-Typen. Alle Architekturen, die GOLANG unterstützen, können NATS-Server unterstützen.

Kafka

18 bekannte Client-Typen. Kafka-Server können auf Plattformen laufen, die JVM unterstützen.

Anwendungsfälle

Anwendungsfall 1

Anforderungen

Wir haben eine Datenplattform mit einer Streaming-Pipeline. Die Plattform verwendet den Apache Flink-Engine für Echtzeit-Streaming und Apache Beam für das Schreiben der Analyse-Pipeline. Hier sind die wichtigsten Anforderungen:

1. Hohe Durchsatz- und geringe Latenznachrichtenverarbeitung
2. Unterstützung für Checkpoint und Rückdruckbehandlung
3. Nachrichten in MBs verarbeiten
4. Nachrichtenbeständigkeit und Persistenz

Vergleich

Kafka-Vorteiles:

• Hoher Durchsatz
• Datenretention mit konfigurierbaren Retentionsrichtlinien und Replikation von Daten für Fehlertoleranz
• Unterstützung für mindestens eine Nachrichtenzustellgarantie
• Nachrichten von frühesten/neuesten/spezifischen Offsets lesen
• Serverseitige ‚Acks‘ für zuverlässige Zustellung
• Massive Datenströme und große Nachrichtengröße verarbeiten
• Unterstützung für Themenkompaktierung

Kafka-Nachteile:

• Hoher Ressourcenverbrauch. Unser Cluster war vor Ort und ressourcenbeschränkt
• Kafka ist nur nahezu in Echtzeit

Vorteile von NATS:

• Hohe Leistung bei minimalem Ressourcenverbrauch. Unser Cluster ist vor Ort mit Ressourcenbeschränkungen
• Unterstützung für mindestens einmal. Wir suchten nach einer Mindest-einmal-Garantie
• Niedriglatenz-Nachrichtenverarbeitung

NATS Nachteile:

• Keine Connectoren für Flink/Beam, daher war die Integration schwierig
• Leistungsreduktion bei Nachrichtengröße

Endgültige Entscheidung

Nach sorgfältiger Analyse wurde Kafka gewählt. Wir mussten einen Kompromiss zwischen Ressourcenverbrauch und den anderen Vorteilen, die Kafka bot, eingehen, insbesondere der guten Integration mit Apache Beam und Flink. Ein weiterer Vorteil von Kafka war die Handhabung großer Nachrichtengrößen und die hochvolumige Nachrichtenverarbeitung.

Anwendungsfall 2

Anforderungen

Verarbeitung der in einem vor Ort Cluster generierten Ereignisse, z.B. Audit-Protokolle. Ereignisse sollten mit niedriger Latenz verarbeitet werden. Und Unterstützung für die Kommunikation von Microservices. Haltbarkeit und Persistenz waren keine Anforderungen. Die Nachrichtengröße war klein. Keine Notwendigkeit, Analysen zu den Ereignissen durchzuführen. Wir waren in einer eingeschränkten Umgebung. Der Ressourcenverbrauch und der Speicherbedarf sollten minimal sein.

Entscheidung

Warum NATS gewählt wurde:

• Effizienter Ressourcenverbrauch
• Niedriglatenz-Ereignisverarbeitung.
• Da es sich um eine Go-Anwendung handelt, ist der Speicherbedarf sehr gering
• Fähigkeit zur Verarbeitung kleiner Nachrichtengrößen
• Unterstützung für Anfrage-Antwort, die die Kommunikation von Microservices unterstützen kann
• Wenn JetStream nicht konfiguriert ist, werden Nachrichten nicht gespeichert

Warum Kafka nicht gewählt wurde:

• Standardmäßig werden Nachrichten auf der Festplatte gespeichert
• Ressourcenverbrauch ist im Vergleich zu NATS hoch
• Da es JVM benötigt, ist der Speicherbedarf sehr hoch

Zusammenfassung

Die Wahl zwischen Kafka und NATS hängt von Ihren spezifischen Anforderungen in drei Schlüsselbereichen ab: Architektur und Komplexität, Leistung und Skalierbarkeit sowie Nachrichtenzustellungsgarantien. Kafka eignet sich für Systeme, die robustes Event-Streaming, dauerhafte Speicherung und fortschrittliche Verarbeitungsfunktionen erfordern, ist jedoch mit höherer Komplexität verbunden. NATS hingegen ist leichtgewichtig, einfach zu verwalten und glänzt in Szenarien mit geringer Latenz und hoher Durchsatzrate bei einfacheren Messaging-Anforderungen.

Bei der Gestaltung eines verteilten Messaging-Systems sollten Sie diese Bereiche sorgfältig bewerten, um Ihre Wahl mit den Zielen und Einschränkungen Ihrer Anwendung abzustimmen. Sowohl Kafka als auch NATS sind leistungsstarke Tools, und die richtige Wahl hängt von Ihrem Anwendungsfall ab.

Zu berücksichtigende Schlüsselbereiche vor der Wahl zwischen Kafka und NATS:

1. Architektur und Komplexität
2. Hohe Verfügbarkeit und Leistung
3. Nachrichtenzustellungsgarantien

Kafka eignet sich ideal für verteilte Systeme, die Event-Streaming, dauerhaften Speicher und fortschrittliche Verarbeitungsfunktionen erfordern. Allerdings geht Kafka mit einem hohen Ressourcenverbrauch und einem großen Speicherbedarf einher. Die Managementkomplexität ist im Vergleich zu NATS sehr hoch.

Andererseits ist NATS leichtgewichtig und einfach zu verwalten. Die geringe Latenz bei der Nachrichtenverarbeitung ist eine charakteristische Fähigkeit von NATS. 

Letztendlich sind sowohl Kafka als auch NATS leistungsstarke Event-Handling-Tools. Die Wahl hängt von spezifischen Anwendungsfällen ab.