Was ist der Unterschied zwischen Kafka und Redis?
Redis ist ein In-Memory-Schlüsselwert-Datenspeicher, während Apache Kafka eine Stream-Verarbeitungs-Engine ist. 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 unterstützt ein Push-basiertes System, bei dem der Publisher Nachrichten an alle Subscriber verteilt, wenn ein Ereignis eintritt.
So funktionieren sie: Kafka vs. Redis Pub/Sub
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 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 Redis-Stream abonnieren, um Nachrichten abzurufen.
Obwohl Sie beide für Pub/Sub-Messaging verwenden können, funktionieren Kafka und Redis 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.
Redis-Arbeitsablauf
Redis läuft mit einer Client-Server-Architektur als NoSQL-Datenbanksystem. Produzenten und Verbraucher sind lose miteinander verbunden und müssen sich beim Versenden von Nachrichten nicht kennen.
Redis verwendet Schlüssel und primär-sekundäre Knoten für diese 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 die Nachricht an alle verbundenen Subscriber, indem der Nachrichtenschlüssel überprüft wird. Der Verbraucher muss immer eine aktive Verbindung mit dem Redis-Server initiieren und aufrechterhalten, um Nachrichten zu empfangen. Dies wird als Semantik der vernetzten Lieferung bezeichnet.
Nachrichtenbehandlung: Kafka vs. Redis Pub/Sub
Apache Kafka bietet Entwicklern hoch skalierbare verteilte Messaging-Systeme. Redis bietet hier umfangreiche Datenstrukturen, die es einer Anwendung ermöglichen, Daten schnell auf mehrere Knoten zu übertragen. Beide Systeme unterscheiden sich in ihren Warteschlangenmechanismen für Nachrichten.
Nachrichtengröße
Kafka und Redis funktionieren am besten, wenn sie kleine Datenpakete zwischen Konsumenten und Subscriber senden.
Vor allem Redis 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.
Andererseits sendet Redis die Nachricht automatisch an die verbundenen Subscriber. Redis-Subscriber warten passiv auf eingehende Nachrichten, die vom Server an sie geleitet werden. Da es sich um ein Most-Once-Versand-Setup handelt, sind Redis-Subscriber 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.
Umgekehrt speichert Redis keine Nachrichten, nachdem sie zugestellt wurden. Wenn keine Subscriber mit dem Stream verbunden sind, verwirft Redis die Nachrichten. Verworfene Nachrichten können nicht wiederhergestellt werden, auch wenn der Subscriber später eine Verbindung zu Redis herstellt.
Fehlerbehebung
Sowohl Kafka als auch Redis ermöglichen es Anwendungen, eine unzuverlässige Nachrichtenübermittlung abzumildern, allerdings auf unterschiedliche Weise.
Die Fehlerbehandlung in Redis konzentriert sich auf die Interaktion zwischen der Client-Anwendung und den Redis-Diensten. Mit Redis können Entwickler Umstände wie Client-Zeitüberschreitungen, überschrittener Speicherpuffer und maximale Client-Grenzwerte berücksichtigen. Aufgrund seiner Schlüssel-Wert-Paar-Datenbankarchitektur kann Redis keine robuste Behandlung von Nachrichtenfehlern wie Kafka 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. Redis Pub/Sub
Insgesamt übertrifft Apache Kafka Redis beim Pub/Sub-Messaging, da Kafka speziell für das Datenstreaming entwickelt wurde. Redis hat verschiedene Anwendungsfälle, in denen Kafka nicht verwendet werden kann.
Parallelität
Parallelität ist die Fähigkeit mehrerer Verbraucher, dieselbe Nachricht gleichzeitig zu erhalten.
Redis 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 Redis Pub/Sub. 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.
In der Zwischenzeit muss Redis auf eine Bestätigung für jeden Verbraucher warten, was den Durchsatz bei mehr angeschlossenen 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 eignen sich für die Datenverarbeitung mit niedriger Latenz. Redis bietet eine geringere Übermittlungszeit, die im Millisekundenbereich liegt, während Kafka im Durchschnitt einige zehn Millisekunden benötigt.
In Anbetracht der Tatsache, dass Redis Daten in erster Linie im RAM liest und schreibt, ist es Kafka in puncto Geschwindigkeit natürlich überlegen. Es kann jedoch sein, dass Redis bei der Verarbeitung größerer Nachrichten keine extrem niedrige Latenzzeit aufweist. 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 Latenzzeit für Redis und Kafka ist möglich, muss aber sorgfältig durchgeführt werden. 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 kann durch verschiedene Faktoren verursacht werden, darunter die Betriebsumgebung, Netzwerkoperationen, langsame Befehle oder Forking. Um Forking-Verzögerungen zu reduzieren, empfiehlt Redis, das Pub/Sub-Delivery-System 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 die Daten nicht standardmäßig gesichert, sondern die Benutzer müssen dieses Feature manuell aktivieren. Redis verwendet einen In-Memory-Datenspeicher, der beim Abschalten alle Daten verliert. Um dies zu verhindern, aktivieren Entwickler die Redis-Datenbankpersistenz (RDB), um regelmäßig Schnappschüsse der RAM-Daten zu erfassen und auf der Festplatte zu speichern.
Wann sollte Kafka verwendet werden im Gegensatz zu Redis Pub/Sub
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.
In der Zwischenzeit bietet Redis eine Ereignisverteilung mit extrem niedriger Latenz für Anwendungen, die eine sofortige Datenübertragung erfordern, aber geringe Datenverluste tolerieren. Redis wird in der Regel als Sitzungs-Cache verwendet, um Daten zu speichern, auf die häufig zugegriffen wird, 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 |
|
| 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-Server sendet Nachrichten an die angeschlossenen 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-Ausnahmen auf Anwendungsebene mit Zeitüberschreitungen, Client-Grenzwerten 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-Server auf eine Antwort warten muss, bevor er eine Nachricht an einen anderen Subscriber sendet. |
| Latenz |
Niedrige Latenz. Etwas langsamer als Redis 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 Redis-Persistenz manuell aktivieren. Risiko eines geringen Datenverlusts. |
Wie kann AWS Ihre Kafka- und Redis-Anforderungen 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 für Redis, um hochverfügbaren In-Memory-Speicher für Ihre Redis-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 oder Kafka können Sie auch Amazon Simple Notification Service (Amazon SNS) verwenden, um ein Pub/Sub-Messaging-System 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.
Beginnen Sie mit Pub/Sub, Redis und Kafka in AWS, indem Sie noch heute ein Konto erstellen.
