ApsaraMQ for Kafka:Best practices for consumers

Éviter les rééquilibrages fréquents

Les rééquilibrages suspendent la consommation pendant la réaffectation des partitions. Des rééquilibrages fréquents perturbent le débit et augmentent la latence de traitement. Ils se produisent lorsque les signaux de maintien de connexion (heartbeats) des consommateurs expirent.

Pour éviter les rééquilibrages fréquents, ajustez les paramètres pertinents ou augmentez la vitesse de consommation. Pour des étapes de dépannage détaillées, consultez Pourquoi des rééquilibrages se produisent-ils fréquemment sur mon client consommateur ?

Nombre de partitions recommandé

Le nombre de partitions par défaut dans la console ApsaraMQ for Kafka est de 12, ce qui convient à la plupart des charges de travail. Lors de la mise à l'échelle, suivez ces recommandations :

Un groupe s'abonne à plusieurs topics

Un seul groupe de consommateurs peut s'abonner à plusieurs topics. Les messages de tous les topics abonnés sont distribués uniformément entre les consommateurs du groupe.

String topicStr = kafkaProperties.getProperty("topic");
String[] topics = topicStr.split(",");
for (String topic: topics) {
    subscribedTopics.add(topic.trim());
}
consumer.subscribe(subscribedTopics);

Plusieurs groupes s'abonnent à un topic

Plusieurs groupes de consommateurs peuvent s'abonner indépendamment au même topic. Chaque groupe reçoit tous les messages, et les groupes fonctionnent indépendamment sans s'affecter mutuellement.

Utilisez ce modèle lorsque différentes applications doivent traiter le même flux de données de manière indépendante, par exemple un groupe pour l'analytique en temps réel et un autre pour l'archivage des données.

Conserver un groupe par application

Utilisez un groupe de consommateurs dédié pour chaque application. Si une seule application doit exécuter différentes logiques de consommation, créez des fichiers de configuration distincts (par exemple, kafka1.properties et kafka2.properties) avec des valeurs group.id distinctes.

Faire correspondre les abonnements au sein d'un groupe

Tous les consommateurs d'un même groupe doivent s'abonner au même ensemble de topics. Des abonnements non concordants compliquent le dépannage et peuvent entraîner un comportement de rééquilibrage inattendu.

Validation automatique vs validation manuelle

ApsaraMQ for Kafka fournit deux paramètres pour valider les offsets des consommateurs :

Lorsque la validation automatique est activée, le client vérifie le temps écoulé depuis la dernière validation avant chaque poll. Si le temps écoulé dépasse auto.commit.interval.ms, il valide l'offset actuel.

Valider les offsets manuellement

Pour valider les offsets manuellement, définissez enable.auto.commit sur false et appelez la fonction commit(offsets) après le traitement de chaque lot.

Comportement de réinitialisation des offsets

Les offsets des consommateurs sont réinitialisés dans deux situations :

• Aucun offset validé n'existe, par exemple lorsqu'un consommateur se connecte à un broker pour la première fois.

• L'offset validé n'est pas valide, par exemple si l'offset maximum d'une partition est 10, mais que le consommateur tente de lire à partir de l'offset 11.

Contrôlez le comportement de réinitialisation sur les clients Java avec auto.offset.reset :

Implémenter une consommation idempotente

Si votre application est sensible aux duplications, par exemple pour les transactions financières ou le traitement des commandes, implémentez la déduplication au niveau de l'application :

1. Joignez une clé unique à chaque message lors de la production (par exemple, un ID de transaction).

2. Avant de traiter un message consommé, vérifiez si la clé a déjà été traitée.

3. Ignorez les messages dont les clés ont déjà été traitées.

Si votre application tolère des duplications occasionnelles (par exemple, l'agrégation de métriques ou l'ingestion de journaux), ignorez cette étape.

Causes courantes d'accumulation

Augmenter le débit de consommation

Ajoutez plus de consommateurs. Démarrez des instances de consommateurs supplémentaires (un thread par consommateur) ou déployez davantage de processus de consommateurs. Le nombre de consommateurs actifs ne peut pas dépasser le nombre de partitions ; les supplémentaires restent inactifs.

Utilisez un pool de threads pour le traitement. Découplez la récupération du traitement pour paralléliser le travail :

1. Définissez un pool de threads avec un nombre fixe de threads de travail.

2. Récupérez un lot de messages.

3. Soumettez chaque message au pool de threads pour un traitement concurrent.

4. Une fois toutes les tâches du lot terminées, récupérez le lot suivant.

Ce modèle maintient la boucle de poll réactive tout en distribuant le travail de traitement sur plusieurs threads.