Kafka Part 01

Kafka – Part01
Hamed.K – 20171104
Dernier Maj: 20180118
Intro
Kafka: c’est quoi?
Do you mean KafTa?

https://kafka.apache.org/intro
● Distributed streaming platform
● Aims to provide a unified, high-throughput, low-
latency platform for handling real-time data feeds.
● Massively scalable pub/sub message queue
architected as a distributed transaction log
● Distributed streaming platform
● Aims to provide a unified, high-throughput, low-
latency platform for handling real-time data feeds.
● Massively scalable pub/sub message queue
architected as a distributed transaction log
Carte d’identité
● Initialement développé par linkedIn
● Devenu open source début 2011 (agé de 6+ ans)
● A intégré Apache le 23 octobre 2012
● Écrit en scala et java, Licence Apache 2.0
● Plusieurs références: LinkedIn, Amadeus, Netflix, eBay, Uber,
Paypal, Cisco systems...etc
● Le nom semble provenir de l’écrivain Franz Kafka, étant une
plateforme optimisée en écrire
source: https://en.wikipedia.org/wiki/Apache_Kafka
kafka dans notre contexte
● On pense l’utiliser pour les communications asynchrones entre nos
microservices: tracer l’utilisation des CRs, synchroniser les données non
normalisées, etc.
● kafka pourrait être une brique d’architecture indispensable, une fois on migre
vers une architecture CQRS.
Pourquoi Kafka
● s’adapte bien avec notre contexte (tourne sur JVM, supporté
par spring-cloud-stream, s’intègre bien avec spring boot...etc)
Pourquoi Kafka
● s’adapte bien avec notre contexte (tourne sur JVM, supporté
par spring-cloud-stream, s’intègre bien avec spring boot...etc)
● broker distribué, scalable, très performant, option de durabilité
● projet actif et ne cesse de gagner en intérêt et popularité
● se distingue par rapport à la concurrence

Kafka vs la concurrence
source: https://www.openhub.net
source: https://stackshare.io/stackups/
source: https://trends.google.com/trends
Architecture et Terminologie
terminologie
● producer
● consumer
● message
● broker
● cluster
● topic
● partitions
● leader, follower et replicas
● offsets
● consumer-groups, coordinator, leader
producer
émetteur
communication classique,
request/response pattern,
via restTemplate, feign
client...etc
émetteur(s): émet des messages à

destination d’un ou plusieurs
récepteur (par exemple un
microservice, une application
externe...etc)
récepteur(s): reçois et traite les

messages qui sont produit
Message: requête/réponse, objet de

communication, contenant les
informations à véhiculer au consumer
consumer
récepteur
producer
émetteur
communication classique,
request/response pattern,
via restTemplate, feign
client...etc Avantages
+ communication synchrone, temps réel
émetteur(s): émet des messages à + feedback rapide (response)
destination d’un ou plusieurs
récepteur (par exemple un Inconvénients
microservice, une application - lorsque la communication prend plus de temps que
externe...etc) prévue -> timeout -> le statut d’exécution reste floue
- le rythme du “consumer” est géré par le “producer”
récepteur(s): reçoit et traite les - Couplage fort: les threads du producers restent bloqués
messages qui sont produit en attente des réponses -> risque de panne
Message: requête/réponse, objet de ⇒ besoin de découpler, on parle alors de broker

communication, contenant les
informations à véhiculer au consumer
consumer
récepteur
Broker: c’est le serveur kafka. il joue producer
producer
le rôle de médiateur entre les
producers et les consumers en leur
permettant de communiquer
efficacement avec un minimum de
couplage entre eux
producer(s): produit / publie un flux

de messages en envoyant les
messages au broker.
Broker
consumer(s): s’abonne à un ou
plusieurs flux au niveau du broker, et
traite les messages reçus.
Message: objet de communication,

