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 :

FeatureApache KafkaApache Pulsar
Concept généralPublish-subscribe, producer push et consumer pullPublish-subscribe, producer push et consumer pull
ParallelismeTopics 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.
ArchitectureCluster brokers Kafka + cluster ZooKeeperCluster broker Pulsar + cluster BookKeeper + cluster ZookKeeper
StockageSystè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éplicationKafka MirrorMakerPrésent et géré au niveau des tenants. https://pulsar.apache.org/docs/en/administration-geo/
Registre de schémasConfluent Schema RegistryChaque message est envoyé avec un ID unique représentant un schémaApproche 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 /blog/articles/un-apercu-d-apache-pulsar/ dans la partie Acknowledgement.
AcknowledgementGé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 latenceGrande capacité de traitement grâce aux techniques de consommation avec zéro copies.Faible latence.
ConsumerGroupes de consommateurs(Voir l'/blog/articles/kafka-et-les-groupes-de-consommateurs/ 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.
TopicsConstitué 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èmeKafka Connect, Kafka StreamsPulsar IO, Pulsar Functions
CommunautéTrès MatureEn croissance
Production indempotentehttps://cwiki.apache.org/confluence/display/KAFKA/Idempotent+Producerhttps://streaml.io/blog/pulsar-effectively-once ⇒ Déduplication des messages
Headers des messagesDepuis 2017 dans la 0.11.0https://cwiki.apache.org/confluence/display/KAFKA/KIP-82+-+Add+Record+Headers+-+TypedNon 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".

Notes pour l'article :

Effectively once pulsar : https://fr.slideshare.net/merlimat/effectivelyonce-semantics-in-apache-pulsar & https://streaml.io/blog/pulsar-effectively-once

Chaos Testing Pulsar : https://jack-vanlightly.com/blog/2018/10/21/how-to-not-lose-messages-on-an-apache-pulsar-cluster

> We can test that by enabling the deduplication feature. When enabled, a broker stores the last sequence number of each producer in a hashtable. When it receives a lower sequence number it knows that it is a duplicate and ignores it. It stores the (producer, sequence number) per topic data in a cursor so that, in a broker fail-over, the new broker can recreate the hashtable. The hashtable is snapshotted periodically so in the event of a broker failure, the latest sequence numbers in the hashtable might be lost. This would create a window of opportunity for duplication in the event of a broker fail-over if the new broker only relied on that snapshot. To avoid that scenario the new Pulsar owner reads the last N entries from the ledger and adds them to the hashtable, thereby covering any gap induced by the fail-over.

Kafka producer idempotent : https://cwiki.apache.org/confluence/display/KAFKA/Idempotent+Producer

Com between pulsar brokers and producer/consumers : https://pulsar.apache.org/docs/en/develop-binary-protocol/

Kafka Headers : https://cwiki.apache.org/confluence/display/KAFKA/KIP-82+-+Add+Record+Headers+-+Typed