Qu’est-ce qu’Apache Pulsar ?

Apache Pulsar est une plateforme de messagerie distribuée et de diffusion open source et cloud native. Alors qu’Apache Kafka a longtemps été la référence en matière de transmission d’événements en continu et de traitement de données en temps réel, Apache Pulsar s’est imposé comme une alternative puissante au cours de la dernière décennie.

Face à des environnements informatiques et de données de plus en plus complexes, les entreprises s’appuient sur des plateformes de messagerie et de streaming pour assurer des échanges de données rapides et fiables entre applications, systèmes et services. L’analyse de données en temps réel devenant un facteur clé pour générer des informations exploitables, l’accélération de la diffusion en continu et du traitement des données constitue une priorité majeure. Selon les données IDC pour 2025, les entreprises interrogées estiment que dans 63 % des cas d’utilisation, les données doivent être traitées en quelques minutes pour être utiles.

Pulsar combine les fonctionnalités des systèmes de messagerie traditionnels avec celles des systèmes publication/abonnement, ce qui le rend parfaitement adapté aux cas d’utilisation tels que les microservices, la messagerie instantanée et l’intégration de données. D’innombrables fonctionnalités et avantages contribuent à la polyvalence de Pulsar, notamment la géoréplication, la multilocation et le stockage multiniveau.

Initialement développé par Yahoo et rendu open source par l’Apache Software Foundation en 2016, Apache Pulsar gère aujourd’hui des centaines de milliards d’événements par jour au sein des grandes entreprises.

Pour comprendre le rôle d’Apache Pulsar, il faut bien comprendre le fonctionnement des plateformes de messagerie et de transmission d’événements en continu.

Un message est un paquet de données que les applications créent pour être utilisé par d’autres applications. Ces paquets sont utilisés dans l’ordre dans lequel ils sont transmis, jusqu’à ce que l’application consommatrice les traite.

Les systèmes de messagerie facilitent l’échange de ces messages. Les systèmes de messagerie traditionnels sont des solutions middleware, également appelées « middleware orienté message » (MOM). Ces solutions prennent généralement en charge deux schémas de distribution des messages : la messagerie point à point et la messagerie publication/abonnement.

Avec la messagerie point à point, une application (appelée « expéditeur ») envoie un message à ce que l’on appelle une file d’attente de messages, qui se charge de le stocker. Ensuite, une autre application (appelée « destinataire » ou « consommateur ») reçoit le message de la file d’attente et le traite. Chaque message peut être consommé une seule fois.

Dans la messagerie publication/abonnement, l’application qui produit le message est appelée « éditeur ». Les applications qui l’utilisent sont appelées « abonnés ». Chaque message est publié dans une catégorie appelée « sujet », et chaque application qui s’abonne à ce sujet reçoit une copie de chaque message qui y est publié.

Les partitions et les sujets partitionnés peuvent accélérer le traitement des messages. Les messages publiés vers les sujets partitionnés sont répartis entre plusieurs courtiers.

La messagerie publication/abonnement est conçue pour une communication « un à plusieurs », de type diffusion. La messagerie point à point, comme son nom l’indique, permet l’échange d’informations entre un seul expéditeur et un seul destinataire.

Parmi les systèmes de messagerie traditionnels, RabbitMQ, une plateforme open source, figure comme étant la plus utilisée.

Une plateforme de transmission d’événements en continu capture les données en temps réel à partir d’applications, de bases de données et d’appareils IdO. Elle transporte ensuite les données vers diverses destinations à des fins de traitement immédiat, d’analyse ou de stockage.

Connues pour leur évolutivité, les plateformes de transmission d’événements en continu peuvent classer les flux d’enregistrements par sujet et les stocker pendant une durée prédéterminée. Toutefois, contrairement aux systèmes de messagerie traditionnels, les plateformes de transmission d’événements en continu ne peuvent ni garantir la remise des messages ni savoir quels consommateurs les ont reçus. Elles s’appuient sur la messagerie publication/abonnement, et non sur la distribution de messages point à point, et offrent moins de flexibilité en matière de routage.

Parmi les plateformes de transmission d’événements en continu, Apache Kafka est la plus utilisée.

Apache Pulsar combine les capacités de plateformes telles que RabbitMQ et Apache Kafka au sein d’une seule et même solution. Comme Kafka, il peut transmettre des événements en continu et envoyer des messages à de multiples consommateurs. Comme RabbitMQ, il prend en charge la mise en file d’attente et peut envoyer des messages à un seul consommateur.

Mais Pulsar est plus qu’un simple héritier de ses prédécesseurs. Développée initialement par Yahoo pour répondre à ses propres besoins organisationnels, la plateforme a intégré dès le départ certains avantages compétitifs. Depuis, d’autres améliorations ont fait de Pulsar une solution de messagerie et de streaming hautes performances.

Aujourd’hui, les fonctionnalités les plus remarquables d’Apache Pulsar sont les suivantes :

• Multilocation
• Réplication géographique
• Architecture multiniveau
• Stockage à plusieurs niveaux
• Connecteurs E/S
• Abonnements flexibles

La multilocation est l’une des fonctionnalités qui différencient Pulsar des autres plateformes depuis le début. Dans une architecture logicielle multilocataire, une seule instance de l’application logicielle (avec sa base de données et son matériel sous-jacents) sert plusieurs locataires (ou comptes utilisateurs). Parmi les avantages de la multilocation, citons la simplification des configurations (système et autres), de la maintenance et du déploiement applicatif, ainsi que la réduction des coûts.

