卡夫卡流和消费者群体奇怪的行为

时间:2017-10-02 19:39:14

标签: apache-kafka kafka-consumer-api apache-kafka-streams

我将两个高级问题分解为更多个别问题,这两个问题都涉及Apache Kafka Streams API正在创建和使用的消费者群体。

首先,是kafka-consumer-group.sh脚本的输出。我得到了奇怪的输出,虽然它们似乎连接到特定的组/主题/分区,但并没有真正告诉我特定消费者在哪里:

TOPIC    PARTITION    CURRENT-OFFSET    LOG-END-OFFSET    LAG
STANDARD_DATA                  9          11              11              0          myConsumer-7fc71848-465b-4817-93b3-42b9ba290dcd-StreamThread-1-consumer-4fd9dc15-d8a7-4598-85a9-3761ae6a747b/1.1.1.1                 myConsumer-7fc71848-465b-4817-93b3-42b9ba290dcd-StreamThread-1-consumer
STANDARD_DATA                  0          4               11              7          myConsumer-13b61e5a-6289-45db-844b-3ef8c5a26782-StreamThread-5-consumer-28e1c7bf-860d-44d6-bf58-5e0ff875587c/1.1.1.1                 myConsumer-13b61e5a-6289-45db-844b-3ef8c5a26782-StreamThread-5-consumer
STANDARD_DATA                  4          -               10              -          myConsumer-7fc71848-465b-4817-93b3-42b9ba290dcd-StreamThread-4-consumer-a3023af6-eafb-4633-85f1-048c20c4dfb3/1.1.1.1                 myConsumer-7fc71848-465b-4817-93b3-42b9ba290dcd-StreamThread-4-consumer
STANDARD_DATA                  5          -               10              -          myConsumer-7fc71848-465b-4817-93b3-42b9ba290dcd-StreamThread-3-consumer-a81f1399-1fc4-4579-b24f-fa8fee01fabf/1.1.1.1                 myConsumer-7fc71848-465b-4817-93b3-42b9ba290dcd-StreamThread-3-consumer
STANDARD_DATA                  3          -               12              -          myConsumer-13b61e5a-6289-45db-844b-3ef8c5a26782-StreamThread-2-consumer-6a83bfcc-2c6e-4e9d-a819-029ac8c6ae17/1.1.1.1                 myConsumer-13b61e5a-6289-45db-844b-3ef8c5a26782-StreamThread-2-consumer
STANDARD_DATA                  8          12              12              0          myConsumer-13b61e5a-6289-45db-844b-3ef8c5a26782-StreamThread-4-consumer-6d46bed3-70c4-4c7f-8e53-f9591192bc3f/1.1.1.1                 myConsumer-13b61e5a-6289-45db-844b-3ef8c5a26782-StreamThread-4-consumer
STANDARD_DATA                  7          -               11              -          myConsumer-13b61e5a-6289-45db-844b-3ef8c5a26782-StreamThread-3-consumer-5313315b-ded9-4fe7-ac9d-d8d5b20dd5b9/1.1.1.1                 myConsumer-13b61e5a-6289-45db-844b-3ef8c5a26782-StreamThread-3-consumer
STANDARD_DATA                  2          10              10              0          myConsumer-b9402faf-4b37-479f-82be-a17eaa180c62-StreamThread-1-consumer-c08a648f-548e-47a8-8bc5-7b6fa3bc1fb5/1.1.1.1                  myConsumer-b9402faf-4b37-479f-82be-a17eaa180c62-StreamThread-1-consumer
STANDARD_DATA                  1          2               10              8          myConsumer-7fc71848-465b-4817-93b3-42b9ba290dcd-StreamThread-2-consumer-08d99679-d430-4e9f-a3b9-11e558ca34a4/1.1.1.1                 myConsumer-7fc71848-465b-4817-93b3-42b9ba290dcd-StreamThread-2-consumer
STANDARD_DATA                  6          -               12              -          myConsumer-7fc71848-465b-4817-93b3-42b9ba290dcd-StreamThread-5-consumer-666040f8-d4d0-49e9-9db6-c6efee49ebe1/1.1.1.1                 myConsumer-7fc71848-465b-4817-93b3-42b9ba290dcd-StreamThread-5-consumer
  1. 为什么某些CURRENT-OFFSETS(第3列)和LAG(第4列)显示为' - '什么时候我可以直接查询Kafka的API来区分它们实际上已被追上了?
  2. (通过golang API查询)

    4                      myConsumer-7fc71848-465b-4817-93b3-42b9ba290dcd-StreamThread-4-consumer-a3023af6-eafb-4633-85f1-048c20c4dfb3    OFFSET: 10        LOG-END: 10                LAG: 0
    
    1. 另外,为什么这种偏移不会在日志中显示出来(也就是说,它应该被追赶)?
    2. 我的第二个高级问题是溪流问题。我们有一个流处理工作,在随机时间(主要是在重启期间),重置为特定主题中可用的最早偏移。在整个代码中没有“重置”,并且没有触及OFFSET_RESET。我也可以确认我们没有使用'确切一次',所以我不确定这些偏移重置究竟在哪里发挥作用。

      再次,基本上:

      流程正在通过数据进行搅拌,某些事情发生〜然后我们的偏移量又回到地面0,再次处理。在决定重置之前,这可能会持续数天到数周,因此会发生抵消。

1 个答案:

答案 0 :(得分:2)

关于kafka-consumer-groups.sh的输出:CURRENT-OFFSET中的-表示此分区没有已提交的偏移量。这意味着,滞后也无法计算(因此,你也会得到-

如果我正确阅读你的陈述,如果你用golang查询偏移量,它会显示分区4偏移10,与kafka-consumer-groups.sh显示的不同 - 不确定为什么会这样...

关于重置的偏移:您可能需要增加代理配置offsets.retention.minutes - 默认为24小时(参见https://docs.confluent.io/current/streams/faq.html#why-is-my-application-re-processing-data-from-the-beginning)。

另请注意,Streams API使用默认重置策略“earliest”(与使用“latest”作为默认值的Consumer API相反)。您可以通过StreamsConfighttps://docs.confluent.io/current/streams/developer-guide.html#non-streams-configuration-parameters

更改Streams API中的重置政策