Difference between revisions of "VT2020-Apache Pulsar-Fiche"

From air
Jump to navigation Jump to search
 
(4 intermediate revisions by one other user not shown)
Line 11: Line 11:
   
 
Pulsar est un système de messagerie distribué, cela veut donc dire que :
 
Pulsar est un système de messagerie distribué, cela veut donc dire que :
- [[Les données répliquées et enregistrées sur le disque.]]
+
- Les données répliquées et enregistrées sur le disque.
- [[La présence d'une réplique géographique des données]]
+
- La présence d'une réplique géographique des données
- [[Une garantit d'ordre des messages]]
+
- Une garantit d'ordre des messages
- [[La fonction de Multi-Entités]]
+
- La fonction de Multi-Entités
- [[Un fort débit]]
+
- Un fort débit
 
   
 
=== Concept et architecture ===
 
=== Concept et architecture ===
Line 23: Line 22:
 
Chaque Broker héberge Topic.
 
Chaque Broker héberge Topic.
 
Les Brokers représentent le point de contact entre les consommateurs et les producteurs, c'est là où vont être hégergés les topics. C'est là ou l'on trouve la première difference entre Apache Pulsar et Apache Kafka, contrairement à Kafka, les Brokers ne stockent pas les informations des messages.
 
Les Brokers représentent le point de contact entre les consommateurs et les producteurs, c'est là où vont être hégergés les topics. C'est là ou l'on trouve la première difference entre Apache Pulsar et Apache Kafka, contrairement à Kafka, les Brokers ne stockent pas les informations des messages.
[[File:CA.jpg]]
+
[[File:CA.png]]
   
 
=== Architecture des stockages et des gestions ===
 
=== Architecture des stockages et des gestions ===
Line 36: Line 35:
   
 
Quant au stockage des méta données, cela se passe au niveau des Servers qui sont générés par Apache ZooKeeper.
 
Quant au stockage des méta données, cela se passe au niveau des Servers qui sont générés par Apache ZooKeeper.
[[File:ASG]]
+
[[File:ASG.png]]
 
=== L'independance des clusters ===
 
=== L'independance des clusters ===
   
Line 51: Line 50:
 
Cette configuration présente des avantages comme par exemple les backups, si un des Bookies lache pour n'importe quelle raison, nous pourrons recopier les segments perdus dans un autre Bookie.
 
Cette configuration présente des avantages comme par exemple les backups, si un des Bookies lache pour n'importe quelle raison, nous pourrons recopier les segments perdus dans un autre Bookie.
   
  +
[[File:seg.png]]
 
== Comportement ==
 
== Comportement ==
   
Line 68: Line 68:
 
Les utilisateurs possèdent 4 manières differentes de consommer des messages :
 
Les utilisateurs possèdent 4 manières differentes de consommer des messages :
   
1) [[Exclusive]]
+
1) Exclusive
 
Un seul consommateur peut accèder à une Subscription et si un autre consommateur essaye d'accéder à la subscription, il se verra refuser l'accès, d'où le principe d'exclusivité.
 
Un seul consommateur peut accèder à une Subscription et si un autre consommateur essaye d'accéder à la subscription, il se verra refuser l'accès, d'où le principe d'exclusivité.
   
2) [[Fail Over]]
+
2) Fail Over
 
Deux consommateurs sont connectés en même temps a une même subscription, de ce fait si un des consommateurs tombe, le deuxième prend le relai.
 
Deux consommateurs sont connectés en même temps a une même subscription, de ce fait si un des consommateurs tombe, le deuxième prend le relai.
   
3) [[Shared]]
+
3) Shared
 
Plusieurs consommateurs peuvent être connectés en même temps à une même Subsciption , seulement, l'ordre de reception des données sera répartit selon un ordre Round Robin, de ce fait, on pourra par exemple avoir une suite de message, la première moitié sera envoyé au consommateur 1 et l'autre au deuxieme consommateur
 
Plusieurs consommateurs peuvent être connectés en même temps à une même Subsciption , seulement, l'ordre de reception des données sera répartit selon un ordre Round Robin, de ce fait, on pourra par exemple avoir une suite de message, la première moitié sera envoyé au consommateur 1 et l'autre au deuxieme consommateur
   
4) [[Key Linked]]
+
4) Key Linked
 
