Qu'est-ce qui détermine la compensation des consommateurs Kafka?

Je suis relativement nouveau à Kafka. J'ai fait un peu d'expérimentation avec cela, mais certaines choses ne sont pas claires pour moi concernant la compensation des consommateurs. D'après ce que j'ai compris jusqu'à présent, lorsqu'un consommateur démarre, le décalage à partir duquel il commencera à lire est déterminé par le paramètre de configuration auto.offset.reset(corrigez-moi si je me trompe).

Maintenant, disons par exemple qu'il y a 10 messages (décalages de 0 à 9) dans le sujet, et qu'un consommateur en a consommé 5 avant qu'il ne tombe en panne (ou avant que je ne tue le consommateur). Puis dites que je redémarre ce processus de consommation. Mes questions sont:

1. Si le auto.offset.resetest défini sur smallest, va-t-il toujours commencer à consommer à partir de l'offset 0?

2. Si le auto.offset.resetest défini sur largest, va-t-il commencer à consommer à partir de l'offset 5?

3. Le comportement vis-à-vis de ce type de scénario est-il toujours déterministe?

N'hésitez pas à commenter si quelque chose dans ma question n'est pas clair. Merci d'avance.

C'est un peu plus complexe que vous ne l'avez décrit.
La auto.offset.resetconfiguration démarre UNIQUEMENT si votre groupe de consommateurs n'a pas de décalage valide commis quelque part (2 stockages de décalage pris en charge sont maintenant Kafka et Zookeeper), et cela dépend également du type de consommateur que vous utilisez.

Si vous utilisez un consommateur Java de haut niveau, imaginez les scénarios suivants:

1. Vous avez un consommateur dans un groupe de consommateurs group1qui a consommé 5 messages et est décédé. La prochaine fois que vous démarrez ce consommateur, il n'utilisera même pas cette auto.offset.resetconfiguration et continuera à partir de l'endroit où il est mort car il récupérera simplement le décalage stocké dans le stockage offset (Kafka ou ZK comme je l'ai mentionné).

2. Vous avez des messages dans un sujet (comme vous l'avez décrit) et vous démarrez un consommateur dans un nouveau groupe de consommateurs group2. Il n'y a pas de décalage stocké nulle part et cette fois, la auto.offset.resetconfiguration décidera de commencer par le début du sujet ( earliest) ou de la fin du sujet ( latest)

Une autre chose qui affecte la valeur de décalage à laquelle correspondra earliestet les latestconfigurations est la politique de rétention des journaux. Imaginez que vous avez un sujet avec une rétention configurée sur 1 heure. Vous produisez 5 messages, puis une heure plus tard, vous publiez 5 autres messages. Le latestdécalage restera toujours le même que dans l'exemple précédent, mais earliestcelui-ci ne pourra pas l'être 0car Kafka supprimera déjà ces messages et donc le premier décalage disponible sera 5.

Tout ce qui est mentionné ci-dessus n'est pas lié SimpleConsumeret chaque fois que vous l'exécutez, il décidera par où commencer à utiliser la auto.offset.resetconfiguration.

Si vous utilisez la version Kafka plus de 0,9, il faut remplacer earliest, latestavec smallest, largest.

Juste une mise à jour: à partir de Kafka 0.9 et les suivants, Kafka utilise une nouvelle version Java du consommateur et les noms des paramètres auto.offset.reset ont changé; À partir du manuel:

Que faire quand il n'y a pas de décalage initial dans Kafka ou si le décalage actuel n'existe plus sur le serveur (par exemple parce que ces données ont été supprimées):

au plus tôt : réinitialise automatiquement le décalage au décalage le plus ancien

dernier : réinitialise automatiquement le décalage au dernier décalage

none : lance une exception au consommateur si aucun décalage précédent n'est trouvé pour le groupe du consommateur

autre chose: jetez une exception au consommateur.

J'ai passé du temps à le trouver après avoir vérifié la réponse acceptée, alors j'ai pensé qu'il pourrait être utile pour la communauté de l'afficher.

De plus, il y a offsets.retention.minutes. Si le temps écoulé depuis le dernier commit est> offsets.retention.minutes, alors auto.offset.resetdémarre également