Quand utiliser RabbitMQ plutôt que Kafka?

Question

On m'a demandé d'évaluer RabbitMQ au lieu de Kafka mais j'ai trouvé difficile de trouver une situation où une file d'attente de messages est plus appropriée que Kafka. Est-ce que quelqu'un connaît des cas d'utilisation où une file d'attente de messages convient mieux en termes de débit, de durabilité, de latence ou de facilité d'utilisation?

Answer 1

RabbitMQ est un courtier de messages solide et polyvalent qui prend en charge plusieurs protocoles tels que AMQP, MQTT, STOMP, etc. Il peut gérer un débit élevé. Un cas d'utilisation courant de RabbitMQ est de gérer des tâches d'arrière-plan ou des tâches longues, telles que la numérisation de fichiers, le redimensionnement d'images ou la conversion de PDF. RabbitMQ est également utilisé entre microservices, où il sert de moyen de communication entre applications, évitant les goulots d'étranglement en transmettant des messages.

Kafka est un bus de messages optimisé pour l'ingestion de flux de données à haut débit et la relecture. Utilisez Kafka lorsque vous avez besoin de déplacer une grande quantité de données, de traiter des données en temps réel ou d'analyser des données sur une période. En d'autres termes, là où les données doivent être collectées, stockées et traitées. Un exemple est lorsque vous souhaitez suivre l'activité des utilisateurs sur une boutique en ligne et générer des articles suggérés à acheter. Un autre exemple est l'analyse des données pour le suivi, l'ingestion, l'enregistrement ou la sécurité.

Kafka peut être vu comme un courtier de messages durable où les applications peuvent traiter et retraiter des données en flux sur le disque. Kafka a une approche de routage très simple. RabbitMQ offre de meilleures options si vous devez router vos messages de manière complexe vers vos consommateurs. Utilisez Kafka si vous avez besoin de prendre en charge des consommateurs en lots qui pourraient être hors ligne ou des consommateurs qui souhaitent recevoir des messages avec une faible latence.

Pour comprendre comment lire les données de Kafka, nous devons d'abord comprendre ses consommateurs et groupes de consommateurs. Les partitions vous permettent de paralléliser un sujet en divisant les données sur plusieurs nœuds. Chaque enregistrement dans une partition est affecté et identifié par son décalage unique. Cet décalage pointe vers l'enregistrement dans une partition. Dans la dernière version de Kafka, Kafka conserve un décalage numérique pour chaque enregistrement dans une partition. Un consommateur dans Kafka peut soit commettre automatiquement des décalages périodiquement, soit choisir de contrôler manuellement cette position engagée. RabbitMQ garde tous les états des messages consommés/acquittés/non acquittés. Je trouve Kafka plus complexe à comprendre que dans le cas de RabbitMQ, où le message est simplement supprimé de la file une fois qu'il est accusé de réception.