Dans Apache Pulsar, différentes équipes peuvent partager le système de messagerie en toute sécurité. Chaque locataire a sa propre authentification, ses propres autorisations et ses propres politiques. Les locataires peuvent être divisés selon ce que l'on appelle des espaces de noms (groupes logiques de sujets). Cette division permet de gérer facilement différents environnements, tels que le développement, la mise en scène et la production, dans une infrastructure d'hébergement dédiée à un locataire unique.

La réplication des messages vers des emplacements distants est importante pour assurer la reprise après sinistre ou permettre aux applications de fonctionner à l’échelle mondiale. Contrairement à d’autres plateformes, Pulsar ne nécessite ni configuration complexe, ni modules complémentaires pour exploiter cette capacité.

Grâce à la géoréplication, les applications peuvent se connecter au cluster Pulsar local et envoyer des e-mails aux clusters dans le monde entier. Si un producteur publie un message sur un sujet dans un espace de noms répliqué, ce message est automatiquement répliqué vers le ou les emplacements distants configurés.

L’architecture Pulsar sépare les composants de la diffusion de messages (courtiers de messages) et les couches de stockage des messages. Les messages sont stockés par Apache BookKeeper, leader des solutions de stockage des journaux durables.

Pour améliorer la performance, BookKeeper répartit les données sur plusieurs serveurs appelés « bookies ». (Les métadonnées des registres BookKeeper sont stockées dans Apache ZooKeeper.) Les bookies peuvent être ajoutés selon les besoins, ce qui permet une évolutivité horizontale adaptée à la gestion des gros volumes de données. Cette architecture permet à Pulsar de fournir une faible latence, tout en transférant de grandes quantités de données en peu de temps (ce que l’on appelle un haut débit).

L’architecture de Pulsar est également considérée comme une architecture cloud native. Pulsar et le cloud computing séparent tous deux le calcul du stockage. En outre, PULSAR peut être déployé sur Kubernetes, une plateforme d’orchestration de conteneurs open source essentielle aux infrastructures cloud modernes.

Apache Pulsar propose également un stockage hiérarchisé. Cette capacité permet de déplacer les données plus anciennes du backlog d’Apache BookKeeper vers un stockage à long terme moins coûteux, tout en autorisant les clients Pulsar à accéder au backlog.

Le stockage hiérarchisé Pulsar utilise Apache jclouds (un kit d’outils multicloud open source pour la plateforme Java), afin de prendre en charge le stockage à long terme par le biais de solutions comme AWS S3 (Amazon S3), GCS (Google Cloud Storage), Azure et Aliyun.

Apache Pulsar peut être facilement utilisé avec des systèmes externes grâce aux connecteurs E/S Pulsar. Ces connecteurs font office de passerelles entre Pulsar et les autres systèmes (moteurs de traitement des flux, API de pipeline de données et autres plateformes de messagerie).

Les connecteurs Pulsar se divisent en deux types : source et sink. Les connecteurs source transmettent les données des systèmes externes à Pulsar, tandis que les connecteurs sink font l’inverse : ils transmettent les données de Pulsar aux systèmes externes. Les connecteurs Pulsar les plus utilisés sont MySQL, MongoDB, Cassandra, RabbitMQ, Kafka, Flume et Redis.

Apache Pulsar prend en charge quatre types d’abonnement différents¹ pour aider les utilisateurs à configurer leurs schémas de messagerie :

• Exclusif : un seul consommateur est autorisé à recevoir des messages dans le cadre de l’abonnement.
  
  
• Basculement : lorsque la transmission d’un message au consommateur primaire désigné échoue, les messages sont envoyés à un consommateur de secours pour être traités.
  
  
• Partagé : les messages sont distribués selon un protocole « round robin » ; plusieurs consommateurs reçoivent des messages, mais chaque message est remis à un seul consommateur.
  
  
• Partagé avec clé : les messages sont associés à une clé de message, ce qui permet de corréler les messages connexes. Les messages ayant la même clé sont envoyés aux consommateurs dans un ordre donné.

Autres fonctionnalités PULSAR notables :

Équilibrage de charge courtier : Pulsar surveille l’utilisation du processeur, de la mémoire et du réseau par les courtiers Pulsar et déplace les workloads selon les besoins, afin d’optimiser l’équilibrage et d’éviter de surcharger les courtiers.

Registre de schémas : le registre de schémas de Pulsar permet aux clients Pulsar de télécharger les schémas de données par sujet, afin de garantir que les producteurs et les consommateurs utilisent des formats de messages compatibles.

Bibliothèques clientes : les bibliothèques clientes sont des fonctions et des procédures préconfigurées pour simplifier les interactions entre les applications et les API, les bases de données et les services. Pulsar prend en charge les bibliothèques spécifiques aux langages de programmation (notamment les bibliothèques Java, C++, Python et Node.js), ainsi que les bibliothèques agnostiques (REST et WebSocket).

Conservation des messages : les systèmes traditionnels suppriment les messages une fois qu’ils ont été consommés. Pulsar permet aux utilisateurs de définir des politiques pour conserver les messages même après leur consommation, une fonctionnalité capable de prendre en charge les modèles d’architecture pilotée par les événements.

Les cas d’utilisation suivants, cités par l’Apache Software Foundation, illustrent la fonctionnalité et la polyvalence d’Apache PULSAR.²