Après le pack producteur, la version v1.2 du Kafka Simulator se tourne vers le côté lecture et son événement le plus mal compris : le rééquilibrage. Ce pack ajoute 10 nouveaux scénarios, portant le cursus à 33 sur 125.
Ce que contient la v1.2
Un groupe de consommateurs est un problème de coordination habillé d’une API simple. La v1.2 rend cette coordination visible :
- Stratégies d’affectation —
range,roundrobin,stickyetcooperative-stickycôte à côte, pour voir lesquelles arrêtent tout et lesquelles ne déplacent que les partitions nécessaires. - Appartenance statique (KIP-345) — pourquoi un membre qui redémarre avant l’expiration de
session.timeout.msconserve son affectation et ne déclenche aucun rééquilibrage, et ce qui se passe quand il reste hors service trop longtemps. - Les deux timeouts —
session.timeout.msface àmax.poll.interval.ms: l’un concerne les heartbeats, l’autre un consommateur vivant mais bloqué dans le traitement. Ils échouent différemment, et le simulateur montre les deux. - Blocage et reprise — un consommateur qui cesse de poller, se fait exclure et rejoint le groupe — et exactement quelles partitions se déplacent alors.
Le rééquilibrage est difficile à enseigner car il n’a de sens qu’en tant que séquence : révoquer, affecter, reprendre. Les diagrammes statiques réduisent cette séquence à une seule flèche. Ici, vous pouvez la parcourir et voir la propriété changer de mains une partition à la fois.
Pourquoi c’est important
La plupart des incidents de consommateurs en production sont en réalité des incidents de rééquilibrage — un déploiement qui ressemble à une panne, un max.poll.interval.ms trop court pour un lot lent, un assignor sticky qui déplace discrètement plus que prévu. Voir le rééquilibrage en mouvement, à la vitesse de votre choix, est le moyen le plus rapide de construire l’intuition qui rend ces incidents évidents a posteriori.
Ouvrez le simulateur, ajoutez et supprimez des consommateurs, et regardez le groupe se reformer.