produit par le producer (généralement
structuré en clé, valeur et timestamp)
consumer
consumer
NB: le consommateur consomme les
message à son rythme, non plus au
rythme du producer
producer
producer
Broker: c’est le serveur kafka. il joue
le rôle de médiateur entre les
producers et les consumers en leur
permettant de communiquer
efficacement avec un minimum de
couplage entre eux
en Panne
producer(s): produit / publie un flux
de messages en envoyant les
message au broker. Broker
consumer(s): s’abonne à un ou
plusieurs flux au niveau du broker, et
traite les messages reçus.
et si le broker tombe en panne?

-> risque de perte de messages
⇒ besoin de haute disponibilité, consumer

consumer
de cluster
producer
producer
cluster: un groupe de brokers

qui se partagent la charge du
travail.
kafka est conçu pour être

distribuée. il utilise apache Broker1 Broker2 Broker3
zookeeper pour assurer le
clustering entre ses serveurs
(brokers).
ainsi, en cas de panne au

niveau d’un broker, les flux des zookeeper
messages qui lui ont été
envoyés sont toujours
accessibles au niveau des consumer
consumer
autres brokers (qui sont sur le
même cluster)
producer1 producer2 producer3
supposons que nous avons

plusieurs ‘producers’ et
‘consumers’.
Le consommateur 1 veut
consommer les messages
Broker1 Broker2 Broker3
produit par le producteur 1 mais
pas ceux du producteur 2 et 3.
poussons encore plus le use-

case, le consommateur ne veux
consommer que les messages
zookeeper
traitant le changement de
l’employé.
consumer1 consumer2

plusieurs ‘producers’ et
‘consumers’.
Le consommateur 1 veut Les messages peuvent avoir des destinataires

consommer les messages différents. Chaque consommateur doit pouvoir
Broker1 Broker2
produit par le producteur 1 mais distinguer entre les messages qui Broker3
lui sont destinés,
pas ceux du producteur 2 et 3. qui l’intéresse, et ceux qui ne le sont pas
poussons encore plus le use- ⇒ besoin d’identifier les flux -> On parle de topic
case, le consommateur ne veux
consommer que les messages
zookeeper
traitant le changement de
l’employé.
consumer1 consumer2
topic: un topic est un nom T1 T1 T1
unique de flux kafka, vers lequel T2

les messages sont publiés.
Exemple:cr-country-affectation
Les topics de Kafka sont

toujours multi-abonnés; c'est-à-
dire qu'un sujet peut avoir zéro,
un ou plusieurs consommateurs
qui s'abonnent aux données qui zookeeper
y sont écrites.
consumer1 consumer2
topic: un topic est un nom
taille de T1
unique de flux kafka, vers lequel dépasse les
limites du
les message sont publiés. broker 1
Exemple:cr-country-affectation T1 T1 T1
T2
si les donnés du topic T1 sont

très grandes, et dépassent la
capacité du broker 1, qui
contient déjà d’autre topics?
⇒ besoin de pouvoir partitionner

les données, obtenant des tailles zookeeper
plus raisonnables qui peuvent
être distribuées sur plus d’un
broker -> on parle alors de consumer1 consumer2
partition
}
T1/P1 T1/P1
Partition 1
Topic 1
Partition 2 T1/P2 T1/P2
Chaque partition est une
séquence ordonnée et immuable
d'enregistrements. T2
le nombre de partition d’un topic

est spécifié au moment de sa
création.
zookeeper
consumer1 consumer2
}
T1/P1 T1/P1
Partition 1
vue que la nature des flux
destinés aux topics 1 et 2 sont Topic 1
différents, nous voulons partager
le premier sur 2 brokers et le
T2 T2 T2
deuxième sur 3 brokers.
Pour ce faire, il y a besoin de

spécifier le nombre de replicas.
On parle alors de réplication, et zookeeper

replication-factor.
consumer1 consumer2
}
T1/P1 T1/P1
Partition 1
replication-factor: le
Topic 1
replication-factor permet de Partition 2 T1/P2 T1/P2
spécifier le nombre de copie de
partition à effectuer pour chaque T2 T2 T2
topic.
dans notre exemple le

replication-factor de T1 est 2:
chaque partition a été répliquée
zookeeper
sur 2 noeuds, celui de T2 est 3.
consumer1 consumer2
question: comment s’assurer

