Offsets stockés dans Zookeeper ou Kafka?
Je suis un peu confus quant à l'endroit où les décalages sont stockés lors de l'utilisation de Kafka et Zookeeper. Il semble que les décalages dans certains cas soient stockés dans Zookeeper, dans d'autres cas, ils sont stockés dans Kafka.
Qu'est-ce qui détermine si le décalage est stocké dans Kafka ou dans Zookeeper? Et quels sont les avantages et les inconvénients?
NB: Bien sûr, je pourrais également stocker le décalage par moi-même dans un magasin de données différent, mais cela ne fait pas partie de l'image de ce message.
Quelques détails supplémentaires sur ma configuration:
- J'exécute ces versions: KAFKA_VERSION = "0.10.1.0", SCALA_VERSION = "2.11"
- Je me connecte à Kafka/Zookeeper en utilisant kafka-node depuis mon application NodeJS.
Les versions plus anciennes de Kafka (pré 0.9)) stockent les décalages dans ZK uniquement, tandis que la version plus récente de Kafka, par défaut, stocke les décalages dans une rubrique interne Kafka appelée __consumer_offsets (Une version plus récente peut cependant encore être validée sur ZK).
L'avantage de commettre des compensations pour le courtier est que le consommateur ne dépend pas de ZK et que les clients n'ont donc qu'à parler aux courtiers, ce qui simplifie l'architecture globale. De plus, pour les déploiements importants avec un grand nombre de consommateurs, ZK peut devenir un goulot d'étranglement tandis que Kafka peut gérer cette charge facilement (la validation des décalages revient à écrire dans un sujet et Kafka évolue très bien ici - en fait, par défaut __consumer_offsets Est créé avec 50 partitions IIRC).
Je ne suis pas familier avec NodeJS ou kafka-node - cela dépend de l'implémentation du client comment les compensations sont validées.
Pour faire court: si vous utilisez des courtiers 0.10.1.0, Vous pouvez valider des compensations pour le sujet __consumer_offsets. Mais cela dépend de votre client, s'il met en œuvre ce protocole.
Plus en détail, cela dépend de votre version de courtier et de client (et de l'API client que vous utilisez), car les clients plus âgés peuvent parler à de nouveaux courtiers. Tout d'abord, vous devez disposer d'une version courtier et client 0.9 Ou supérieure pour pouvoir écrire des décalages dans les rubriques Kafka. Mais si un ancien client se connecte à un 0.9, Il va encore valider les décalages vers ZK.
Pour les clients Java consommateurs:
Cela dépend de ce que les consommateurs utilisent: Avant 0.9, il y a deux "anciens consommateurs" à savoir "les consommateurs de haut niveau" et les "consommateurs de bas niveau". Les deux, valident les décalages directement dans ZK. Depuis 0.9, Les deux consommateurs ont été fusionnés en un seul consommateur, appelé "nouveau consommateur" (il unifie essentiellement l'API de bas niveau et de haut niveau des deux anciens consommateurs - cela signifie, dans 0.9 Il y a trois types de consommateurs). Le nouveau consommateur s'engage à compenser les courtiers (c'est-à-dire le sujet interne Kafka topic)
Pour faciliter la mise à niveau, il existe également la possibilité de "double commit" des compensations en utilisant l'ancien consommateur (à partir de 0.9). Si vous l'activez via dual.commit.enabled, Les décalages sont validés pour ZK et la rubrique __consumer_offsets. Cela vous permet de passer de l'ancienne API client à la nouvelle API client tout en déplaçant vos décalages de ZK vers la rubrique __consumer_offsets.
Tout dépend du consommateur que vous utilisez. Vous devez choisir le bon consommateur en fonction de votre version Kafka.
pour la version 0.8 les courtiers utilisent le HighLevelConsumer. Les décalages pour vos groupes sont stockés dans zookeeper.
Pour les courtiers 0.9 et plus, vous devez utiliser le nouveau ConsumerGroup. Les décalages sont stockés avec kafka brokers.
Gardez à l'esprit que HighLevelConsumer fonctionnera toujours avec les versions antérieures à 0.8 mais qu'elles sont obsolètes dans 0.10.1 et l'assistance disparaîtra probablement bientôt. ConsumerGroup propose des options de migration évolutives pour vous aider à passer de HighLevelConsumer si vous vous êtes engagé à l'utiliser.