Les files d'attente de RabbitMQ sont les plus rapides lorsqu'elles sont vides, tandis que Kafka conserve de grandes quantités de données avec très peu de surcharge - Kafka est conçu pour contenir et distribuer de grands volumes de messages. (Si vous prévoyez d'avoir de très longues files d'attente dans RabbitMQ, vous pourriez jeter un œil aux files d'attente paresseuses.)

Kafka est conçu dès le départ avec le scaling horizontal (échelle en ajoutant plus de machines) à l'esprit, tandis que RabbitMQ est principalement conçu pour le scaling vertical (échelle en ajoutant plus de puissance).

RabbitMQ dispose d'une interface conviviale intégrée qui vous permet de surveiller et de gérer votre serveur RabbitMQ à partir d'un navigateur web. Entre autres choses, les files d'attente, les connexions, les canaux, les échanges, les utilisateurs et les autorisations d'utilisateur peuvent être gérés - créés, supprimés et répertoriés dans le navigateur et vous pouvez surveiller les taux de messages et envoyer/recevoir des messages manuellement. Kafka dispose d'un certain nombre d'outils open-source et également commerciaux, offrant les fonctionnalités d'administration et de surveillance. Je dirais qu'il est plus facile/développe plus rapidement une bonne compréhension de RabbitMQ.

En général, si vous voulez un courtier de messages pub-sub simple/traditionnel, le choix évident est RabbitMQ, car il va probablement évoluer plus que ce dont vous aurez jamais besoin. J'aurais choisi RabbitMQ si mes exigences étaient assez simples pour traiter la communication système à travers des canaux/files d'attente, et où la rétention et le streaming ne sont pas requis.

Il y a deux situations principales où je choisirais RabbitMQ ; Pour des tâches longues, lorsque j'ai besoin d'exécuter des tâches d'arrière-plan fiables. Et pour la communication et l'intégration à l'intérieur et entre les applications, c'est-à-dire comme intermédiaire entre les microservices; où un système doit simplement notifier une autre partie du système de commencer à travailler sur une tâche, comme la gestion des commandes dans une boutique en ligne (commande passée, mise à jour du statut de la commande, envoi de la commande, paiement, etc.).

En général, si vous voulez un cadre pour stocker, lire (re-lire) et analyser des données en continu, utilisez Apache Kafka. Il est idéal pour les systèmes qui sont audités ou ceux qui ont besoin de stocker des messages de manière permanente. Ceux-ci peuvent également être décomposés en deux cas d'utilisation principaux pour l'analyse de données (suivi, ingestion, journalisation, sécurité, etc.) ou le traitement en temps réel.

Vous trouverez plus de lectures, de cas d'utilisation et quelques données de comparaison ici : https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html

Je recommande également le document de l'industrie : "Kafka versus RabbitMQ : Une étude comparative de deux implémentations de référence de l'industrie sur la publication/abonnement" : http://dl.acm.org/citation.cfm?id=3093908

Je travaille dans une entreprise proposant à la fois Apache Kafka et RabbitMQ en tant que service.

Answer 2

Je réponds à cette question chaque semaine... Alors que RabbitMQ (comme IBM MQ ou JMS ou d'autres solutions de messagerie en général) est utilisé pour la messagerie traditionnelle, Apache Kafka est utilisé comme plateforme de streaming (messagerie + stockage distribué + traitement des données). Les deux sont conçus pour des cas d'utilisation différents.

Vous pouvez utiliser Kafka pour la "messagerie traditionnelle", mais pas utiliser MQ pour des scénarios spécifiques à Kafka.

L'article “Apache Kafka vs. Enterprise Service Bus (ESB)—Amis, Ennemis, ou Ennemies ? (https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/)” explique pourquoi Kafka n'est pas en concurrence mais complémentaire aux solutions d'intégration et de messagerie (y compris RabbitMQ) et comment les intégrer ensemble.

Answer 3

RabbitMQ est un courtier de messages général à usage traditionnel. Il permet aux serveurs web de répondre rapidement aux demandes et de livrer des messages à plusieurs services. Les éditeurs peuvent publier des messages et les rendre disponibles dans des files d'attente, de sorte que les consommateurs puissent les récupérer. La communication peut être asynchrone ou synchrone.

---

En revanche, Apache Kafka n'est pas juste un courtier de messages. Il a été initialement conçu et mis en œuvre par LinkedIn afin de servir de file d'attente de messages. Depuis 2011, Kafka est devenu open source et a rapidement évolué vers une plate-forme de diffusion distribuée, utilisée pour la mise en œuvre de pipelines de données en temps réel et d'applications de streaming.

Il est scalable horizontalement, tolérant aux pannes, extrêmement rapide, et est utilisé en production dans des milliers d'entreprises.

Les organisations modernes disposent de divers pipelines de données facilitant la communication entre les systèmes ou services. Les choses se compliquent un peu lorsque plusieurs services doivent communiquer en temps réel les uns avec les autres.

L'architecture devient complexe car diverses intégrations sont nécessaires pour permettre l'intercommunication de ces services. Plus précisément, pour une architecture comprenant m services sources et n services cibles, n x m intégrations distinctes doivent être écrites. De plus, chaque intégration nécessite une spécification différente, ce qui signifie qu'elle peut nécessiter un protocole différent (HTTP, TCP, JDBC, etc.) ou une représentation des données différente (binaire, Apache Avro, JSON, etc.), rendant les choses encore plus difficiles. De plus, les services sources peuvent subir une charge accrue due aux connexions, ce qui pourrait potentiellement avoir un impact sur la latence.

Apache Kafka conduit à des architectures plus simples et gérables, en déliant les pipelines de données. Kafka agit comme un système distribué à haut débit où les services sources envoient des flux de données, les rendant disponibles pour que les services cibles les récupèrent en temps réel.

De plus, de nombreuses interfaces utilisateur open source et de niveau entreprise pour la gestion des clusters Kafka sont désormais disponibles. Pour plus de détails, consultez mes articles Aperçu des outils de surveillance de l'interface utilisateur pour les clusters Apache Kafka et Pourquoi Apache Kafka ?

---

Le choix entre RabbitMQ et Kafka dépend des exigences de votre projet. En général, si vous voulez un courtier de messages pub-sub simple / traditionnel, optez pour RabbitMQ. Si vous voulez construire une architecture événementielle sur laquelle votre organisation agira en temps réel, choisissez Apache Kafka car il fournit plus de fonctionnalités pour ce type d'architecture (par exemple Kafka Streams ou ksqlDB).

Answer 4

Le redimensionnement des deux est difficile de manière tolérante aux pannes distribuées, mais je soutiendrais que c'est beaucoup plus difficile à grande échelle avec RabbitMQ. Ce n'est pas trivial de comprendre Shovel, Federation, Mirrored Msg Queues, ACK, les problèmes de mémoire, la tolérance aux pannes, etc. Sans oublier que vous aurez également des problèmes spécifiques avec Zookeeper, etc. sur Kafka, mais il y a moins d'éléments à gérer. Cela dit, vous obtenez un échange polyglotte avec RMQ que vous n'obtenez pas avec Kafka. Si vous voulez du streaming, utilisez Kafka. Si vous voulez une livraison de paquets IoT simple ou similaire à fort volume, utilisez Kafka. C'est une question de consommateurs avisés. Si vous voulez une flexibilité des messages et une fiabilité accrue avec des coûts plus élevés et éventuellement une certaine complexité, utilisez RMQ.

Answer 5

Le seul avantage auquel je pense est la fonction transactionnelle, tout le reste peut être fait en utilisant Kafka