Was ist der Unterschied zwischen Kafka und Redis OSS?
Redis OSS ist ein speicherresidenter Schlüssel-Wert-Datenspeicher, während es sich bei Apache Kafka um eine Engine zur Stream-Verarbeitung handelt. Sie können die beiden Technologien jedoch miteinander vergleichen, da Sie beide für die Erstellung eines Publish-Subscribe-Nachrichtensystems (Pub/Sub) verwenden können. In der modernen Cloud-Architektur werden Anwendungen in kleinere, unabhängige Bausteine, so genannte Services, zerlegt. Pub/Sub-Messaging bietet sofortige Ereignisbenachrichtigungen für diese verteilten Systeme. Kafka unterstützt ein Pull-basiertes System, bei dem Publisher und Subscriber eine gemeinsame Nachrichtenwarteschlange nutzen, aus der Subscriber nach Bedarf Nachrichten abrufen. Redis OSS unterstützt ein Push-basiertes System, bei dem der Publisher bei einem Ereignis Nachrichten an alle Subscriber verteilt.
So funktionieren sie: Kafka vs. Pub/Sub in Redis OSS
Apache Kafka ist eine Event-Streaming-Plattform, die es mehreren Anwendungen ermöglicht, Daten unabhängig voneinander zu streamen. Diese Anwendungen, Produzenten und Verbraucher genannt, veröffentlichen und abonnieren Informationen zu und von bestimmten Datenpartitionen, die Themen genannt werden.
Redis OSS ist als In-Memory-Datenbank konzipiert, die eine Datenübertragung mit geringer Latenz zwischen Anwendungen unterstützt. Sie speichert alle Nachrichten im RAM statt auf einer Festplatte, um die Lese- und Schreibzeit der Daten zu reduzieren. Wie bei Kafka können mehrere Verbraucher einen Stream von Redis OSS abonnieren, um Nachrichten abzurufen.
Obwohl Sie beide für Pub/Sub-Messaging verwenden können, funktionieren Kafka und Redis OSS unterschiedlich.
Kafka-Arbeitsablauf
Apache Kafka verbindet Produzenten und Verbraucher über Rechen-Cluster. Jeder Cluster besteht aus mehreren Kafka-Brokern, die sich auf verschiedenen Servern befinden.
Kafka erstellt Themen und Partitionen für diese Zwecke:
- Themen zur Gruppierung ähnlicher Daten, die zu einem bestimmten Thema gehören, z. B. E-Mail, Zahlung, Benutzer und Kauf
- Partitionen zwischen verschiedenen Brokern für Datenreplikation und Fehlertoleranz
Produzenten veröffentlichen Nachrichten an den Broker. Wenn der Broker eine Nachricht erhält, kategorisiert er die Daten in ein Thema und speichert sie in einer Partition. Verbraucher stellen eine Verbindung zum entsprechenden Thema her und extrahieren Daten aus seiner Partition.
Workflow von Redis OSS
Redis OSS wird mit einer Client-Server-Architektur als NoSQL-Datenbanksystem ausgeführt. Produzenten und Verbraucher sind lose miteinander verbunden und müssen sich beim Versenden von Nachrichten nicht kennen.
Redis OSS nutzt Schlüssel und primäre/sekundäre Knoten für folgende Zwecke:
- Schlüssel zum Gruppieren ähnlicher Nachrichten. Beispielsweise ist „E-Mail“ ein Schlüssel, der auf den Datenspeicher verweist, der nur E-Mail-Nachrichten enthält.
- Primäre/sekundäre Knoten für die Nachrichtenreplikation.
Wenn ein Produzent eine Nachricht an einen bestimmten Knoten sendet, übermittelt Redis OSS die Nachricht an alle verbundenen Subscriber, indem der Nachrichtenschlüssel überprüft wird. Der Verbraucher muss immer eine aktive Verbindung mit dem Server von Redis OSS initiieren und aufrechterhalten, um Nachrichten zu empfangen. Dies wird als Semantik der vernetzten Lieferung bezeichnet.
Nachrichtenbehandlung: Kafka vs. Pub/Sub in Redis OSS
Apache Kafka bietet Entwicklern hoch skalierbare verteilte Messaging-Systeme. Redis OSS hingegen bietet umfangreiche Datenstrukturen, die es einer Anwendung ermöglichen, Daten schnell per Push-Verfahren an mehrere Knoten zu übertragen. Beide Systeme unterscheiden sich in ihren Warteschlangenmechanismen für Nachrichten.
Nachrichtengröße
Kafka und Redis OSS funktionieren am besten, wenn sie kleine Datenpakete zwischen Verbrauchern und Subscribern senden.
Vor allem Redis OSS ist nicht dafür ausgelegt, große Datenmengen zu verarbeiten, ohne den Durchsatz zu beeinträchtigen. Außerdem können keine großen Datenmengen gespeichert werden, da RAM eine geringere Kapazität hat als ein Festplattenspeicher.
Kafka hingegen kann ziemlich große Nachrichten unterstützen, obwohl es nicht speziell dafür entwickelt wurde. Kafka kann Nachrichten bis zu 1 GB verarbeiten, wenn es die Nachricht komprimiert und Sie es für eine abgestufte Speicherung konfigurieren. Anstatt alle Nachrichten im lokalen Speicher zu speichern, verwendet es den Remote-Speicher, um die vollständigen Protokolldateien zu speichern.
Nachrichtenzustellung
Kafka-Verbraucher ziehen die Daten aus der Nachrichtenwarteschlange. Jeder Kafka-Konsument merkt sich die Nachricht, die er gelesen hat, mit einem Offset, den er aktualisiert, um die nächste Nachricht abzurufen. Die Verbraucher können doppelte Nachrichten erkennen und verfolgen.
Redis OSS hingegen sendet die Nachricht automatisch per Push-Verfahren an die verbundenen Subscriber. Subscriber von Redis OSS warten passiv auf eingehende Nachrichten, die vom Server an sie weitergeleitet werden. Da es sich um eine Konfiguration handelt, bei der Nachrichten höchstens einmal übermittelt werden, sind Subscriber von Redis OSS nicht in der Lage, doppelte Nachrichten zu erkennen.
Nachrichtenaufbewahrung
Kafka speichert Nachrichten, nachdem Verbraucher sie gelesen haben. Wenn also eine Client-Anwendung die abgerufenen Daten verliert, kann sie diese Daten erneut von der Partition anfordern, die sie abonniert hat. Durch die Einstellung der Nachrichtenaufbewahrungsrichtlinie können die Benutzer festlegen, wie lange Kafka die Daten aufbewahrt.
Redis OSS dagegen speichert keine Nachrichten, nachdem sie zugestellt wurden. Wenn keine Subscriber mit dem Stream verbunden sind, verwirft Redis OSS die Nachrichten. Verworfene Nachrichten können nicht wiederhergestellt werden, selbst wenn der Subscriber später eine Verbindung zu Redis OSS herstellt.
Fehlerbehebung
Sowohl Kafka als auch Redis OSS ermöglichen es Anwendungen, bei einer unzuverlässigen Nachrichtenübermittlung Abhilfe zu schaffen, allerdings auf unterschiedliche Weise.
Bei der Fehlerbehandlung in Redis OSS liegt das Augenmerk auf der Interaktion zwischen der Client-Anwendung und den Services von Redis OSS. Bei Redis OSS können Entwickler Umstände wie Client-Timeouts, die Überschreitung von Speicherpuffer und maximale Client-Limits beheben. Aufgrund seiner Datenbankarchitektur mit Schlüssel-Wert-Paaren kann Redis OSS im Gegensatz zu Kafka keine robuste Fehlerbehandlung für Nachrichten bereitstellen.
Kafka-Entwickler können fehlerhafte Ereignisse in einer Dead-Letter-Warteschlange speichern, sie erneut versuchen oder umleiten, um eine konsistente Nachrichtenübermittlung an Client-Anwendungen zu ermöglichen. Entwickler können die Kafka Connect-API auch verwenden, um Connector-Tasks bei bestimmten Fehlern automatisch neu zu starten.
Leistungsunterschiede: Kafka vs. Pub/Sub in Redis OSS
Insgesamt bietet Apache Kafka beim Pub/Sub-Messaging eine bessere Leistung als Redis OSS, da Kafka speziell für das Datenstreaming entwickelt wurde. Redis OSS weist verschiedene Anwendungsfälle auf, in denen Kafka nicht verwendet werden kann.
Parallelität
Parallelität ist die Fähigkeit mehrerer Verbraucher, dieselbe Nachricht gleichzeitig zu erhalten.
Redis OSS unterstützt keine Parallelität.
Andererseits ermöglicht Kafka die gleichzeitige Verteilung derselben Nachricht an mehrere Verbraucher. Normalerweise rufen Verbraucher in Kafka-Verbrauchergruppen abwechselnd neue Nachrichten von einer Partition ab. Wenn es in mehreren Verbrauchergruppen nur einen einzelnen Verbraucher gibt, werden alle Nachrichten abgerufen. Indem Sie dieses Setup und die Partitionsreplikation nutzen, können Sie jeder Nutzungsgruppe an jedem Partitionsreplikat einen Verbraucher zuweisen. Auf diese Weise können alle Verbraucher eine ähnliche Nachrichtensequenz abrufen.
Durchsatz
Der Durchsatz misst die Anzahl der Nachrichten, die jedes System pro Sekunde verarbeiten kann.
Kafka hat im Allgemeinen einen höheren Durchsatz als das Pub/Sub in Redis OSS. Kafka verarbeitet viel größere Datenmengen, da es nicht warten muss, bis jeder Subscriber die Nachricht erhält, bevor es zu einem anderen wechselt. Stattdessen speichert es aktuelle Nachrichten in einem Cache-Speicher, wodurch die Lesegeschwindigkeit optimiert wird.
Die Leistung von Kafka kann jedoch sinken, wenn die Verbraucher die Nachricht nicht schnell genug abrufen, da ungelesene Nachrichten im Cache schließlich entfernt werden. In diesem Fall müssen Verbraucher von der Festplatte lesen, was langsamer ist.
Redis OSS hingegen muss auf eine Bestätigung für jeden Verbraucher warten, was den Durchsatz bei einer größeren Zahl verbundener Knoten erheblich verringert. Eine Abhilfe ist das Senden mehrerer Anfragen mit einem Prozess, der als Pipelining bezeichnet wird, aber dies verringert die Latenzzeit bei der Nachrichtenübermittlung.
Latenz
Sowohl Kafka als auch Redis OSS eignen sich für die Datenverarbeitung mit niedriger Latenz. Redis OSS bietet eine geringere Übermittlungszeit, die im Millisekundenbereich liegt, während Kafka im Durchschnitt mehrere Zehner an Millisekunden benötigt.
In Anbetracht der Tatsache, dass Redis OSS Daten in erster Linie im RAM liest und schreibt, ist es Kafka in puncto Geschwindigkeit natürlich überlegen. Unter Umständen kann Redis OSS jedoch bei der Verarbeitung größerer Nachrichten keine extrem niedrige Latenz aufrechterhalten. In der Zwischenzeit benötigt Kafka aus Gründen der Datenpersistenz mehr Zeit, um Partitionen auf verschiedenen physischen Laufwerken zu replizieren, was die Nachrichtenübermittlungszeit zusätzlich erhöht.
Die Optimierung der Latenz für Redis OSS und Kafka ist möglich, Sie müssen dabei aber sorgsam vorgehen. Sie können beispielsweise Kafka-Nachrichten komprimieren, um die Latenzzeit zu verringern, aber Produzenten und Konsumenten brauchen mehr Zeit, um sie zu dekomprimieren.
Die Latenz in Redis OSS kann durch verschiedene Faktoren verursacht werden, darunter die Betriebsumgebung, Netzwerkvorgänge, langsame Befehle oder Forking. Um Forking-Verzögerungen zu reduzieren, empfiehlt Redis OSS, das Pub/Sub-Übermittlungssystem auf modernen EC2-Instances auszuführen, die auf einer Hardware Virtual Machine (HVM) basieren.
Fehlertoleranz
Kafka schreibt alle Daten auf die Speicherfestplatte eines führenden Brokers und repliziert sie auf verschiedenen Servern. Wenn ein Server ausfällt, rufen mehrere Subscriber die Daten von den Sicherungspartitionen ab.
Im Gegensatz zu Kafka werden bei Redis OSS die Daten nicht standardmäßig gesichert. Das entsprechende Feature muss manuell aktiviert werden. Redis OSS nutzt einen In-Memory-Datenspeicher, der beim Abschalten alle Daten verliert. Daher aktivieren Entwickler die Persistenz von Redis OSS Database (RDB), um regelmäßig Snapshots der RAM-Daten zu erfassen und auf einem Datenträger zu speichern.
Wann sollte Kafka verwendet werden im Gegensatz zu Pub/Sub in Redis OSS
Apache Kafka ist die bessere Wahl für die Entwicklung von Anwendungen, die große Datensätze streamen und eine hohe Wiederherstellbarkeit erfordern. Sie wurde ursprünglich als eine einzige verteilte Datenpipeline entwickelt, die Billionen von Nachrichten verarbeiten kann. Kafka repliziert Partitionen auf verschiedenen Servern, um Datenverlust zu verhindern, wenn ein Knoten ausfällt. Unternehmen verwenden Kafka, um die Echtzeitkommunikation zwischen Anwendungen, mobilen IoT-Geräten (Internet der Dinge) und Microservices zu unterstützen. Es ist auch die bessere Wahl für Protokollaggregation, Stream-Verarbeitung und andere Cloud-basierte Datenintegrationsaufgaben.
Redis OSS hingegen bietet eine Verteilung von Ereignissen mit extrem niedriger Latenz für Anwendungen, die eine sofortige Datenübertragung erfordern, aber geringe Datenverluste tolerieren. Redis OSS wird in der Regel als Sitzungs-Cache verwendet, um häufig abgerufene Daten zu speichern oder um dringende Nachrichten zu übermitteln. Sie eignet sich auch zum Speichern von Gaming-, E-Commerce- oder Social-Media-Daten, um ein reibungsloseres Benutzererlebnis zu ermöglichen.
Zusammenfassung der Unterschiede: Kafka vs. Redis Pub/Sub
| Apache Kafka |
Redis OSS |
|
| Nachrichtengröße |
Unterstützt eine Nachrichtengröße von bis zu 1 GB mit Komprimierung und gestaffelter Speicherung. |
Unterstützt kleinere Nachrichtengrößen. |
| Nachrichtenzustellung |
Subscriber ziehen Nachrichten aus der Warteschlange. |
Der Redis-OSS-Server sendet Nachrichten per Push-Verfahren an die verbundenen Subscriber. |
| Nachrichtenaufbewahrung |
Bewahrt Nachrichten nach dem Abruf auf. |
Bewahrt keine Nachrichten auf. |
| Fehlerbehebung |
Robuste Fehlerbehandlung auf Messaging-Ebene. Warteschlange für unlesbare Nachrichten, Wiederholungsversuch von Ereignissen und Umleitung. |
Sie müssen Redis-OSS-Ausnahmen auf Anwendungsebene mit Timeouts, Client-Limits und Speicherpufferkapazität behandeln. |
| Parallelität |
Kafka unterstützt Parallelität. Mehrere Verbraucher können dieselbe Nachricht gleichzeitig abrufen. |
Unterstützt keine Parallelität. |
| Durchsatz |
Hat aufgrund des asynchronen Lesen/Schreibens einen höheren Durchsatz. |
Niedrigerer Durchsatz, da der Redis-OSS-Server auf eine Antwort warten muss, bevor er eine Nachricht an einen anderen Subscriber sendet. |
| Latenz |
Niedrige Latenz. Etwas langsamer als Redis OSS aufgrund der standardmäßigen Datenreplikation. |
Extrem niedrige Latenz bei der Verteilung kleinerer Nachrichten. |
| Fehlertoleranz |
Sichert Partitionen automatisch auf verschiedenen Brokern. |
Wird standardmäßig nicht gesichert. Benutzer können die Persistenz von Redis OSS-manuell aktivieren. Risiko eines geringen Datenverlusts. |
Wie kann AWS Ihre Anforderungen in Sachen Kafka und Redis OSS unterstützen?
Amazon Web Services (AWS) bietet eine skalierbare und verwaltete Infrastruktur zur Unterstützung Ihrer Publish-Subscribe-(Pub/Sub)-Messaging-Anforderungen.
Verwenden Sie Amazon Managed Streaming für Apache Kafka (Amazon MSK), um große Datenmengen in Echtzeit zu erfassen und zu verarbeiten. Sie können einen Datenbus mit privatem Zugriff aufbauen, um hochverfügbare Streaming-Knoten in großem Umfang bereitzustellen. Sie können sich auch nahtlos mit anderen AWS-Services wie AWS IoT Core, Amazon Virtual Private Cloud (Amazon VPC) und Amazon Kinesis Data Analytics verbinden.
Verwenden Sie Amazon MemoryDB, um hochverfügbaren In-Memory-Speicher für Ihre Redis-OSS-Workloads bereitzustellen. Sie können Streaming-Datenfeeds mit hoher Umlaufgeschwindigkeit ausführen, um Benutzeraktivitäten aufzunehmen. Und Sie können Millionen von Anfragen pro Tag für Medien- und Unterhaltungsanwendungen unterstützen.
Anstelle von Redis OSS oder Kafka können Sie auch Amazon Simple Notification Service (Amazon SNS) verwenden, um ein System für Pub/Sub-Messaging aufzubauen. Sie können Nachrichten direkt aus Ihren Anwendungen an Kunden oder andere Anwendungen auf skalierbare und kosteneffiziente Weise senden. Amazon SNS bietet verschiedene Feature, wie z. B.:
- Push-basiertes Many-to-Many-Messaging mit hohem Durchsatz zwischen verteilten Systemen, Microservices und ereignisgesteuerten Serverless-Anwendungen.
- Verschlüsselung von Nachrichten und Schutz des Datenverkehrs.
- Fanout-Funktionen in allen AWS-Kategorien. Dazu gehören Analytik, Datenverarbeitung, Container, Datenbanken, Internet der Dinge (IoT), Machine Learning (ML), Sicherheit und Speicher.
Unternehmen Sie erste Schritte mit Pub/Sub, Redis OSS und Kafka in AWS, indem Sie noch heute ein Konto erstellen.
