Paris Kafka Meetup - Concepts & Architecture
2 j'aime970 vues
Le document présente Apache Kafka, un système de messagerie distribué hautement scalable et tolérant aux pannes, conçu pour le traitement de flux de données en temps réel. Il aborde les concepts clés, tels que la production et la consommation de messages, la fonctionnalité de partitionnement et de réplication, ainsi que les API disponibles, incluant Kafka Connect et Kafka Streams. De plus, il décrit des cas d'utilisation pratiques et les configurations de tolérance aux pannes pour assurer la disponibilité des données.
![Broker 1 Broker 2 Broker 3
P0
R1
P0
R2
P0
R3
ISR (in-sync replicas) = [1, 2, 3]
Producer
1
2
Acknowledgment
(Optionnel)
3](https://image.slidesharecdn.com/paris-kafka-meetup-may17-1-architecture-160518202431/85/Paris-Kafka-Meetup-Concepts-Architecture-20-320.jpg)
![Broker 1 Broker 2 Broker 3
P0
R1
P0
R2
P0
R3
ISR (in-sync replicas) = [1, 2]
Producer
1
2
Acknowledgment
(Optionnel) Out-of-Sync
Down
replica.lag.time.max.ms (10secondes)
3](https://image.slidesharecdn.com/paris-kafka-meetup-may17-1-architecture-160518202431/85/Paris-Kafka-Meetup-Concepts-Architecture-21-320.jpg)
![Broker 1 Broker 2 Broker 3
P0
R1
P0
R2
P0
R3
ISR (in-sync replicas) = [1, 2, 3]
Producer
Acknowledgment
request.required.acks
0 : Le Producer n’attend aucun acquittement
de la part du leader.
? ? ?](https://image.slidesharecdn.com/paris-kafka-meetup-may17-1-architecture-160518202431/85/Paris-Kafka-Meetup-Concepts-Architecture-22-320.jpg)
![Broker 1 Broker 2 Broker 3
P0
R1
P0
R2
P0
R3
ISR (in-sync replicas) = [1, 2, 3]
Producer
Acknowledgment
request.required.acks
1 : Le leader garantit avoir écrit le message
? ?](https://image.slidesharecdn.com/paris-kafka-meetup-may17-1-architecture-160518202431/85/Paris-Kafka-Meetup-Concepts-Architecture-23-320.jpg)
![Broker 1 Broker 2 Broker 3
P0
R1
P0
R2
P0
R3
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-Sync
Down
?](https://image.slidesharecdn.com/paris-kafka-meetup-may17-1-architecture-160518202431/85/Paris-Kafka-Meetup-Concepts-Architecture-24-320.jpg)
![Broker 1 Broker 2 Broker 3
P0
R1
P0
R2
P0
R3
ISR (in-sync replicas) = [1, 2]
Producer
1
2
Consumer
3
Acknowledgment
(Optionnel) committed Out-of-Sync
Down
replica.lag.time.max.ms (10secondes)](https://image.slidesharecdn.com/paris-kafka-meetup-may17-1-architecture-160518202431/85/Paris-Kafka-Meetup-Concepts-Architecture-26-320.jpg)
Paris Kafka Meetup - Concepts & Architecture
- 1. Paris Apache Kafka Meetup Florian HUSSONNOIS Zenika @fhussonnois
- 2. Qu’est-ce que Kafka ? Les concepts et l’architecture Structure et distribution des messages La tolérance à la panne La consommation des messages Les nouvelles APIs Kafka Connect et Kafka Streams (PIZZAS) Comment développer avec les APIs Clients ? API Producer API Consumer
- 3. A high-throughput distributed messaging system
- 4. Kafka est un projet créé à l’origine chez Open-source en 2011 Broker Broker Broker Producer Producer Producer Consumer Consumer Consumer Publish Subscribe Cluster Distribué Hautement scalable Durable Tolérant à la panne Un simple système de messages
- 5. Spécification 3 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)
- 6. 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()
- 7. Construction de data pipelines à très faible latence Log delivery, collection processing Data integration Activity stream, Data pipeline Real-Time monitoring / Event Tracking
- 8. 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 Stream Framework pour développer des applications data-driven / realtime stream processing
- 9. Topic, Partition, Stockage et Rétention
- 10. Clé Valeur Optionnelle (Primary Key) Bytes (Texte, JSON, XML, Images, etc)
- 11. • 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 K1 V1 K2 V2 null V4 K1 V5 null V7 K5 V8 K2 V10 Clé Valeur K2 V10 K1 V3 K5 V9 Write-ahead Log
- 12. • 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
- 13. Partition Segment 1 Segment 2 Segment N File Segments (défaut 1Go) Active Temps Une partition est : • Immuable • Stockée sur un disque • Divisée en segments Configuration • log.segment.bytes • log.roll.hours
- 14. Partition Segment 1 Segment 2 Segment N File Segments (défaut 1Go) Actif Temps • Temps – 7 jours • Taille maximum d’un log • Clé - Compaction Les anciens messages sont automatiquement supprimés
- 15. 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 V11 Log après compaction Clé Valeur Clé Valeur Log avant compaction
- 16. 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 V11 Log 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)
- 17. 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
- 18. Réplication, Disponibilité et Consistance
- 19. 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
- 20. Broker 1 Broker 2 Broker 3 P0 R1 P0 R2 P0 R3 ISR (in-sync replicas) = [1, 2, 3] Producer 1 2 Acknowledgment (Optionnel) 3
- 21. Broker 1 Broker 2 Broker 3 P0 R1 P0 R2 P0 R3 ISR (in-sync replicas) = [1, 2] Producer 1 2 Acknowledgment (Optionnel) Out-of-Sync Down replica.lag.time.max.ms (10secondes) 3
- 22. Broker 1 Broker 2 Broker 3 P0 R1 P0 R2 P0 R3 ISR (in-sync replicas) = [1, 2, 3] Producer Acknowledgment request.required.acks 0 : Le Producer n’attend aucun acquittement de la part du leader. ? ? ?
- 23. Broker 1 Broker 2 Broker 3 P0 R1 P0 R2 P0 R3 ISR (in-sync replicas) = [1, 2, 3] Producer Acknowledgment request.required.acks 1 : Le leader garantit avoir écrit le message ? ?
- 24. Broker 1 Broker 2 Broker 3 P0 R1 P0 R2 P0 R3 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-Sync Down ?
- 25. min.insync.replicas Nombre 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
- 26. Broker 1 Broker 2 Broker 3 P0 R1 P0 R2 P0 R3 ISR (in-sync replicas) = [1, 2] Producer 1 2 Consumer 3 Acknowledgment (Optionnel) committed Out-of-Sync Down replica.lag.time.max.ms (10secondes)
- 27. Apache ZooKeeper Métadonnées sur les Leaders et réplicas In-sync replicas: réplicas éligiblent à devenir leader Controller Détecte les erreurs au niveau broker Sélectionne les leaders pour toutes les partitions
- 28. Offsets, Consumer Groups et Auto- rebalancing
- 29. 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
- 30. • 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 Producer Append-Only
- 31. 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
- 32. 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
- 33. 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 consumer 4
- 34. 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
- 35. 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
- 36. • 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
- 37. • 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
- 38. • 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
- 39. • 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)