que les flux (les topics
partitionnés et clusterisés) sont
}
T1/P1 T1/P1
Partition 1
bien synchrones?
Topic 1
⇒ besoin de synchroniser les
partitions, risque de perte de
T2 T2 T2
donnée lors de crash d’un
broker.
zookeeper
consumer1 consumer2
question: comment s’assurer
leader of follower
que les flux (les topics Partition 1
partitionnés et clusterisés) sont
bien synchrones?
}
T1/P1 T1/P1
Partition 1
Topic 1
⇒ besoin de synchroniser les Partition 2 T1/P2 T1/P2
partitions
T2 T2 T2
pour répondre à ce besoin,
kafka désigne un replicas
comme leader et le reste des
réplicas sont appelés ‘follwers’.
zookeeper
Toutes les demandes d'écriture
passent par le leader et le leader
propage les écritures au suiveur.
consumer1 consumer2
Lorsqu’un consommateur
récupère des messages à partir Partition 1 T1/P1 T1/P1
d’une partition, comment peut-il

différencier, rapidement, entre Partition 2 T1/P2 T1/P2
nouveaux messages
les messages qu’il a déjà
}
consommé (donc à ignorer) et T2
les nouveaux messages (donc à
M1 M2 M3 M4 M5 M6
consommer)?
}
messages déjà lus
zookeeper
consumer1 consumer2
Lorsqu’un consommateur
récupère des messages à partir
d’une partition, comment peut-il Partition 1 T1/P1 T1/P1
différencier, rapidement, entre

les messages qu’il a déjà Partition 2 T1/P2 T1/P2
nouveaux messages
consommé (donc à ignorer) et
}
les nouveaux messages (donc à T2
consommer)?
M1 M2 M3 M4 M5 M6
⇒ besoin d’un indicateur de
}
position de lecture, on parle
messages déjà lus position de
alors d’offset. zookeeper lecture?
consumer1 consumer2
offset: un offset est un numéro producer1 producer2 producer3
d'identification séquentiel qui identifie
de façon unique chaque
enregistrement dans la partition.

Lors de sa première initialisation, le
consommateur commence
généralement à lire le premier ou le Partition 2 T1/P2 T1/P2
nouveaux messages
dernier offset de chaque partition.
}
T2
Les messages dans chaque log de
partition sont ensuite lus M1 M2 M3 M4 M5 M6
séquentiellement. 0 1 2 3 4 5
Au fur et à mesure que le offset

consommateur progresse, il commit zookeeper
committed offset
les offsets des messages qu'il a
traités avec succès.
à l’itération suivante (ou lors de consumer1 consumer2

reprise post-crash) la position est
fixée au dernier offset commité.
plusieurs producteurs et un
seule consommateur. La charge
produite devient alors largement Partition 1 Topic
1
supérieure à la vitesse de
consommation. Partition 2 T1/P2 T1/P2
dans ce scénario, ajouter des T2

brokers au cluster n’aide pas
vraiment.
zookeeper
consumer
plusieurs producteurs et un
seule consommateur. La charge
produite devient alors largement Partition 1 Topic
1
supérieure à la vitesse de
consommation. Partition 2 T1/P2 T1/P2
dans ce scénario, ajouter des

T2
brokers au cluster n’aide pas
vraiment.
⇒ besoin d’avoir plusieurs

consommateur qui peuvent se
zookeeper
partager la charge de traitement
des messages au niveau d’un
même topic. On parle alors de
consumer
groupe de consommateur (
consumer-group)
consumer-group: groupe de producer1 producer2 producer3
consommateurs qui fonctionnent
comme une seule unité.
ceci permet de lire et traiter des Partition 1 Topic

1
données en parallèle.
avec les partitions, les
consumer-groups représentent T2
une option de scaling,
permettant de répondre à une
éventuelle montée en charge.
zookeeper
consumer consumer consumer

Consumer group 1
Partition 1 Topic
1

Étant du même groupe (même
identifiant de consommateur), et
T2
risque de
consommant d’un même topic, consommer
on peut penser au risque de le même
message
consommer le même message
plusieurs fois!
zookeeper
consumer consumer consumer

