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 :
| Feature | Apache Kafka | Apache Pulsar |
|---|---|---|
| Concept général | Publish-subscribe, producer push et consumer pull | Publish-subscribe, producer push et consumer pull |
| Parallelisme | 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 s,uivant, 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". |
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