Différence entre session.timeout.ms et max.poll.interval.ms pour Kafka 0.10.0.0 et versions ultérieures
Je ne comprends pas pourquoi nous avons besoin des deux session.timeout.ms et max.poll.interval.ms et quand utiliserions-nous l'un ou l'autre ou les deux? Il semble que les deux indiquent que la limite supérieure du temps que le coordonnateur attendra pour obtenir le battement de coeur du consommateur avant de supposer qu'elle est morte.
De plus, comment se comporte-t-il pour les versions 0.10.1.0+ basées sur KIP-62 ?
Avant KIP-62, il n’existait que session.timeout.ms (C.-à-d. Kafka 0.10.0 Et antérieur)). max.poll.interval.ms Est introduit via KIP-62 (partie de Kafka 0.10.1).
KIP-62, permet de découpler les pulsations des appels à poll() via un thread de pulsation en arrière-plan, ce qui permet un temps de traitement plus long (c'est-à-dire un temps entre deux poll()) consécutives à l'intervalle de pulsation.
Supposons que le traitement d'un message prenne 1 minute. Si battement de cœur et interrogation sont couplés (c'est-à-dire avant KIP-62), vous devrez définir session.timeout.ms Sur une valeur supérieure à 1 minute pour empêcher le délai d'expiration du consommateur. Toutefois, si le consommateur décède, la détection du consommateur défaillant prend également plus d'une minute.
KIP-62 dissocie les interrogations et les pulsations, ce qui permet d'envoyer des pulsations entre deux interrogations consécutives. Maintenant, vous avez deux threads en cours d'exécution, le thread de pulsation et le thread de traitement et, par conséquent, KIP-62 a introduit un délai d'expiration pour chacun. session.timeout.ms Est pour le thread de pulsation alors que max.poll.interval.ms Est pour le thread de traitement.
Supposons que vous définissiez session.timeout.ms=30000, Ainsi, le thread de pulsation consommateur doit envoyer une pulsation au courtier avant l'expiration de ce délai. D'autre part, si le traitement d'un seul message prend 1 minute, vous pouvez définir max.poll.interval.ms Plus d'une minute pour donner plus de temps au thread de traitement pour traiter un message.
Si le thread de traitement meurt, il faut max.poll.interval.ms Pour le détecter. Cependant, si le consommateur entier meurt (et qu'un thread de traitement en train de mourir meurt probablement, il bloque tout le consommateur, y compris le thread de pulsation), il ne prend que session.timeout.ms Pour le détecter.
L'idée est de permettre la détection rapide d'un consommateur défaillant, même si le traitement lui-même prend beaucoup de temps.