Je l'ai mis en place d'un simple processeur d'enregistrement de Kafka lettre morte.
Il fonctionne parfaitement lors de l'utilisation des documents produits par le producteur Console.
Cependant, je trouve que nos applications Kafka Streams ne garantissent pas que la production d'enregistrements aux sujets de puits que les compensations seront incrémentée de 1 pour chaque enregistrement produit.
Arrière-plan du processeur lettre morte:
J'ai un scénario où les dossiers peuvent être reçues avant toutes les données nécessaires pour traiter sa publication. Lorsque les dossiers ne sont pas adaptés pour le traitement des flux, ils sont app passer à un sujet de lettre morte au lieu de continuer à couler en aval. Lorsque de nouvelles données sont publiées, nous vidons les derniers messages de l'arrière sujet de lettre morte au sujet de la source de l'application de flux de retraitement avec les nouvelles données.
Le processeur Dead Letter:
- Au début de l'application d'exécution enregistre les décalages de fin de chaque partition
- Les marques de compensations se terminant le point d'arrêter le traitement des dossiers pour un sujet Dead Letter donnée à éviter boucle infinie si les dossiers régénérées Retour à la rubrique Dead Letter.
- L'application reprend des derniers produits Décalages par l'exécution précédente par des groupes de consommateurs.
- Application utilise les transactions et
KafkaProducer#sendOffsetsToTransactionde commettre les derniers produits compensations.
Pour suivre lorsque tous les enregistrements de ma gamme sont traitées pour une partition du sujet de mon service compare son dernier produit décalé par rapport au producteur au consommateur carte enregistrée de mettre fin à des compensations. Quand on arrive à la terminaison compenser les pauses de consommation partition via KafkaConsumer#pauseet quand toutes les partitions sont mis en pause ( ce qui signifie qu'ils ont atteint la fin enregistrée offset) puis appelle sa sortie.
L' API consommateurs Kafka États:
Offsets et position des consommateurs Kafka maintient une position numérique pour chaque enregistrement dans une partition. Ce décalage agit comme un identifiant unique d'un enregistrement dans cette partition, et représente aussi la position du consommateur dans la partition. Par exemple, un consommateur qui est à la position 5 a consommé des enregistrements avec des décalages 0 à 4 et ensuite recevoir le record avec 5 offset.
L' API du producteur Kafka références suivant est toujours +1 décalées aussi bien.
Envoie une liste des compensations spécifiées au coordonnateur du groupe de consommateurs, ainsi que des marques les compensations dans le cadre de la transaction en cours. Ces compensations seront considérés comme engagés que si la transaction est validée avec succès. Le décalage ENGAGE devrait être le message suivant votre application consommera, à savoir lastProcessedMessageOffset + 1.
Mais vous pouvez voir clairement dans mon débogueur que les enregistrements consommés pour une seule partition sont tout sauf incrémentée 1 à un moment ... 
Je pensais que cela était un problème de configuration Kafka, comme , max.message.bytesmais pas vraiment du sens. Alors je pensais que peut - être il est de rejoindre , mais ne voit pas d' une façon qui changerait la façon dont le producteur fonctionnerait.
Je ne sais pas si elle est pertinente ou non, mais toutes nos applications Kafka utilisent Avro et schéma d'enregistrement ...
Si les décalages incrémenter toujours par 1 quelle que soit la méthode de production ou est-il possible que l'utilisation des flux Kafka API ne propose pas les mêmes garanties que les clients normaux entre producteurs et consommateurs?
Est-il juste quelque chose tout à fait que je suis absent?
Il est pas un contrat API officielle que les compensations de message sont augmentés par un, même si les JavaDocs indiquent ce (il semble que les JavaDocs devraient être mis à jour).
Si vous ne l'utilisez pas les transactions, vous obtenez soit à-moins une fois la sémantique ou aucune garantie (certains appellent cela à la plus-fois la sémantique). Au-moins une fois, les enregistrements peuvent être écrits deux fois et ainsi, les compensations pour deux messages consécutifs ne sont pas vraiment augmenté par un comme l'écriture en double « consume » deux décalages.
Si vous utilisez des transactions, chaque livraison (ou abort) d'une transaction écrit un commit (ou abort) marqueur dans le sujet - ces marqueurs transactionnels aussi « consomment » un décalage (c'est ce que vous observez).
Ainsi, en général, vous ne devriez pas compter sur les compensations consécutifs. La seule garantie que vous obtenez est que chaque décalage est unique dans une partition.