Apache Kafka supprime la dépendance à ZooKeeper

• Comme ZooKeeper est utilisé comme magasin de métadonnées externe, cela entraîne des problèmes de redondance, d’inefficacité et de limites de scalabilité

• KIP-500 : "Kafka on Kafka"

→ Gestion directe des métadonnées au sein de Kafka, avec stockage dans des partitions

→ Les métadonnées sont traitées comme des logs

→ Amélioration de la vitesse de création/suppression de topics : contrairement à ZooKeeper, la création d’un nouveau topic se termine par une opération O(1) sur la partition de métadonnées

→ Un seul cluster peut prendre en charge plus d’un million de partitions

• Feuille de route

→ Il existe encore des outils d’administration qui communiquent directement avec ZooKeeper. Une API destinée à les remplacer est prévue

→ Comme une dépendance apparaît entre la partition de métadonnées et le contrôleur, KIP-595 prévoit une implémentation d’un quorum de métadonnées autogéré via le protocole Raft

→ Mode KIP-500 exécutant Kafka sans ZooKeeper : au départ, la prise en charge complète sera incomplète, donc ZooKeeper continuera d’être utilisé avec le mode legacy

→ KIP-500 est une "Bridge Release". Il s’agit d’une mise à niveau intermédiaire préparant une migration sans interruption vers une version postérieure à KIP-500 où la prise en charge de ZooKeeper aura totalement disparu. Une autre mise à niveau vers une véritable version sans ZooKeeper sera ensuite possible

[minji]

Merci. C’était très intéressant.