我们在Apache Kafka 2.3、2.4.0、2.4.1和2.5.0版本的主题中发现消息消失。我们在滚动部署集群时注意到了这一点，但不幸的是，这种情况并不是每次都发生，因此非常不一致。
有时我们会丢失一个主题内的所有消息，有时我们会丢失一个分区内的所有消息。当这种情况发生时，下面的日志是一个常量：
[2020-04-27 10:36:40,386] INFO [Log partition=test-lost-messages-5, dir=/var/kafkadata/data01/data] Deleting segments List(LogSegment(baseOffset=6, size=728, lastModifiedTime=1587978859000, largestTime=0)) (kafka.log.Log)还有一个以前的日志指出，此段的保留时间突破了24小时。在此示例中，消息是在部署前约12分钟生成的。
请注意，所有被错误删除的消息都有largestTime=0，而正确删除的消息则有一个有效的时间戳。从我们从文档和代码中读到的内容来看，largestTime似乎是用来计算给定的段是否达到了时间突破。
由于我们可以在Kafka的多个版本中观察到这一点，我们认为这可能与Kafka之外的任何东西有关。
有没有人知道为什么会发生这种情况？我们使用的是Zookeeper3. 6. 0。
2条答案
按热度按时间yv5phkfx1#
我们发现，原因与Kafka本身无关，而是与我们存放日志的体积有关，不过，下面的解释可能对教育有用：
详细地说，这是一个权限问题，在触发日志清除程序时，Kafka无法读取
.timeindex文件。这导致largestTime成为0，并导致一些邮件在保留时间之前被删除。每个主题分区被分成几个部分，最后一部分被存储到不同的
.log文件中，这些文件包含实际的消息。对于每个.log文件，都有一个.timeindex文件，其中包含偏移量和lastModifiedTime之间的Map。当Kafka需要检查一个段是否可删除时，它会搜索最近的偏移量
lastModifiedTime并将其存储为largestTime，然后检查是否达到了保留限制：currentTime - largestTime > retentionTime.如果是，则删除该段和相应的消息。
由于Kafka无法读取该文件，因此
largestTime为0，并且检查currentTime > retentionTime对于我们的1天保留始终为真。dzhpxtsq2#
确保所有Kafka代理和ZooKeeper节点之间的日期同步。
猛击命令：
date.比较年、日、小时和分钟。