Upload
florian-hussonnois
View
450
Download
1
Embed Size (px)
Citation preview
Paris Apache Kafka Meetup
Florian HUSSONNOISZenika
@fhussonnois
Qu’est-ce que Kafka ?
Les concepts et l’architectureStructure et distribution des messagesLa tolérance à la panneLa consommation des messages
Les nouvelles APIsKafka Connect et Kafka Streams
(PIZZAS)
Comment développer avec les APIs Clients ?API ProducerAPI Consumer
A high-throughput distributed messaging system
Kafka est un projet créé à l’origine chez
Open-source en 2011
Broker
Broker
Broker
Producer
Producer
Producer
Consumer
Consumer
Consumer
Publish Subscribe
ClusterDistribué
Hautement scalable
Durable
Tolérant à la panne
Un simple système de messages
Spécification3 machines : « commodity hardware »
Intel Xeon 2.5 GHz processor with six cores
Six 7200 RPM SATA drives (JBOD)
32GB of RAM
1Gb Ethernet
Scenario (message = 100 octets)
Three producers, 3x async replication
2,024,032 records/sec (193.0 MB/sec)O(1)
Fast Writes
Toutes les écritures sont mises dans le page-cache (c.à.d RAM)
Zero-Copy
Evite les copies redondantes de données entre des buffers intermédiaires
Réduit les context-swithes entre Kernel et Application.
API Java NIO (java.nio.channels.FileChannel)
transferTo() transfert des données depuis un fichier vers une socket
Unix – sendfile()
Construction de data pipelines à très faible latence
Log delivery, collection processing
Data integration
Activity stream, Data pipeline
Real-Time monitoring / Event Tracking
Kafka Core
Le système de messagerie distribué
Kafka Client
API Clients pour publier / consommer des messages (Java, C++, Go, etc)
Kafka Connect
API pour connecter des systèmes à Kafka en tant que Source ou Sink
Kafka StreamFramework pour développer des applications data-driven / realtime stream processing
Topic, Partition, Stockage et Rétention
Clé Valeur
Optionnelle (Primary Key)
Bytes (Texte, JSON, XML, Images, etc)
• Un Producer produit des messages vers un Topic
• Un ou plusieurs Consumers s’abonnent à un topic pour lire les messages
Nouveaux messagesAnciens messages Temps
Producer
Consumer Consumer
Append-Only
K1V1
K2V2
nullV4
K1V5
nullV7
K5V8
K2V10
Clé
Valeur
K2V10
K1V3
K5V9
Write-ahead Log
• Clé• Round-Robin• Implémentation Custom
Messages partitionnés par :
Topic : User_Activity
Partition 0
Partition 1
Partition 2
Producer Consumer
Broker 2
Broker 3
Broker 1
Partition
Segment 1
Segment 2
Segment N
File Segments (défaut 1Go)
ActiveTemps
Une partition est :• Immuable• Stockée sur un disque• Divisée en segments
Configuration• log.segment.bytes• log.roll.hours
Partition
Segment 1
Segment 2
Segment N
File Segments (défaut 1Go)
ActifTemps
• Temps – 7 jours• Taille maximum d’un log• Clé - Compaction
Les anciens messages sont automatiquement supprimés
Permet la suppression des messages avec un payload à null.
K1 K2 K1 K1 K3 K2 K4 K5 K5 K2 K6
V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11
K1 K3 K4 K5 K2 K6
V4 V5 V7 V9 V10 V11Log après compaction
Clé
Valeur
Clé
Valeur
Log avant compaction
Cas d’utilisation
K1 K2 K1 K1 K3 K2 K4 K5 K5 K2 K6
V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V11
K1 K3 K4 K5 K2 K6
V4 V5 V7 V9 V10 V11Log après compaction
Clé
Valeur
Clé
Valeur
Log avant compaction
• Distribuer les changements d’états d’une base de données• Event-sourcing• Cache distribué clé / valeur• State journaling (Hight Availability)
Application(Producer)
Application(Consumer)
Topic avec compaction
Application(Consumer)
Application(Consumer)
Embedded Database
Embedded Database
Embedded Database
Application(Producer)
Application(Producer)
Application Servers Application Servers
Réplication, Disponibilité et Consistance
Topic : User_Activity
Broker 2
Broker 3
Broker 1
Partition Leader 0
Partition Follower 2
Partition Leader 1
Partition Follower 0
Partition Leader 2
Partition Follower 1
Producer Consumer
Kafka accepte (#réplicas - 1) broker down avant de perdre des données
Broker 1 Broker 2 Broker 3
P0R1
P0R2
P0R3
ISR (in-sync replicas) = [1, 2, 3]
Producer
1
2
Acknowledgment(Optionnel)
3
Broker 1 Broker 2 Broker 3
P0R1
P0R2
P0R3
ISR (in-sync replicas) = [1, 2]
Producer
1
2
Acknowledgment(Optionnel) Out-of-Sync
Down
replica.lag.time.max.ms (10secondes)
3
Broker 1 Broker 2 Broker 3
P0R1
P0R2
P0R3
ISR (in-sync replicas) = [1, 2, 3]
Producer
Acknowledgment
request.required.acks
0 : Le Producer n’attend aucun acquittement
de la part du leader.
? ? ?
Broker 1 Broker 2 Broker 3
P0R1
P0R2
P0R3
ISR (in-sync replicas) = [1, 2, 3]
Producer
Acknowledgment
request.required.acks
1 : Le leader garantit avoir écrit le message
? ?
Broker 1 Broker 2 Broker 3
P0R1
P0R2
P0R3
ISR (in-sync replicas) = [1, 2]
Producer
Acknowledgment
request.required.acks
all : Le leader attend d’avoir reçu un acquittement
de la part de tous les in-sync réplicas.
1
2
3 Out-of-SyncDown
?
min.insync.replicasNombre minimum de réplicas qui doivent acquitter un message lorsque request.required.acks = -1 (all)
Compromis entre
Disponibilité et Consistance
Configuration possible
replication_factor = 3; request.required.acks = all; min.insync.replicas=2
Broker 1 Broker 2 Broker 3
P0R1
P0R2
P0R3
ISR (in-sync replicas) = [1, 2]
Producer
1
2
Consumer
3
Acknowledgment(Optionnel) committed Out-of-Sync
Down
replica.lag.time.max.ms (10secondes)
Apache ZooKeeperMétadonnées sur les Leaders et réplicas
In-sync replicas: réplicas éligiblent à devenir leader
ControllerDétecte les erreurs au niveau broker
Sélectionne les leaders pour toutes les partitions
Offsets, Consumer Groups et Auto-rebalancing
Topic : User_Activity
Partition 0
Partition 1
Partition 2
0 1 3 4
Consumer 10 1 2 4
0 2 3 4
5 6
5
Consumer 1
Consumer 2
2
3
1
• Un offset est un identifiant unique et incrémental par partition• Un message est identifié par le triplet : Topic / Partition / Offset
• Les offsets des consumers sont stockés dans un topic système• Si aucune position, 2 stratégies possibles : Earliest ou Latest
0 1 2 3 4 42 44 45 4643
Current Position
Last Committed Offset High Watermark
Log End Offset
ProducerAppend-Only
Topic : User_Activity
Partition 0
Partition 1
Partition 2
0 1 3 4
Consumer 10 1 2 4
0 2 3
5 6
5
2
3
1
Consumer 1
Consumer 2
Consumer 3
Consumer 1
Consumer 2
Consumer Group Vert
Consumer Group Bleu• Une partition est assignée automatiquement à un unique consumer au sein d’un groupe• Plusieurs groupes peuvent souscrire à un même topic
4
Topic : User_Activity
Partition 0
Partition 1
Partition 2
0 1 3 4
Consumer 10 1 2 4
0 2 3
5 6
5
2
3
1
Consumer 1
Consumer 2
Consumer Group Vert
Consumer 3
• Les consumers se coordonnent automatiquement pour se distribuer les partitions.• Le nombre de partitions définit le niveau de parallélisme maximum pour consommer un topic• Il n’est pas possible de définir plus de consumers que de partitions
4
Topic : User_Activity
Partition 0
Partition 1
Partition 2
0 1 3 4
Consumer 10 1 2 4
0 2 3
5 6
5
2
3
1
Consumer 1
Consumer 2
Consumer Group Vert
Consumer 3
Crash ou arrêt d’un consumer4
Topic : User_Activity
Partition 0
Partition 1
Partition 2
0 1 3 4
Consumer 10 1 2 4
0 2 3
5 6
5
2
3
1
Consumer 1
Consumer 2
Consumer Group Vert
Consumer 3
La partition est automatiquement réassignée à l’un des consumers4
Topic : User_Activity
Partition 0
Partition 1
Partition 2
0 1 3 4
Consumer 10 1 2 4
0 2 3
5 6
5
2
3
1
Consumer 1
Consumer 2
Consumer Group Vert
Consumer 3
Partition 3 0 2 3 4 51
• La nouvelle partition est assignée à un des consumers
4
• Les messages sont stockés dans l’ordre dans lequel ils sont produits
• L’ordre de lecture des messages est garanti uniquement par partition
• En cas de panne, certains messages peuvent-être produits ou consommés plusieurs fois (At-Least Once)
0 2 3 4
Consumer v1
Last Committed Offset
Consomme et commit le message à l’Offset 1
1
• Les messages sont stockés dans l’ordre dans lequel ils sont produits
• L’ordre de lecture des messages est garanti uniquement par partition
• En cas de panne, certains messages peuvent-être produits ou consommés plusieurs fois (At-Least Once)
0 1 3 4
Consumer v1
Last Committed Offset
Se déplace à l’offset 2
2
• Les messages sont stockés dans l’ordre dans lequel ils sont produits
• L’ordre de lecture des messages est garanti uniquement par partition
• En cas de panne, certains messages peuvent-être produits ou consommés plusieurs fois (At-Least Once)
0 1 3 4
Consumer v1
Last Committed Offset
Crash
2
• Les messages sont stockés dans l’ordre dans lequel ils sont produit
• L’ordre de lecture des messages est garanti uniquement par partition
• En cas de panne, certains messages peuvent-être produits ou consommés plusieurs fois (At-Least Once)
0 3 4
Consumer v2
Last Committed Offset
21
Re-consomme le message à l’Offset 2 (doublon)
KEEP
CALMAND
STREAM
YOUR DATA