Apache Kafka关于合并云-分区主题和消费者滞后中的不相干偏移

Question

我发现在合流云上使用Kafka时有一个奇怪的行为。我创建了一个主题，其分区值默认为6。

我的系统由一个Java Producer应用程序和一个Kafka Streams应用程序组成，前者向该主题发送一条消息，后者读取该主题并执行每个消息的操作。

-----------------------          --------            -----------
| Kafka Java Producer |  ---->  | topic | ---->      | KStream |
-----------------------          --------            -----------

目前，我只启动了Kafka Streams应用程序的一个实例，因此consumer组只有一个成员。

null

events.foreach { key, value ->
    logger.info("--------> Processing TimeMetric {}", value)
    //Store in DB

日志

[-StreamThread-1]uration$$EnhancerBySpringCglib$$E72E3F00:---------->正在处理事件{“...

[-StreamThread-1]uration$$EnhancerBySpringCglib$$E72E3F00:---------->正在处理事件{

null

Answer 1

对于第一个问题，有两种可能性（尽管通过阅读第二个问题，您似乎在使用事务）：

>

如果您没有使用一次准确的语义，生产者可能会发送多个消息，因为在电线上无法控制之前发送的消息。这样，Kafka默认的至少一次语义可能会因为那些重复的消息而增加你的偏移量>+1。

如果您使用的是一次准确语义或事务，则事务的每个事件都会在主题中写入一个标记，以便进行内部控制。这些标记是+2增加的原因，因为它们也存储在主题中（但被使用者避免）。Confluent的交易指南也提供了一些关于这种行为的信息：

然后协调器开始第2阶段，将事务提交标记写入作为事务一部分的主题分区。

这些事务标记不向应用程序公开，而是由read_committed模式下的使用者用来从中止的事务中筛选出消息，并且不返回作为打开事务一部分的消息（即，那些在日志中但没有与之关联的事务标记的消息）。

一旦写入标记，事务协调器将事务标记为“完成”，生产者就可以开始下一个事务。

一般说来，你不应该关心偏移量，因为它不是一个确定的指南。例如，重试、重复或事务标记会使偏移量与您预期的生产者不同，但您不应为此担心；你的消费者会这样做的，他们只会处理“真实的”消息。

关于问题2，这是一个已知的问题：https://issues.apache.org/jira/browse/kafka-6607

引用JIRA：

希望有帮助！