In verteilten Systemen und sind Message Broker unverzichtbar. Sie ermöglichen Kommunikation, entkoppeln Dienste und verbessern Zuverlässigkeit und Skalierbarkeit. Moderne Architekturen sind stark von Message Brokern abhängig, was sie zu einer Schlüsselkomponente in vielen Designmustern macht. Microservices asynchrone Kafka und RabbitMQ sind zwei der beliebtesten Message Broker. Sie sind für ihre Zuverlässigkeit, Effizienz und Anpassungsfähigkeit bekannt und verfügen über hervorragende Dokumentation, Support und Communities. RabbitMQ ist eine kostenlose Open-Source-Lösung mit Doppellizenz unter der Apache License 2.0 und der Mozilla Public License 2. Sie können es nach Bedarf verwenden und ändern. Es fungiert als reiner Nachrichtenbroker, unterstützt mehrere Protokolle und bietet zusätzliche Funktionen. Kafka, ebenfalls Open Source unter der Apache 2.0-Lizenz, ist mehr als nur ein Nachrichtenbroker; es ist eine verteilte Event-Streaming-Plattform. Es bietet erweiterte Funktionen, darunter Kafka Streams. Beim Vergleich von RabbitMQ und Kafka gibt es keine „bessere“ Lösung; es geht darum, die beste Lösung für Ihre Architektur und Ziele zu finden. Dieser Artikel führt Sie durch die wichtigsten Funktionen und Merkmale und vergleicht die beiden direkt. Er soll Ihnen ein umfassendes Verständnis der Unterschiede zwischen Kafka und RabbitMQ vermitteln und Ihnen dabei helfen, eine fundierte Entscheidung basierend auf Ihrem spezifischen Problem und Ihren Anforderungen zu treffen. Unterstützte Protokolle RabbitMQ unterstützt verschiedene Protokolle wie: ist ein leichtes Protokoll für Netzwerke mit begrenzter Bandbreite und hoher Latenz, wie sie beispielsweise im Internet der Dinge (IoT) vorkommen. Ursprünglich wurde es zur Überwachung von Ölpipelines entwickelt und wird heute häufig als Pub-Sub-Messaging-Protokoll verwendet. MQTT (MQ Telemetry Transport) ist ein einfaches, leichtes textbasiertes Protokoll für Messaging-Integrationen, das sich gut für die Verwendung über WebSocket und das Web eignet. STOMP (Simple Text Oriented Messaging Protocol) ist das primäre Protokoll für RabbitMQ und beschreibt verschiedene Routing-Optionen. Obwohl RabbitMQ über Plugins andere Protokolle unterstützen kann, ist AMQP sein Kernprotokoll. AMQP (Advanced Message Queuing Protocol) Kafka hingegen verwendet sein binäres TCP-basiertes Protokoll, das für hohen Durchsatz optimiert ist und auf einer „Nachrichtensatz“-Abstraktion basiert. Diese Abstraktion ermöglicht es Netzwerkanforderungen, Nachrichten zu gruppieren, wodurch der Overhead von Netzwerk-Roundtrips durch das Senden von Batches anstelle einzelner Nachrichten reduziert wird. Das benutzerdefinierte Protokoll von Kafka ermöglicht Flexibilität bei der Entwicklung und Optimierung für Szenarien mit hoher Auslastung. Das benutzerdefinierte Protokoll hat jedoch auch Nachteile. Es isoliert Kafka von anderen Nachrichtenbrokern, was zu mangelnder Interoperabilität führt. Im Gegensatz zu RabbitMQ, das mit jedem AMQP-Client kompatibel ist, erfordert Kafka die Verwendung von Kafka-Clients. Aufgrund der Popularität von Kafka und der Bemühungen der Community sind Kafka-Clients jedoch für viele Programmiersprachen verfügbar. Routenplanung Der Routing-Ansatz in RabbitMQ und Kafka unterscheidet sich erheblich. RabbitMQ-Routing Die Hauptkomponenten des RabbitMQ-Routings: Produzent. Eine Anwendung, die Nachrichten generiert und an RabbitMQ sendet. Exchange. Empfängt Nachrichten vom Produzenten und leitet sie an eine oder mehrere Warteschlangen weiter. Warteschlange. Speichert Nachrichten. Verbraucher. Eine Anwendung, die eine Warteschlange abonniert und Nachrichten von ihr empfängt. , und jeder Verbraucher erhält Nachrichten nur von einer Warteschlange. RabbitMQ sendet Nachrichten an den Verbraucher Bevor wir uns mit Börsen befassen, sollten wir zwei weitere Konzepte klären: Eine Regel beschreibt, wie Nachrichten vom Exchange an eine Warteschlange weitergeleitet werden. Normalerweise bindet ein Consumer eine Warteschlange beim Erstellen an einen bestimmten Exchange. Bindung. In RabbitMQ kann der Produzent die Warteschlange für eine Nachricht nicht direkt angeben. Der Exchange leitet Nachrichten basierend auf dem vom Produzenten bereitgestellten Routing-Schlüssel weiter, der aus einer oder mehreren durch Punkte getrennten Zeichenfolgen besteht. Routing-Schlüssel. Es gibt vier Arten von Austausch: Standardmäßig. Leitet Nachrichten unter Verwendung des Warteschlangennamens aus dem Routing-Schlüssel direkt an eine Warteschlange weiter. Fanout. Sendet Nachrichten an alle gebundenen Warteschlangen und ignoriert dabei den Routing-Schlüssel. Direkt. Leitet Nachrichten an Warteschlangen weiter, basierend auf genauen Übereinstimmungen zwischen dem Routing-Schlüssel und dem von der Warteschlange bereitgestellten Bindungsschlüssel. Thema. Ermöglicht komplexe Routing-Regeln basierend auf dem Mustervergleich des Routing-Schlüssels und unterstützt Platzhalterzeichen: * (Stern) entspricht genau einem Wort. #(Hash) passt zu null oder mehr Wörtern. Beispielsweise würde eine mit dem Routing-Schlüssel gebundene Warteschlange Nachrichten mit Schlüsseln wie oder empfangen. Eine mit gebundene Warteschlange würde Nachrichten mit Schlüsseln wie oder „apple.*.banana“ „apple.orange.banana“ „apple.strawberry.banana“ #.banana „apple.banana“ „apple.orange.banana“ empfangen. Kafka Das Routing von Kafka ist einfacher. Die Hauptkomponenten sind: Produzent. Ähnlich wie RabbitMQ sendet es Nachrichten an ein Thema. Thema. Speichert Nachrichten. Produzenten geben das Thema an, an das sie Nachrichten senden. Partitionen. Jedes Thema ist in Partitionen unterteilt, die den physischen Speicher von Nachrichten darstellen. Produzenten können einen Schlüssel zum Weiterleiten von Nachrichten angeben und so sicherstellen, dass alle Nachrichten mit demselben Schlüssel zur selben Partition gehören. Verbraucher. Im Gegensatz zu RabbitMQ-Verbrauchern . Sie können jeweils nur Nachrichten aus einem Thema lesen. ziehen Kafka-Verbraucher Nachrichten aus Themen Im Vergleich zu RabbitMQ sind die Routing-Fähigkeiten von Kafka eingeschränkt. Es ist nicht für granulares Routing, sondern für hohe Leistung und Skalierung ausgelegt. Eine wichtige Anmerkung hierzu: Wenn ein Verbraucher Verbrauchergruppe ist eine Kafka-Abstraktion, die es mehreren Verbrauchern ermöglicht, unabhängig voneinander aus demselben Thema zu lesen, wodurch sichergestellt wird, dass jede Verbrauchergruppe alle Themennachrichten verarbeitet. in RabbitMQ eine Nachricht aus einer Warteschlange empfängt, „stiehlt“ er sie. Bei erfolgreicher Bestätigung erhalten andere Verbraucher die Nachricht nicht. Kafka-Verbraucher verhalten sich gleich, wenn sie sich in derselben Verbrauchergruppe befinden. Beständigkeit und Haltbarkeit In RabbitMQ sind Haltbarkeit und Beständigkeit eindeutige Merkmale: Dauerhaftigkeit. Dies ist eine Eigenschaft von Warteschlangen und Exchanges. Es gibt zwei Arten von Warteschlangen: dauerhafte und vorübergehende. Eine dauerhafte Warteschlange (oder Exchange) speichert ihre Metadaten auf der Festplatte und kann einen Neustart des Brokers überstehen. Bei vorübergehenden Warteschlangen ist dies nicht der Fall. Persistenz. Eine dauerhafte Warteschlange garantiert keine Nachrichtenbeständigkeit. Um sie dauerhaft zu machen, müssen Sie die Persistenz konfigurieren. Wenn der Herausgeber eine Nachricht sendet, kann er die Persistenzeigenschaft angeben. In diesem Fall wird eine Nachricht im internen Festplattenspeicher gespeichert und ist nach dem Neustart des Brokers verfügbar. Kafka speichert alles auf einer Festplatte. Im Gegensatz zu RabbitMQ, das Nachrichten nach der Bestätigung durch den Verbraucher löscht, behält Kafka alle Nachrichten, bis sie eine bestimmte Lebensdauer (TTL) oder Festplattengrößenbeschränkung erreichen. Es ermöglicht die erneute Verarbeitung von Nachrichten durch verschiedene oder dieselbe Verbrauchergruppe. Skalierbarkeit Sowohl RabbitMQ als auch Kafka unterstützen Clustering, bei dem mehrere Broker zusammenarbeiten. In RabbitMQ verbessert Clustering die Verfügbarkeit und gewährleistet Datensicherheit. Wenn es um Leistung geht, ist vertikale Skalierung eine bevorzugte Methode, um Ihr RabbitMQ zu verbessern. Horizontale Skalierung kann einen erheblichen Synchronisierungsaufwand verursachen. Normalerweise bevorzugen Sie einen 3-Broker-Cluster, um die Verfügbarkeit sicherzustellen, falls ein Broker ausfällt. RabbitMQ unterstützt standardmäßig keine Warteschlangenpartitionierung, es ist jedoch erwähnenswert, dass es , das Ihnen bei der Skalierung und gleichmäßigen Lastverteilung im Cluster helfen kann. ein konsistentes Hash-Austausch-Plugin Kafka lässt sich effizient skalieren. Es sorgt nicht nur für Verfügbarkeit und Datensicherheit, sondern verbessert auch den Durchsatz der Datenverarbeitung. Das Schlüsselkonzept hierbei ist die Partitionierung. Jedes Thema hat eine konfigurierbare Anzahl von Partitionen. Jede Partition arbeitet isoliert von den anderen und fungiert als physischer Datenspeicher und -verarbeiter. Sie können jede Partition im gesamten Cluster replizieren, was Fehlertoleranz gewährleistet. Produzenten und Konsumenten arbeiten nur mit der Hauptpartition (oder Primärpartition). Wenn der Broker mit dieser Partition ausfällt, wählt das System eine neue Primärpartition aus den Replikaten aus. Die Wahl der richtigen Anzahl von Partitionen ist entscheidend. Eine große Anzahl von Partitionen verlangsamt die Systemwiederherstellung im Falle eines Knotenausfalls. Umgekehrt begrenzt sie den Durchsatz und den Grad der Parallelität für die Verbrauchergruppe. Innerhalb einer Verbrauchergruppe kann jede Partition nur mit einem Verbraucher arbeiten (was effektiv einem Thread in Ihrer Anwendung entspricht). Daher wäre es sinnlos, drei Partitionen zu haben oder mehr als drei Verbraucher, da der Rest inaktiv wäre. Bestellung RabbitMQ garantiert die Sortierung innerhalb einer einzelnen Warteschlange. Ein Verbraucher verarbeitet Nachrichten der Reihe nach. Bei mehreren Verbrauchern ändert sich die Situation jedoch. Wenn ein Verbraucher ausfällt, gibt das System die unbestätigten Nachrichten an die Warteschlange zurück, aber der nächste Verbraucher verarbeitet möglicherweise bereits den nächsten Stapel. Welche Optionen gibt es also? Verwenden Sie Kafka! Kafka garantiert die Sortierung innerhalb einer Partition (dies ist intuitiv, da es mit jeweils einer Partition arbeiten kann). Kafka garantiert jedoch keine Sortierung für das gesamte Thema. Normalerweise ist es wichtig, die Sortierung innerhalb einer Kunden-ID oder Zahlungs-ID beizubehalten. Wenn der Produzent also den richtigen Partitionsschlüssel verwendet, können Sie eine genaue Sortierung für Ihr System erreichen. Verwenden . Mit der Option „Single-Active Consumer“ wird RabbitMQ in Kafka umgewandelt. Sie erhalten „Partitionen“ und stellen sicher, dass nur ein Verbraucher mit jeder Partition arbeiten kann. das konsistente Hash-Austausch-Plugin Liefergarantien RabbitMQ und Kafka bieten eine „mindestens einmalige“ Zustellungsgarantie. Dies bedeutet, dass Duplikate möglich sind, Nachrichten jedoch mindestens einmal vollständig verarbeitet werden. Kafka verfügt über weitere Bereitstellungsfunktionen: Idempotenter Produzent. In Kafka können Sie Ihren Produzenten so konfigurieren, dass doppelte Nachrichten ersetzt werden. RabbitMQ Producer kann Duplikate an die Warteschlange senden. Genau einmalige Zustellung innerhalb der Kafka-Verarbeitung. Genau einmal – ist die stärkste Garantie. Es stellt sicher, dass jede Nachricht nur einmal verarbeitet wird, nicht mehr und nicht weniger. In Kafka können Sie dies mit einer Kafka-Transaktion erreichen: wenn Sie von einem Kafka-Thema konsumieren und in ein anderes Kafka-Thema schreiben. Zusätzliche Merkmale Wie bereits erwähnt, bietet Kafka durch den Verzicht auf Routing-Flexibilität im Gegenzug leistungsstarke Funktionen. Kafka bietet leistungsstarke Bibliotheken zur Streaming-Verarbeitung: Kafka Streams. Ermöglicht Echtzeit-Datenverarbeitung und -Transformationen innerhalb von Kafka. KSQL. Bietet eine SQL-ähnliche Schnittstelle zum Abfragen und Transformieren von Streaming-Daten und erstellt dauerhafte Tabellenabstraktionen, die von Kafka-Themen unterstützt werden. Mit Kafka Streams können Sie Zeitaggregationen für Ihr Thema durchführen und die Ergebnisse an ein anderes Thema oder eine andere Datenbank übertragen. Stellen Sie sich vor, Sie haben ein Thema mit Wechselkursen für verschiedene Währungspaare und möchten Daten eines Open-High-Low-Close-Charts (auch OHLC) innerhalb von Zeiträumen (5 Minuten, 30 Minuten, 1 Stunde usw.) aggregieren. Eine Möglichkeit besteht darin, Daten in einer Zeitreihendatenbank zu speichern, die für eine solche Verarbeitung geeignet ist. Das brauchen Sie jedoch nicht, wenn Sie Kafka haben. Mithilfe einfacher Kafka Stream-Aggregationen können Sie OHLC-Daten auf einem Kafka-Thema berechnen und die Ergebnisse zur weiteren Abfrage in eine beliebige Datenbank einfügen. Kafka ermöglicht es Ihnen auch, verarbeitete Nachrichten als Tabelle darzustellen. Es legt Aggregationsergebnisse in einer Tabellenabstraktion ab, auf die Sie über KSQL zugreifen können. Ein solcher Tabellenstatus ist dauerhaft. Wenn ein Broker neu gestartet wird, stellt er den neuesten Status aus dem entsprechenden Thema wieder her. Wie wir sehen, geht Kafka über die grundlegende Message-Broker-Funktionalität hinaus und betritt den Bereich der Echtzeitverarbeitung und ETLs. Abschluss Sowohl Kafka als auch RabbitMQ sind hervorragende Tools für Szenarien mit hohem Durchsatz und geringer Latenz. Die Wahl hängt von den Besonderheiten des Anwendungsfalls, der Architektur und den zukünftigen Anforderungen ab. Beispielsweise ist Kafka ideal für die langfristige Speicherung von Transaktionsereignissen, während RabbitMQ in Szenarien hervorsticht, die Protokollkompatibilität und Routingflexibilität erfordern. Wenn sowohl RabbitMQ als auch Kafka geeignet sind, berücksichtigen Sie Ihre zukünftigen Anforderungen.
