ApsaraMQ for Kafka:Client parameter configuration

acks

Détermine le nombre d'accusés de réception que le producteur exige du broker avant de considérer l'envoi comme réussi.

Valeur recommandée : 1 pour la plupart des charges de travail qui privilégient le débit à une durabilité stricte.

retries

Nombre maximal de tentatives de renvoi par le producteur en cas d'échec d'envoi. Une valeur plus élevée aide le producteur à récupérer après des pannes temporaires du broker, telles que les élections de leader. Combinez ce paramètre avec retry.backoff.ms pour contrôler le rythme des nouvelles tentatives.

retry.backoff.ms

Délai entre les tentatives d'envoi. Une valeur trop faible peut provoquer des tempêtes de nouvelles tentatives lors des basculements de broker.

batch.size

Taille maximale d'un lot par partition. Lorsqu'un lot atteint cette taille, le producteur l'envoie immédiatement.

Conservez la valeur par défaut de 16384 pour la plupart des charges de travail. Une valeur plus petite augmente le nombre de requêtes réseau et réduit le débit. Si vous augmentez batch.size, assurez-vous que buffer.memory est suffisamment grand pour accueillir les lots plus volumineux.

linger.ms

Temps maximal pendant lequel le producteur attend qu'un lot se remplisse avant de l'envoyer. Ce mécanisme fonctionne comme l'algorithme de Nagle dans TCP : dès qu'un lot atteint batch.size, il est envoyé immédiatement, indépendamment du minuteur d'attente. Si le lot est encore inférieur à batch.size lorsque linger.ms expire, le producteur envoie les données accumulées.

Une valeur linger.ms plus élevée améliore l'efficacité de la mise en lots et le débit, au détriment de la latence par message.

buffer.memory

Mémoire totale allouée par le producteur pour la mise en tampon des enregistrements non envoyés sur toutes les partitions. Si ce pool est épuisé, send() bloque ou lève une exception selon la valeur de max.block.ms. Un tampon sous-dimensionné entraîne une allocation mémoire lente, une réduction du débit ou des délais d'expiration d'envoi.

Unité : octets. Par défaut : 33554432 (32 Mo).

Formule de dimensionnement :

buffer.memory >= batch.size x number_of_partitions x 2

Par exemple, avec batch.size=16384 et 50 partitions :

16384 x 50 x 2 = 1,638,400 bytes (~1.6 MB minimum)

Si vous augmentez batch.size pour améliorer le débit, augmentez buffer.memory proportionnellement.

partitioner.class

Détermine comment le producteur attribue les enregistrements aux partitions. La stratégie de partitionnement « sticky » (adhésif) réduit le nombre de lots incomplets en remplissant le lot d'une partition avant de passer à la suivante.

Si votre client producteur est antérieur à la version 2.4, définissez explicitement le partitionneur sticky pour améliorer l'efficacité de la mise en lots.

fetch.min.bytes

Quantité minimale de données que le broker accumule avant de renvoyer une réponse de récupération. Une valeur plus grande réduit la fréquence des récupérations et la charge CPU du broker, ce qui améliore le débit mais augmente la latence de bout en bout des messages. Unité : octets.

Évaluez le taux de messages de votre producteur avant de définir cette valeur. Si les messages arrivent lentement, une valeur fetch.min.bytes élevée ajoute un délai inutile.

fetch.max.wait.ms

Temps maximal pendant lequel le broker attend d'accumuler fetch.min.bytes avant de renvoyer une réponse. Unité : millisecondes.

Le comportement varie selon le type de stockage :

• Stockage local : Le broker attend jusqu'à ce que fetch.min.bytes soit atteint ou que fetch.max.wait.ms expire, selon la première éventualité.

• Stockage cloud : Le broker renvoie une réponse immédiatement lorsque de nouvelles données arrivent, indépendamment de fetch.min.bytes.

max.partition.fetch.bytes

Quantité maximale de données renvoyées par le broker par partition lors d'une seule récupération. Unité : octets.

session.timeout.ms

Temps maximal entre les battements de cœur (heartbeats) avant que le broker ne considère le consommateur comme mort et ne déclenche un rééquilibrage.

max.poll.records

Nombre maximal d'enregistrements renvoyés lors d'un seul appel poll(). Si le consommateur ne peut pas traiter autant d'enregistrements avant l'échéance du prochain poll(), le broker le considère comme mort et déclenche un rééquilibrage.

Formule de dimensionnement :

max.poll.records < messages_per_thread_per_second x consumer_threads x session_timeout_seconds

Par exemple, avec 500 msg/s par thread, 4 threads et un délai d'expiration de session de 45 secondes :

500 x 4 x 45 = 90,000

Définissez max.poll.records en dessous de cette valeur pour garantir que le consommateur termine toujours le traitement avant l'expiration de la session.

max.poll.interval.ms

Intervalle maximal entre les appels consécutifs poll() avant que le broker ne retire le consommateur du groupe. Ce paramètre s'applique uniquement au client Java 0.10.1 et versions ultérieures, où les battements de cœur s'exécutent sur un thread séparé.

Formule de dimensionnement :

max.poll.interval.ms > time_per_record x max.poll.records

Dans la plupart des cas, la valeur par défaut de 300000 (5 minutes) est suffisante. Augmentez-la uniquement si votre logique de traitement est exceptionnellement lente.

enable.auto.commit

Contrôle si le consommateur valide automatiquement les offsets à intervalle fixe.

auto.commit.interval.ms

Intervalle pour les validations automatiques d'offsets lorsque enable.auto.commit est défini sur true.

Un intervalle plus court réduit la fenêtre de duplication des messages après un crash, mais augmente le nombre de requêtes de validation envoyées au broker.

auto.offset.reset

Détermine ce qui se produit lorsque le consommateur n'a aucun offset validé ou que l'offset validé n'est plus valide (par exemple, l'offset a été supprimé en raison des politiques de rétention).

Valeur recommandée : latest. L'utilisation de earliest amène le consommateur à retraiter tous les messages conservés chaque fois qu'un offset invalide est rencontré, ce qui peut entraîner un double traitement et une augmentation soudaine du retard du consommateur.

Si votre application gère les offsets manuellement (par exemple, en stockant les offsets dans une base de données externe), définissez ce paramètre sur none.