ApsaraMQ for Kafka:Dépannage des rééquilibrages fréquents des consommateurs dans ApsaraMQ for Kafka

Symptôme

Des rééquilibrages se produisent fréquemment sur votre client consommateur lorsque vous utilisez ApsaraMQ for Kafka.

Cause

La cause profonde dépend de la version de votre client, car le mécanisme de heartbeat diffère d'une version à l'autre.

• Clients antérieurs à la version 0.10.2 : Il n'existe pas de thread dédié au heartbeat. Les heartbeats sont envoyés lors de l'appel à poll(). Lorsque le traitement des messages prend plus de temps que la valeur définie pour session.timeout.ms, le broker ne reçoit aucun heartbeat, retire le consommateur du groupe et déclenche un rééquilibrage.

• Clients de version 0.10.2 ou ultérieure : Un thread dédié au heartbeat s'exécute indépendamment du traitement des messages. Toutefois, si le consommateur n'appelle pas poll() dans l'intervalle défini par max.poll.interval.ms (par défaut : 5 minutes), le client quitte le groupe de consommateurs et un rééquilibrage est déclenché. La valeur par défaut de max.poll.interval.ms est de 5 minutes. Cela se produit généralement lorsque le traitement d'un lot de messages prend trop de temps.

Les messages d'erreur suivants sont couramment associés aux rééquilibrages. L'identification de l'erreur spécifique peut vous aider à localiser plus rapidement la cause profonde :

• **NOT_COORDINATOR / join group failed** : Indique que le Group Coordinator a changé (par exemple, en raison d'un basculement du broker) ou qu'un délai d'expiration du heartbeat a entraîné le retrait du consommateur du groupe. Le consommateur tente de rejoindre le groupe, ce qui déclenche un rééquilibrage.

• **MemberIdRequiredException / consumer poll timeout** : Pour les clients antérieurs à la version 0.10.2, cela est généralement causé par un consommateur bloqué qui empêche l'envoi du heartbeat. Pour les clients de version 0.10.2 ou ultérieure, cela indique que le traitement lent des messages a amené le consommateur à dépasser max.poll.interval.ms sans appeler poll(), incitant le client à quitter le groupe de consommateurs.

• **CommitFailedException** : Indique que le consommateur a mis trop de temps à traiter les messages ou n'a pas pu envoyer de heartbeats à temps. Le broker retire le consommateur du groupe (déclenchant un rééquilibrage) avant que la validation de l'offset ne puisse être achevée.

Paramètres clés

Les paramètres suivants contrôlent le comportement de rééquilibrage :

Solutions

1. Ajustez les valeurs des paramètres/@cmd

   Configurez les paramètres suivants en fonction de la version de votre client :

   **session.timeout.ms**

   Version du client	Valeur recommandée
   Antérieure à 0.10.2	Supérieure au temps nécessaire pour traiter un lot de messages, mais inférieure ou égale à 30 secondes. 25 secondes est recommandé.
   0.10.2 ou ultérieure	Conservez la valeur par défaut de 10 secondes.

   **max.poll.records**

   Définissez cette valeur bien en dessous du résultat de la formule suivante :

   max.poll.records << messages_per_thread_per_second * number_of_threads * max.poll.interval.ms

   **max.poll.interval.ms** (version 0.10.2 ou ultérieure uniquement)

   Définissez cette valeur au-dessus du résultat de la formule suivante :

   max.poll.interval.ms > max.poll.records / (messages_per_thread_per_second * number_of_threads)

   **heartbeat.interval.ms** (version 0.10.2 ou ultérieure)

   Définissez heartbeat.interval.ms à une valeur ne dépassant pas 10 000 millisecondes (10 secondes). Cette valeur contrôle la fréquence à laquelle le consommateur envoie des heartbeats au broker et doit toujours être inférieure à session.timeout.ms. Une pratique courante consiste à la définir à un tiers de session.timeout.ms.

   Configuration des paramètres dans Spring Kafka

   Si vous utilisez Spring Kafka, vous pouvez configurer tous les paramètres ci-dessus dans votre fichier application.yml :

   spring:
     kafka:
       consumer:
         properties:
           session.timeout.ms: 10000
           heartbeat.interval.ms: 3000
           max.poll.interval.ms: 300000
           max.poll.records: 50

   Ajustez les valeurs en fonction de votre débit de consommation. La valeur de max.poll.interval.ms doit dépasser le temps nécessaire pour traiter un seul lot de messages max.poll.records.

2. Améliorez la vitesse de consommation et séparez les threads de traitement/@cmd

   Déléguez le traitement des messages à un thread dédié afin que le thread du consommateur puisse appeler poll() selon le calendrier prévu. Cela évite qu'un traitement lent ne bloque les heartbeats ou ne dépasse l'intervalle de poll.

3. Réduisez le nombre de topics par groupe de consommateurs/@cmd

   Limitez chaque groupe de consommateurs à un abonnement de cinq topics maximum. Pour une stabilité optimale, abonnez-vous à un seul topic par groupe de consommateurs.

4. Mettez à niveau vers la version 0.10.2 ou ultérieure/@cmd

   Les clients antérieurs à la version 0.10.2 ne disposent pas de thread dédié au heartbeat, ce qui les rend vulnérables aux expirations de heartbeat lors d'un traitement intensif. La mise à niveau vers la version 0.10.2 ou ultérieure découple l'envoi des heartbeats du traitement des messages et élimine cette catégorie de rééquilibrage.

FAQ

Q : Comment réduire temporairement les rééquilibrages pour accélérer la consommation des messages en attente ?

Suivez les étapes ci-dessous pour minimiser les rééquilibrages et vider le backlog de messages aussi rapidement que possible :

1. Utilisez la version 0.10.2 ou ultérieure du client. Les clients antérieurs à la version 0.10.2 ne disposent pas de thread dédié au heartbeat et sont sujets aux rééquilibrages sous forte charge. Effectuez la mise à niveau avant d'ajuster les autres paramètres.

2. **Augmentez max.poll.interval.ms** à une valeur supérieure au temps maximal nécessaire pour traiter un seul lot de messages. Cela empêche le consommateur d'être considéré comme non réactif lors d'un traitement intensif.

3. **Diminuez max.poll.records** pour réduire le nombre de messages récupérés par appel à poll(). Des lots plus petits se traitent plus rapidement, réduisant ainsi le risque de dépasser max.poll.interval.ms.

4. Réduisez le nombre de topics auxquels chaque groupe de consommateurs est abonné. Limitez les abonnements à cinq topics ou moins. Pour une stabilité optimale, abonnez-vous à un seul topic par groupe de consommateurs.

5. Évitez de bloquer le thread du consommateur. Déplacez la logique de traitement des messages vers un thread asynchrone distinct afin que le thread du consommateur reste libre d'appeler poll() selon le calendrier prévu.