La différence entre la session.délai d'attente.ms et max.sondage.d'intervalle.ms pour Kafka 0.10.0.0 et versions ultérieures

Je ne sais pas pourquoi nous avons besoin des deux session.timeout.ms et max.poll.interval.ms et quand nous utilisons l'un ou l'autre ou les deux à la fois? Il semble que les deux paramètres indiquent la limite supérieure sur le temps, le coordonnateur de l'attendre pour obtenir le battement de cœur de la part du consommateur avant l'hypothèse qu'il est mort.

Aussi comment se comporter pour les versions 0.10.1.0+ basé sur KIP-62?

  • Est-ce pour Kafka se Connecter uniquement?
InformationsquelleAutor Deeps | 2016-09-27
  1. 96

    Avant de KIP-62, il est seulement session.timeout.ms (c'est à dire, Kafka 0.10.0 et antérieures). max.poll.interval.ms est introduite par KIP-62 (partie de Kafka 0.10.1).

    KIP-62, découple les battements de cœur à partir d'appels à poll() par l'intermédiaire d'un fond de pulsation fil, ce qui permet un temps de traitement plus long (c'est à dire, le temps entre deux années consécutives poll()) que l'intervalle d'interrogation.

    Assumer le traitement d'un message prend 1 minute. Si le rythme cardiaque et le sondage sont couplés (c'est à dire, avant de KIP-62), vous aurez besoin de mettre session.timeout.ms de plus de 1 minute pour empêcher le consommateur de temps. Cependant, si les consommateurs ne meurt pas, il prend également plus de temps de 1 minute pour détecter l'échec de la consommation.

    KIP-62 dissocie d'interrogation et le rythme cardiaque permettant d'envoyer battement de coeur entre deux années consécutives dans les sondages. Maintenant, vous avez deux threads en cours d'exécution, le battement de coeur de thread et de la thread de traitement et donc, KIP-62 introduit un délai d'attente pour chaque. session.timeout.ms est pour le battement de coeur de filetage max.poll.interval.ms est pour le thread de traitement.

    Assumer, vous définissez session.timeout.ms=30000, ainsi, le consommateur battement de coeur thread doit être envoyé à un battement de cœur pour le courtier avant cette expiration de la période. D'autre part, si le traitement d'un message unique prend 1 minutes, vous pouvez définir max.poll.interval.ms plus qu'une minute pour donner le thread de traitement de plus de temps pour traiter un message.

    Si le thread de traitement meurt, il prend max.poll.interval.ms de le détecter. Toutefois, si l'ensemble de la consommation meurt (et mourant de traitement de fil probablement une panne de l'ensemble des consommateurs, y compris le rythme cardiaque thread), il ne faut que session.timeout.ms à détecter.

    L'idée est de permettre une détection rapide de l'échec de la consommation, même si le traitement dure assez longtemps.

    • Merci Matthias, cela efface beaucoup de la confusion. Le fait que max.poll.interval.ms est présenté dans le cadre de kafka v 0.10.1 l'a n'était pas évident. Dans ce cas, cependant, des sons comme session.timeout.ms pourrait alors être remplacé par heartbeat.interval.ms que ce dernier implique clairement qu'il est destiné à la ou au moins l'un de ces symptômes devraient disparaître?
    • Si vous avez des demande de ce genre, vous devez écrire à Kafka dev mailing list. C'est une décision communautaire... Mais je suppose que, en gardant session.timeout.ms pour la compatibilité descendante raison en est un bon choix. Et "battement de cœur.d'intervalle.ms" n'est pas parfait car il n'indique pas qu'il y a un délai d'attente impliqués. Peut-être "battement de cœur.max.d'intervalle.ms" serait mieux (encore, à l'aide de "timeout" dans le nom du paramètre est un indicateur fort de la sémantique et serait perdu.)
    • J'en ai un similaire question sur la base de session.timeout.ms dans lequel ma consommation est de donner une exception lors de la perpétration d'offsets. Je voulais voir si vous pouvez m'aider.
    • Je ne suis pas encore clair pourquoi nous avons besoin des deux. Disons que le consommateur travail prend beaucoup de temps pour consommer un message. e.g consommateur envoie le message à un tiers, via un processus très lent appel reste. Le consommateur peut toujours envoyer cœur bat à intervalles réguliers pour le courtier à l'aide d'un thread d'arrière-plan. max.sondage.d'intervalle.ms semble redondant.
    • Supposons que votre consommateur meurt (ou il y a un bug avec une boucle infinie), mais le thread d'arrière-plan conserve heartbeating. Pour ce cas, les aurait pas de progrès, mais il serait détectée. Par conséquent, max.poll.interval.ms est une lande à vérifier pour votre principal thread de traitement, ayant les deux configs, vous permet de détecter les "durs échecs" (à la fois du rythme cardiaque et thread principal meurent rapidement, et de simplifier votre code pour le traitement long (avec une seule config vous avez une longue période de détention de temps ou de code complexe pour déclencher des battements du cœur pendant le traitement "à la main")
    InformationsquelleAutor Matthias J. Sax