У меня есть приложение kafka streams (Kafka v1.1.0) с несколькими (24) темами.Четыре из этих тем являются исходными темами, а остальные - темами назначения.Похоже, они обработали данные об изменении системного времени на предыдущую дату.У меня есть конфиги брокера по умолчанию, например:
auto.offset.reset = latest
offsets.retention.minutes = 1440 #1 day
log.retention.hours = 168 #7 days
Я подробно рассмотрел следующие ссылки и ссылки, размещенные в ответах:
1) Переработка Kafka Streamстарые сообщения о перебалансировке
2) Как истекает смещение для группы потребителей Apache Kafka?
3) https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days
В следующем обсуждении JIRA также говорится об этой проблеме:
https://issues.apache.org/jira/browse/KAFKA-3806
После прочтения этого я понял, в каких случаях потребители потоков могут повторно обрабатывать данные.
Тем не менее, с конфигами по умолчанию, упомянутыми выше (те, которые используются для моей настройки), если смещения будут потеряны, т.е. offsets.retention.minutes
истекло, тогда потребитель будет перебалансирован и начнёт с последнего зафиксированного смещения (которое не будет ничем) и любогоновые входящие данные будут обрабатываться как есть.В этом сценарии не должно быть никакой повторной обработки данных и, следовательно, не должно быть дубликатов.
В случае изменения системного времени, однако, может быть вероятность того, что смещения будут несовместимыми, то есть возможны смещения исходной темы.иметь CommitTime
более ранней даты после CommitTime
более поздней даты.В этом случае, если у темы низкий трафик и нет данных, полученных по ней более чем offsets.retention.minutes
, ее смещение больше не будет доступно, а другая тема с большим трафиком будет иметь смещение в __consumer_offsets
теме.
Как поведет себя потребитель потока в этом сценарии?Есть ли вероятность дублирования в этом сценарии.Я действительно смущен этим.Любая помощь будет по достоинству оценена.