Résolution

Les utilisateurs d'Apache Kafka font généralement partie d'un groupe de consommateurs. Chaque utilisateur du groupe de consommateurs reçoit des messages provenant d'un sous-ensemble différent de partitions de la rubrique dans les cas suivants :

• Plusieurs consommateurs s'abonnent à un sujet.
• Ces consommateurs appartiennent au même groupe de consommateurs.

Lorsqu'un consommateur ne parvient pas à accéder au cluster, le coordinateur du groupe le retire du groupe de consommateurs. Ce processus déclenche un événement de rééquilibrage qui inclut les actions suivantes :

• Les consommateurs restants sont libérés de leurs partitions.
• Le coordinateur du groupe redistribue les partitions du sujet aux autres utilisateurs.

Votre groupe de consommateurs peut se rééquilibrer dans les conditions suivantes :

• Vous avez transféré la propriété de la partition d'un consommateur à un autre au sein d'un groupe de consommateurs.
• Vous avez ajouté un nouveau consommateur au groupe de consommateurs.
• Un consommateur s'arrête, est défaillant ou quitte le groupe de consommateurs.
• Vous avez modifié les rubriques et un réalignement des partitions a lieu.
• Il existe un problème de configuration client dans les abonnements aux groupes de consommateurs. Cela est dû à un décalage entre les sujets auxquels le groupe a souscrit et le sujet attribué à chaque consommateur individuel du groupe.

Les consommateurs d'un même groupe de consommateurs ne peuvent pas continuer à consommer des données tant que le rééquilibrage n'est pas terminé. Il s'agit du comportement par défaut de l'attribution de partitions. Vous pouvez éviter cela en modifiant la stratégie d'attribution de partition en CooperativeStickyAssignor.

Pour éviter que votre groupe de consommateurs ne se rééquilibre continuellement, essayez ce qui suit :

• Réduisez la valeur max.partition.fetch.bytes ou augmentez la valeur du délai d'expiration de session (session.timeout.ms) dans la configuration client. Le consommateur doit appeler poll() fréquemment pour éviter l'expiration du délai de session et le rééquilibrage ultérieur. Si la quantité de données renvoyée par un seul poll() est importante, le consommateur peut mettre beaucoup de temps à traiter les données. Cela signifie que le consommateur n'accède pas à l'itération suivante de la boucle de sondage à temps pour éviter l'expiration du délai de session.
  **Remarque :**La définition d'une valeur plus élevée pour session.timeout.ms réduit le risque de rééquilibrage accidentel. Toutefois, la détection d'une défaillance réelle peut prendre plus de temps. Ce paramètre est lié à heartbeat.interval .ms. Le paramètre heartbeat.interval.ms contrôle la fréquence à laquelle la méthode KafkaConsumer poll () envoie un battement de cœur au coordinateur du groupe. Toutefois, le paramètre session.timeout.ms contrôle la durée pendant laquelle un utilisateur peut rester sans envoyer de pulsations.
  Supposons, par exemple, que vous exécutiez Apache Kafka 0.10.1 ou version ultérieure et que vous gériez des enregistrements dont le traitement prend plus de temps. Dans ce cas, réglez max.poll.interval.ms pour gérer des délais plus longs entre les requêtes pour de nouveaux enregistrements.
• Assurez-vous que la valeur session.timeout.ms dans la configuration consommateur est inférieure à celle de group.max.session.timeout.ms dans la configuration du courtier.
• max.poll.interval.ms fixe une limite supérieure à la durée pendant laquelle le consommateur peut rester inactif avant de récupérer d'autres enregistrements. Par défaut, cette valeur est définie sur 5 minutes. Si cette valeur est réglée sur moins de 5 minutes, augmentez-la pour réduire le risque de rééquilibrage. Vous pouvez également envisager de diminuer max.poll.records en même temps que max.poll.interval.ms.
• heartbeat.interval.ms est le temps estimé entre les battements de cœur et le coordinateur des consommateurs lorsque vous utilisez les fonctionnalités de gestion de groupe de Kafka. Les battements cardiaques sont utilisés pour s'assurer que la session de l'utilisateur reste active. Ils facilitent le rééquilibrage lorsque de nouveaux consommateurs rejoignent le groupe ou le quittent. Cette valeur doit être définie sur une valeur inférieure à session.timeout.ms. Généralement, cette valeur doit être définie sur une valeur ne dépassant pas le tiers de session.timeout.ms. Vous pouvez choisir de réduire considérablement la valeur heartbeat.interval.ms afin de contrôler le temps attendu pour les rééquilibres normaux.
• Si vous avez récemment procédé à une réattribution de partition impliquant des modifications des partitions dans l'une des rubriques auxquelles le groupe de consommateurs est abonné, il est possible que le groupe de consommateurs rééquilibre son équilibre. Cela est dû au fait que les partitions concernées sont déplacées ou modifiées. Dans ce cas, évitez de redémarrer le coordinateur du groupe ou les autres courtiers Kafka. Vous devez attendre la fin de la réaffectation des partitions avant d'essayer d'empêcher le groupe de consommateurs de se rééquilibrer. Il est recommandé d'effectuer des réattributions de partitions pendant les périodes de faible trafic.

Dans certains cas, les informations suivantes peuvent s'afficher dans les journaux des courtiers Amazon MSK :

[2023-03-01 01:23:45,678] INFO [GroupCoordinator 1]: Preparing to rebalance group amazon.msk.canary.group.broker-1 in state PreparingRebalance with old generation 382660 (__consumer_offsets-21) (reason: Adding new member consumer-amazon.msk.canary.group.broker-1-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx with group instance id None) (kafka.coordinator.group .GroupCoordinator)

Ce message indique que amazon.msk.canary.group.broker-N est en état PreparingRebalance.

Les groupes amazon.msk.canary.group.broker-N sont des groupes de consommateurs internes qui sont ajoutés ou supprimés régulièrement pour vérifier l'état du cluster et les indicateurs de diagnostic. Ces groupes sont de taille négligeable et ne peuvent pas être supprimés. Vous pouvez ignorer ce message.

Informations connexes

Un groupe de consommateurs bloqué dans l'état PreparRebalance