Le monde des systèmes de messageries de type publish-subscribe a vu plusieurs acteurs émerger comme Apache Kafka, Apache Pulsar, les solutions proposées par Amazon (Kinesis) et Google (PubSub), et autres. Dans cet article, nous allons nous attarder sur les deux projets open-source que sont Apache Kafka et Apache Pulsar. Ces deux systèmes se veulent distribués (donc extensible), fiables, de faible latences dans l'envoi de messages, et autres joyeuseries. Le but n'est pas que de constater les différences, mais également les similarités et équivalences qui existent entre ces deux systèmes. Sans plus tarder, voici donc un tableau faisant la comparaison entre ceux-ci.

Features Apache Kafka Apache Pulsar
Concept général Publish-subscribe, producer push et consumer pull Publish-subscribe, producer push et consumer pull
Parallélisme Topics partitionnés. Un topic possède plusieurs partitions. Une partition représente un ou plusieurs fichiers logs et index. Topics partitionés. Un topic possède plusieurs partitions représentés par le concept de ledgers et fragments d'Apache BookKeeper.
Architecture Cluster brokers Kafka + cluster ZooKeeper Cluster broker Pulsar + cluster BookKeeper + cluster ZookKeeper
Stockage Système de structure de logs distribués (à l'intérieur du cluster de brokers) Apache BookKeeper (en dehors du cluster de brokers). Tiered Storage ⇒ stockage vers aws
Geo-Réplication Kafka MirrorMaker Présent et géré au niveau des tenants. Doc Pulsar
Registre de schémas Confluent Schema Registry. Chaque message est envoyé avec un ID unique représentant un schéma Approche client ou serveur.
Retention et expiration des messages (TTL) Possède seulement le concept de rétention. 7 jours de rétention par défaut. Peut également être configuré avec une taille maximale. Possède les deux. Plus de détails ici dans la partie Acknowledgement.
Acknowledgement Géré par un topic dédié aux offsets, __consumer_offsets. Géré par les cursors, l'ack est soit cumulatif (à la Kafka), soit par message (ce dernier permet de mieux gérer les erreurs et une utilisation comme un système de queue plus traditionnelle)
Capacité de traitement et latence Grande capacité de traitement grâce aux techniques de consommation avec zéro copies. Faible latence.
Consumer Groupes de consommateurs (Voir l'article suivant sur notre blog pour plus de détail). 3 types de consommations différentes (appelés subscriptions). Possibilité d'avoir plus de consommateurs que de partitions dans une même subscription.
Topics Constitué de plusieurs partitions répartis sur plusieurs brokers. Multi-tenancy : paramétrage sur les topics pour permettre ou non la consommation/production de données dans les topics + quotas pour contrôler les ressources des brokers utilisées par les clients. Persistant ou non persistant. Constitué de plusieurs partitions répartis sur plusieurs brokers. Multi-tenancy : Pulsar est conçu pour cela. Les topics sont organisés en namespace, et chaque namespace appartient à un tenant.
Écosystème Kafka Connect, Kafka Streams Pulsar IO, Pulsar Functions
Communauté Très Mature En croissance
Production indempotente Exactly Once Effectively Once ⇒ Déduplication des messages
Headers des messages Depuis 2017 dans la 0.11.0 KIP-82 Non implémenté pour l'instant (v2.3.1)
Sécurité Authentification + Chiffrement + Autorisation via SSL + SASL (Kerberos, SCRAM-SHA-256/512) Authentification + Chiffrement via TLS. Autorisation et authentification avec Athenz ⇒ Concept de "role tokens".

Photo by Frida Bredesen on Unsplash