Un mode assez similaire au précédent, à la difference pret que tous les messages qui sont associés à une même clé seront délivrés à un unique consommateur.
 
Un mode assez similaire au précédent, à la difference pret que tous les messages qui sont associés à une même clé seront délivrés à un unique consommateur.
   
Line 84: Line 84:
 
=== Consommation des messages ===
 
=== Consommation des messages ===
   
- [[Acknowledgement-Based retention]]
+
- Acknowledgement-Based retention
 
Tous les messages non traités non acquittés seront stockés dans BookKeep, si un consommateur n'arrive pas à entamer un message, il pourra venir l'acquitter dans BookKeeper plus tard vu que le message est stocké.
 
Tous les messages non traités non acquittés seront stockés dans BookKeep, si un consommateur n'arrive pas à entamer un message, il pourra venir l'acquitter dans BookKeeper plus tard vu que le message est stocké.
   
- [[Size-Based Retention]]
+
- Size-Based Retention
 
Tous les messages sont stockés sur le disque et supprimés lorsque le topic atteint une taille limite préalablement configurée
 
Tous les messages sont stockés sur le disque et supprimés lorsque le topic atteint une taille limite préalablement configurée
   
- [[Time-Based retention]]
+
- Time-Based retention
 
Ici, tous les messages acquittés ou non seront stocké dans le disque durant une durée limitée. Après la fin du temps impartit, les messages stockés seront supprimés.
 
Ici, tous les messages acquittés ou non seront stocké dans le disque durant une durée limitée. Après la fin du temps impartit, les messages stockés seront supprimés.
   
- [[Time-To-Live retention]]
+
- Time-To-Live retention
 
Les messages seront automatiquement supprimés des topics s'ils ne sont pas acquité après un temps donné limité.
 
Les messages seront automatiquement supprimés des topics s'ils ne sont pas acquité après un temps donné limité.
   
   
  +
=== Multi Tenant ===
 
 
 
 
   
  +
Chaque topic possède sa propre hierarchie, composée d'un Tenant et d'un Name Space.
  +
Ces deux entités represent un outil pour pouvoir facilier l'administration des clusters.
  +
Cette décomposition permet donc d'avoir plusieurs plusieurs niveaux de sécurités suivant les topics en question.
   
  +
=== Instance replication ===
  +
Afin de pouvoir utiliser plusieurs topics dans differentes parties du monde, Apache Pulsar a développé l'Instance replication, si un producteur se site dans une zone géographique du monde qui est differente de celle du consommateur, cela ne pose plus aucun problème, tant que le topic appartient au même name space il y a la possibilité de répliquer les messages entre différentes régions du monde.
   
  +
== Demonstration ==
   
 
== Veille Technologique 2020 ==
 
== Veille Technologique 2020 ==
 
* Année : [[VT2020]]
 
* Année : [[VT2020]]
* Sujet : Adobe Pulsar
+
* Sujet : Apache Pulsar
 
* Slides : [[Media:AdobePulsar.pdf|Slides]]
 
* Slides : [[Media:AdobePulsar.pdf|Slides]]
 
* Auteur : Ali El Mufti
 
* Auteur : Ali El Mufti

Latest revision as of 17:46, 1 March 2021

Link title

Introduction

Pulsar est un système de messagerie distribué que l’on peut comparer à Apache Kafka. C'est un projet né chez Yahoo! à l'issu d’un besoin de faire un système de messagerie, les systèmes fait à l’époque n'étant pas suffisants . Ce produit est utilisé actuellement pour d’autre application comme Yahoo Mail, Yahoo Finance mais aussi Yahoo! Sport. Le premier déploiement de Pulsar date de 2015, il a par la suite été mit en OpenSource en 2016 et est finalement devenu un Top Project Apache en septembre 2018.

Fonctionnement

Messagerie Distribuée

Pulsar est un système de messagerie distribué, cela veut donc dire que :

 -   Les données répliquées et enregistrées sur le disque.
 -   La présence d'une réplique géographique des données
 -   Une garantit d'ordre des messages
 -   La fonction de Multi-Entités
 -   Un fort débit

Concept et architecture

L'architecture est composée principalement de Producteurs de Consommateurs et de Brokers. Chaque Broker héberge Topic. Les Brokers représentent le point de contact entre les consommateurs et les producteurs, c'est là où vont être hégergés les topics. C'est là ou l'on trouve la première difference entre Apache Pulsar et Apache Kafka, contrairement à Kafka, les Brokers ne stockent pas les informations des messages. CA.png