Consumer group 1
Pour éviter ce risque, une partition
n’est jamais partagée par des Consumer group 1
membres du même groupe en
consumer
même temps.
n’est jamais partagée par des
membres du même groupe en Consumer group 1
même temps.
consumer
consumer
même temps.
consumer
consumer
consumer
n’est jamais partagée par des Consumer group 1
consumer
même temps.
consumer
consumer
consumer
même temps.
consumer
si les membres du groupe consumer

dépassent le nombre des
partitions, kafka ne réclame pas, consumer
mais le consommateur en plus

consumer
restera au chômage :)
consumer
Consumer group 1
même temps.
consumer
si les membres du groupe
consumer
dépassent le nombre des
partitions, kafka ne réclame pas, consumer
restera au chômage :) consumer
il intervient en cas de crash d’un consumer
autre consommateur.
Si nous ajoutons un nouveau
groupe de consommateurs Group2
Consumer group 1
avec un seul consommateur, ce
consommateur recevra tous les consumer
messages du topic
consumer
indépendamment de ce que fait
Group1. consumer
Group2 peut avoir plus d'un consumer

consommateur, auquel cas ils
consumer
recevront chacun un sous-
ensemble de partitions, comme
nous l'avons montré pour Group1 Consumer group 2
consumer
Group2 dans son ensemble
recevra toujours tous les consumer
messages indépendamment des
autres groupes de
consommateurs.
Consumer group 1
même temps.
consumer
si les membres du groupe
dépassent le nombre des consumer
partitions, kafka ne réclame pas,

consumer
restera au chômage :) consumer
il intervient en cas de crash d’un consumer

autre consommateur.
ces affectations “partition-

consumer”, et ce dispatching
automatique entre les membres,
nécessitent plus d’un responsable
-> on parle de ‘coordinator’ et de
‘group-leader’.
kafka prévoit un coordinateur de
group qui :
Consumer group 1
- maintient une liste de
consommateurs actifs consumer
- initie l’activité de consumer

rééquilibrage et
communique les affectations consumer
aux consommateur.
consumer
on parle de rééquilibrage
consumer
(Rebalance) à chaque fois que la
liste des consommateurs change.
kafka prévoit un coordinateur de
group qui :
- maintient une liste de

consommateurs actifs consumer
consumer
- initie l’activité de
rééquilibrage et consumer
communique les affectations
aux consommateur. consumer
consumer
on parle de rééquilibrage
(Rebalance) à chaque fois que la
liste des consommateurs change.
Pour exécuter le rééquilibrage,

kafka prévoit un group-leader
Review
● producer producer
producer
● consumer
● message
● broker
Broker
consumer
consumer
● producer
● consumer
● message
● broker
● cluster
zookeeper
consumer1 consumer2
● consumer producer1 producer2 producer3
● message
● broker
}
● cluster Topic 1
● topic
T2 T2 T2
● partitions
zookeeper
consumer1 consumer2
● consumer producer1 producer2 producer3
● message
● broker
}
● cluster Topic 1
● topic
T2 T2 T2
● partitions
zookeeper
consumer1 consumer2
● consumer
● message
● broker
}
Partition 1 T1/P1
cluster T1/P1
Topic 1
● topic Partition 2 T1/P2 T1/P2
● partitions M1 M2 M3 M4 M5 M6
0 1 2 3 4 5
● offsets
zookeeper
consumer1 consumer2
● consumer
● message producer1 producer2 producer3
● broker
● cluster
}
Topic 1
● topic
● partitions
● offsets
● consumer-groups, zookeeper
coordinator, leader
consumer consumer 2
consumer
Mettre la main
à la pâte
Fully
Distributed
Apache
Kafka
Cluster
zookeeper
consumer1 consumer2
Objectif de la manip:
● mettre en place un cluster de 3 brokers (de façon progressive)

