Quelle est la différence entre Kafka et Redis ?
Redis est un magasin de données clé-valeur en mémoire, tandis qu'Apache Kafka est un moteur de traitement de flux. Vous pouvez toutefois comparer les deux technologies, car vous pouvez les utiliser pour créer un système de messagerie par publication-abonnement (pub/sub). Dans l'architecture cloud moderne, les applications sont découplées en de plus petits composants indépendants appelés services. La messagerie Pub/Sub fournit des notifications d'événements instantanées pour ces systèmes distribués. Kafka prend en charge un système basé sur l'extraction dans lequel les diffuseurs de publication et les abonnés partagent une file d'attente de messages commune à partir de laquelle les abonnés extraient les messages selon leurs besoins. Redis prend en charge un système basé sur le push dans lequel le diffuseur de publication distribue des messages à tous les abonnés lorsqu'un événement se produit.
Fonctionnement : Kafka vs Redis pub/sub
Apache Kafka est une plateforme de diffusion d'événements qui permet à plusieurs applications de diffuser des données indépendamment les unes des autres. Ces applications, appelées producteurs et consommateurs, publient et des informations s'y abonnent depuis et vers certaines partitions de données appelées rubriques.
Redis est quant à lui conçu comme une base de données en mémoire qui prend en charge le transfert de données à faible latence entre les applications. Il stocke tous les messages en RAM plutôt que sur un disque dur afin de réduire le temps de lecture et d'écriture des données. Comme Kafka, plusieurs consommateurs peuvent s'abonner à un flux Redis pour récupérer des messages.
Bien que vous puissiez utiliser les deux pour la messagerie pub/sub, Kafka et Redis fonctionnent différemment.
Flux de travail Kafka
Apache Kafka connecte les producteurs et les consommateurs par le biais de clusters de calcul. Chaque cluster est composé de plusieurs agents Kafka résidant sur différents serveurs.
Kafka crée des rubriques et des partitions à ces fins :
- Des rubriques permettant de regrouper des données similaires appartenant à un sujet d'intérêt, telles que les e-mails, les paiements, les utilisateurs et les achats
- Des partitions entre différents agents pour la réplication des données et la tolérance aux pannes
Les producteurs publient des messages à l'intention de l'agent. Lorsque l'agent reçoit un message, il classe les données dans une rubrique et les stocke dans une partition. Les consommateurs se connectent à la rubrique concernée et extraient les données de sa partition.
Flux de travail Redis
Redis fonctionne avec une architecture client-serveur en tant que système de base de données NoSQL. Les producteurs et les consommateurs sont peu liés et n'ont pas besoin de se connaître pour envoyer des messages.
Redis utilise des clés et des nœuds primaires/secondaires à ces fins :
- Des clés pour regrouper des messages similaires. Par exemple, « e-mail » est une clé qui pointe vers le magasin de données qui ne contient que les messages électroniques.
- Des nœuds primaires et secondaires pour la réplication des messages.
Lorsqu'un producteur envoie un message à un nœud spécifique, Redis transmet le message à tous les abonnés connectés en vérifiant la clé du message. Le consommateur doit toujours établir et maintenir une connexion active avec le serveur Redis pour recevoir des messages. C'est ce que l'on appelle la sémantique de livraison connectée.
En savoir plus sur la messagerie par publication-abonnement »
Gestion des messages : Kafka vs Redis pub/sub
Apache Kafka fournit aux développeurs des systèmes de messagerie distribuée hautement évolutifs. De son côté, Redis offre des structures de données élaborées qui permettent à une application d'envoyer rapidement des données à plusieurs nœuds. Les deux systèmes présentent plusieurs différences dans leurs mécanismes de mise en file d'attente des messages.
Taille du message
Kafka et Redis fonctionnent mieux lorsqu'ils envoient de petits paquets de données entre les consommateurs et les abonnés.
Redis, en particulier, n'est pas conçu pour gérer de grandes quantités de données sans compromettre le débit. Il ne peut pas non plus stocker de grandes quantités de données, car la capacité de la RAM est inférieure à celle du stockage sur disque.
De son côté, Kafka peut prendre en charge des messages relativement volumineux bien qu'il n'ait pas été spécifiquement créé pour cela. Kafka peut gérer des messages jusqu'à 1 Go s'il compresse le message et si vous le configurez pour un stockage hiérarchisé. Au lieu de stocker tous les messages dans le stockage local, il utilise le stockage distant pour enregistrer les fichiers journaux complets.
Diffusion de message
Les consommateurs Kafka extraient les données de la file d'attente des messages. Chaque consommateur Kafka garde la trace du message qu'il a lu grâce à un offset, qu'il met à jour pour récupérer le message suivant. Les consommateurs peuvent détecter et suivre les messages dupliqués.
En revanche, Redis envoie automatiquement le message aux abonnés connectés. Les abonnés Redis attendent passivement les messages entrants qui leur sont adressés par le serveur. Comme il s'agit d'une configuration de livraison de type « au plus une fois », les abonnés Redis ne sont pas en mesure de détecter les messages dupliqués.
Conservation des messages
Kafka conserve les messages une fois que les consommateurs les ont lus. Ainsi, si une application cliente perd les données récupérées, elle peut demander à nouveau ces données à la partition à laquelle elle est abonnée. En définissant la politique de conservation des messages, les utilisateurs peuvent déterminer la durée pendant laquelle Kafka conserve les données.
À l'inverse, Redis ne stocke pas les messages une fois qu'ils ont été remis. Si aucun abonné n'est connecté au stream, Redis supprime les messages. Les messages supprimés ne peuvent pas être récupérés même si l'abonné se connecte ultérieurement à Redis.
Gestion des erreurs
Kafka et Redis permettent aux applications d'atténuer le manque de fiabilité de la diffusion de messages, mais ils le font différemment.
La gestion des erreurs dans Redis se concentre sur l'interaction entre l'application cliente et les services Redis. Avec Redis, les développeurs peuvent faire face à des circonstances telles que les délais d'attente des clients, le dépassement de la mémoire tampon et les limites maximales des clients. En raison de son architecture de base de données de paires clé-valeur, Redis ne peut pas fournir une gestion robuste des erreurs de message comme le fait Kafka.
Les développeurs de Kafka peuvent stocker les événements erronés dans une file d'attente de lettres mortes, les réessayer ou les rediriger pour permettre une diffusion cohérente des messages aux applications clientes. Les développeurs peuvent également utiliser l'API Kafka Connect pour redémarrer automatiquement les tâches du connecteur en cas d'erreur.
Différences de performance : Kafka vs Redis pub/sub
Dans l'ensemble, Apache Kafka surpasse Redis en matière de messagerie pub/sub, car Kafka a été spécialement conçu pour le streaming de données. Redis a plusieurs cas d'utilisation différents dans lesquels Kafka ne peut pas être utilisé.
Parallélisme
Le parallélisme est la capacité de plusieurs consommateurs à recevoir le même message simultanément.
Redis ne prend pas en charge le parallélisme.
D'autre part, Kafka permet de distribuer le même message à plusieurs consommateurs simultanément. En général, les utilisateurs des groupes de consommateurs de Kafka récupèrent à tour de rôle les nouveaux messages d'une partition. S'il n'y a qu'un seul consommateur dans plusieurs groupes de consommateurs, il récupère tous les messages. En tirant parti de cette configuration et de cette réplication de partition, vous pouvez affecter un consommateur à chaque groupe de consommateurs lors de chaque réplique de partition. Cela permet à tous les consommateurs de récupérer une séquence de messages similaire.
Débit
Le débit mesure le nombre de messages que chaque système peut traiter par seconde.
Kafka a généralement un débit supérieur à celui de Redis pub/sub. Kafka gère des volumes de données beaucoup plus importants, car il n'a pas à attendre que chaque abonné reçoive le message avant de passer à un autre. Au lieu de cela, il stocke les messages actuels dans un cache mémoire et un stockage, ce qui optimise la vitesse de lecture.
Cependant, les performances de Kafka peuvent diminuer si les utilisateurs ne récupèrent pas le message assez rapidement, car les messages non lus du cache sont finalement supprimés. Dans ce cas, les utilisateurs doivent lire à partir du disque, ce qui est plus lent.
De son côté, Redis doit attendre un accusé de réception pour chaque consommateur, ce qui réduit considérablement son débit avec l'augmentation du nombre de nœuds connectés. Une solution consiste à envoyer plusieurs requêtes à l'aide d'un processus appelé pipelining, mais cela réduit la latence de messagerie.
Latence
Kafka et Redis conviennent tous deux au traitement de données à faible latence. Redis offre un temps de messagerie plus court, exprimé en millisecondes, tandis que Kafka se chiffre en moyenne à des dizaines de millisecondes.
Étant donné que Redis lit et écrit des données principalement en RAM, il devance naturellement Kafka en termes de vitesse. Cependant, Redis peut ne pas maintenir des opérations de données à très faible latence lorsqu'il gère des messages plus volumineux. Dans le même temps, Kafka a besoin de plus de temps pour répliquer les partitions sur différents disques physiques afin de garantir la persistance des données, ce qui accroît le temps de livraison des messages.
L'optimisation de la latence pour Redis et Kafka est possible, mais elle doit être effectuée avec précaution. Par exemple, vous pouvez compresser les messages Kafka pour réduire la latence, mais les producteurs et les consommateurs ont alors besoin de plus de temps pour les décompresser.
La latence dans Redis peut être due à plusieurs facteurs, notamment l'environnement d'exploitation, les opérations réseau, la lenteur des commandes ou la subdivision (forking). Pour réduire les délais de subdivision, Redis recommande d'exécuter le système de distribution pub/sub sur des instances EC2 modernes basées sur une machine virtuelle matérielle (HVM).
Tolérance aux pannes
Kafka écrit toutes les données sur le disque de stockage d'un agent de premier plan et les réplique sur différents serveurs. Lorsqu'un serveur tombe en panne, plusieurs abonnés récupèrent les données des partitions de sauvegarde.
Contrairement à Kafka, Redis ne sauvegarde pas les données par défaut et les utilisateurs doivent activer cette fonctionnalité manuellement. Redis utilise un magasin de données en mémoire, qui perd la totalité des données lorsqu'il est mis hors tension. Pour éviter cela, les développeurs activent la persistance de la base de données Redis (RDB) pour capturer périodiquement des instantanés des données RAM et les stocker sur disque.
Utilisation : Kafka vs Redis pub/sub
Apache Kafka est le meilleur choix pour créer des applications qui diffusent de jeux de données et nécessitent une capacité de restauration élevée. Il a été initialement développé comme un pipeline de données distribué unique capable de traiter des billions de messages. Kafka réplique les partitions sur différents serveurs pour éviter la perte de données en cas de défaillance d'un nœud. Les organisations utilisent Kafka pour prendre en charge la communication en temps réel entre les applications, les appareils mobiles de l'Internet des objets (IoT) et les microservices. C'est également le meilleur choix pour l'agrégation de journaux, le traitement des flux et d'autres tâches d'intégration de données basées sur le cloud.
Redis fournit quant à lui une distribution d'événements à très faible latence pour les applications qui nécessitent un transfert de données instantané, mais tolèrent de faibles pertes de données. Redis est couramment utilisé comme cache de session pour stocker les données fréquemment consultées ou envoyer des messages urgents. Il convient également au stockage de données de jeux, de commerce électronique ou de réseaux sociaux afin de permettre une expérience utilisateur plus fluide.
Résumé des différences : Kafka vs Redis pub/sub
| Apache Kafka |
Redis |
|
| Taille du message |
Supporte une taille de message allant jusqu'à 1 Go avec compression et stockage hiérarchisé. |
Supporte une taille de message plus petite. |
| Diffusion de message |
Les abonnés extraient les messages de la file d'attente. |
Le serveur Redis envoie des messages aux abonnés connectés. |
| Conservation des messages |
Conserve les messages après leur extraction. |
Ne conserve pas les messages. |
| Gestion des erreurs |
Gestion robuste des erreurs au niveau de la messagerie. File d'attente de lettres mortes, nouvelle tentative d'événement et redirection. |
Vous devez gérer les exceptions Redis au niveau de l'application avec les délais d'attente, les limites du client et la capacité de la mémoire tampon. |
| Parallélisme |
Kafka prend en charge le parallélisme. Plusieurs consommateurs peuvent récupérer le même message simultanément. |
Ne prend pas en charge le parallélisme. |
| Débit |
Débit plus élevé grâce à une lecture/écriture asynchrone. |
Débit plus faible dû au fait que le serveur Redis doit attendre une réponse avant d'envoyer un message à un autre abonné. |
| Latence |
Faible latence. Légèrement plus lent que Redis en raison de la réplication des données par défaut. |
Très faible latence lors de la distribution de messages de petite taille. |
| Tolérance aux pannes |
Sauvegarde automatiquement les partitions auprès de différents agents. |
Ne sauvegarde pas par défaut. Les utilisateurs peuvent activer la persistance Redis manuellement. Risque de petite perte de données. |
Que peut apporter AWS pour répondre à vos besoins en matière de Kafka et de Redis ?
Amazon Web Services (AWS) fournit une infrastructure évolutive et gérée pour répondre à vos besoins de messagerie par publication-abonnement (pub/sub).
Utilisez Amazon Managed Streaming for Apache Kafka (Amazon MSK) pour ingérer et traiter facilement de gros volumes de données en temps réel. Vous pouvez créer un bus de données à accès privé pour fournir des nœuds de streaming à haute disponibilité à grande échelle. Vous pouvez également vous connecter de manière fluide à d'autres services AWS comme AWS IoT Core, Virtual Private Cloud (VPC) Amazon et service géré Amazon pour Apache Flink.
Utilisez Amazon MemoryDB afin de fournir un stockage en mémoire à haute disponibilité pour vos charges de travail Redis. Vous pouvez exécuter des flux de données en streaming à haute simultanéité pour ingérer l'activité des utilisateurs. Et vous pouvez répondre à des millions de requêtes par jour pour des applications multimédia et de divertissement.
Au lieu de Redis ou Kafka, vous pouvez également utiliser Amazon Simple Notification Service (Amazon SNS) pour créer un système de messagerie pub/sub. Vous pouvez envoyer des messages depuis vos applications aux clients ou à d'autres applications de manière évolutive et rentable. Amazon SNS propose plusieurs fonctionnalités, telles que :
- Messagerie à haut débit de type « many-to-many », basée sur le push, entre des systèmes distribués, des microservices et des applications sans serveur orientées événements.
- Chiffrement des messages et confidentialité du trafic.
- Fonctionnalités de diffusion en éventail dans les différentes catégories AWS. Cela inclut l'analyse, le calcul, les conteneurs, les bases de données, l'Internet des objets (IoT), le machine learning (ML), la sécurité et le stockage.
Commencez à utiliser la messagerie pub/sub, Redis et Kafka sur AWS en créant un compte dès aujourd'hui.