Architecture des stockages et des gestions

On remarque donc que les Brokers s'occupent de la gestion des données et du traitement des messages, seulement, nous possedons ici de nouvelles entitées appellées Bookies qui s'occupent du stockage des données des differents messages.

Les Brokers et les Bookies sont donc organisés en Cluster :

  -  Gestion des messages composé des Brokers
  -  Stockage des messages composé des Bookies et géré par Apache BookKeeper


Quant au stockage des méta données, cela se passe au niveau des Servers qui sont générés par Apache ZooKeeper. ASG.png

L'independance des clusters

On remarque donc qu'il y a une décorellation entre la partie stockage et la partie traitement des messages. Nous pouvons donc rajouter des brokers si l'on a besoin de plus de CPU pour traiter des messages et plus de Bookies si nous avons besoin de plus de stockage. File:IDC.jpg On peut donc faire évoluer les deux entités et leurs nombres totalement indépendamment les unes des autres.

Segmentation des données

Les informations d'un Topic se divisent en un ensemble de segments et chacun de ces segments represente un ensemble de message qui seront envoyés dans les bookies.

Contrairement à Kafka, les données ne sont pas stockées de manière entière, elles sont partitionnées suivant les differents Bookies. Cette configuration présente des avantages comme par exemple les backups, si un des Bookies lache pour n'importe quelle raison, nous pourrons recopier les segments perdus dans un autre Bookie.

Seg.png

Comportement

Obtention des messages

Les messages sont composés de :

 - Tableau d’octets
 - Clé (optionnel)
 - Ensemble de propriétés (optionnel)
 - Nom du producteur
 - ID de séquence (numéro d’ordre dans le topic, attribué par le producteur)
 - Timestamps


Les utilisateurs possèdent 4 manières differentes de consommer des messages :

 1) Exclusive
    Un seul consommateur peut accèder à une Subscription et si un autre consommateur essaye d'accéder à la subscription, il se verra refuser l'accès, d'où le principe d'exclusivité.
 2) Fail Over
    Deux consommateurs sont connectés en même temps a une même subscription, de ce fait si un des consommateurs tombe, le deuxième prend le relai.
 3) Shared
    Plusieurs consommateurs peuvent être connectés en même temps à une même Subsciption , seulement, l'ordre de reception des données sera répartit selon un ordre Round Robin, de ce fait, on pourra par exemple avoir une suite de message, la première moitié sera envoyé au consommateur 1 et l'autre au deuxieme consommateur
  4) Key Linked
    Un mode assez similaire au précédent, à la difference pret que tous les messages qui sont associés à une même clé seront délivrés à un unique consommateur.

Notons aussi que plusieurs subscriptions peuvent avoir un même topic.

Consommation des messages

 - Acknowledgement-Based retention
   Tous les messages non traités non acquittés seront stockés dans BookKeep, si un consommateur n'arrive pas à entamer un message, il pourra venir l'acquitter dans BookKeeper plus tard vu que le message est stocké.
 - Size-Based Retention
   Tous les messages sont stockés sur le disque et supprimés lorsque le topic atteint une taille limite préalablement configurée
 - Time-Based retention
   Ici, tous les messages acquittés ou non seront stocké dans le disque durant une durée limitée. Après la fin du temps impartit, les messages stockés seront supprimés.
 - Time-To-Live retention
    Les messages seront automatiquement supprimés des topics s'ils ne sont pas acquité après un temps donné limité.


Multi Tenant

Chaque topic possède sa propre hierarchie, composée d'un Tenant et d'un Name Space. Ces deux entités represent un outil pour pouvoir facilier l'administration des clusters. Cette décomposition permet donc d'avoir plusieurs plusieurs niveaux de sécurités suivant les topics en question.

Instance replication

Afin de pouvoir utiliser plusieurs topics dans differentes parties du monde, Apache Pulsar a développé l'Instance replication, si un producteur se site dans une zone géographique du monde qui est differente de celle du consommateur, cela ne pose plus aucun problème, tant que le topic appartient au même name space il y a la possibilité de répliquer les messages entre différentes régions du monde.

Demonstration

Veille Technologique 2020

  • Année : VT2020
  • Sujet : Apache Pulsar
  • Slides : Slides
  • Auteur : Ali El Mufti