● créer un topic repliqué et partitionné
● utiliser les exemples de producer et consumer livré par kafka pour déposer des messages et les consommer
Broker0
:9092
zookeeper :2181
step 1: démarrer un broker kafka
● bin/zookeeper-server-start.sh config/zookeeper.properties
● bin/kafka-server-start.sh config/server.properties
P0 session2
Broker0
:9092
zookeeper :2181
step 2: créer un topic
● bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic session2
● bin/kafka-topics.sh --list --zookeeper localhost:2181

producer1
P0 session2
Broker0
:9092
zookeeper :2181
step 3: instancier un producteur et envoyer quelques messages
● bin/kafka-console-producer.sh --broker-list localhost:9092 --topic session2

producer1
P0 session2
Broker0
:9092
zookeeper :2181
consumer1
step 4: instancier un consommateur pour consommer les messages déjà envoyés
● bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic session2 --from-beginning

P0 session2
:9092 :9093 :9094
zookeeper :2181
step 5: configurer et instancier deux autres brokers multi-brokers
● cp config/server.properties config/server-1.properties
● cp config/server.properties config/server-2.properties
● bin/kafka-server-start.sh config/server-1.properties &

P0 session2
P0 session2- session2- session2-

rep rep rep

rep rep rep
:9092 :9093 :9094
zookeeper :2181
step 6:
● bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 2 --topic session2-rep
● bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic session2-rep

producer1
P0 session2

rep rep rep

rep rep rep
:9092 :9093 :9094
zookeeper :2181
consumer1
step 7:
● bin/kafka-console-producer.sh --broker-list localhost:9092 --topic session2-rep
● bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic session2-rep

Merci
‫شكرا‬

Kafka Part 01

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Kafka Part 01

Загружено:

Авторское право:

Доступные форматы

Kafka – Part01

Do you mean KafTa?

● broker distribué, scalable, très performant, option de durabilité

● projet actif et ne cesse de gagner en intérêt et popularité

● se distingue par rapport à la concurrence

émetteur(s): émet des messages à

récepteur(s): reçois et traite les

Message: requête/réponse, objet de

Message: requête/réponse, objet de ⇒ besoin de découpler, on parle alors de broker

producer(s): produit / publie un flux

Message: objet de communication,

et si le broker tombe en panne?

⇒ besoin de haute disponibilité, consumer

cluster: un groupe de brokers

kafka est conçu pour être

ainsi, en cas de panne au

supposons que nous avons

poussons encore plus le use-

supposons que nous avons

Le consommateur 1 veut Les messages peuvent avoir des destinataires

topic: un topic est un nom T1 T1 T1

unique de flux kafka, vers lequel T2

Les topics de Kafka sont

si les donnés du topic T1 sont

⇒ besoin de pouvoir partitionner

le nombre de partition d’un topic

Pour ce faire, il y a besoin de

On parle alors de réplication, et zookeeper

dans notre exemple le

question: comment s’assurer

d’une partition, comment peut-il

différencier, rapidement, entre

Partition 1 T1/P1 T1/P1

Au fur et à mesure que le offset

à l’itération suivante (ou lors de consumer1 consumer2

dans ce scénario, ajouter des T2

dans ce scénario, ajouter des

⇒ besoin d’avoir plusieurs

ceci permet de lire et traiter des Partition 1 Topic

consumer consumer consumer

Partition 2 T1/P2 T1/P2

consumer consumer consumer

si les membres du groupe consumer

mais le consommateur en plus

il intervient en cas de crash d’un consumer

Group2 peut avoir plus d'un consumer

partitions, kafka ne réclame pas,

il intervient en cas de crash d’un consumer

ces affectations “partition-

- initie l’activité de consumer

- maintient une liste de

Pour exécuter le rééquilibrage,

● leader, follower et replicas

● message producer1 producer2 producer3

● leader, follower et replicas

Broker1 Broker2 Broker3

● mettre en place un cluster de 3 brokers (de façon progressive)

step 1: démarrer un broker kafka

step 2: créer un topic

● bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic session2

● bin/kafka-topics.sh --list --zookeeper localhost:2181

step 3: instancier un producteur et envoyer quelques messages

● bin/kafka-console-producer.sh --broker-list localhost:9092 --topic session2