我们的主题保留时间设置为7天（168小时）。生产者发送消息时，消息将实时消耗。一切都按预期进行。但是，最近在生产服务器上，作为操作系统补丁的一部分，Devops意外将时区从PST更改为EST。
重新启动Kafka服务器后，我们发现使用者消耗了很少（不是全部，而是随机的）旧消息。我们要求Devops将其更改回PST，然后重新启动。旧消息也再次在本周末再次出现。
我们还没有在较低的环境（开发，质量检查，舞台等）中看到此问题。
Kafka版本：kafka_2.12-0.11.0.2
我们非常感谢您的帮助。
添加更多信息...最近，我们的CentOS进行了补丁更新，并且管理员以某种方式从PST时区更改为EST，并启动了Kafka服务器...之后，我们的消费者开始看到偏移量为0的消息。调试之后，我发现4天后，时区更改和管理员从EST更改为PST。我们的消息生产者正在定期更改时区之前和之后发送消息。将时区从EST更改回PST后，Kafka服务器已重新启动，我看到了以下警告。
当我们从EST切换回PST时，发生了此日志：（server.log） [2018-06-13 18：36：34,430]由于需求失败，警告发现索引文件损坏：发现索引损坏，索引文件（/app/kafka_2.12-0.11.0.2/data/__consumer_offsets-21/00000000000000002076.index ）的大小为非零，但最后一个偏移量为2076，不大于基本偏移量2076。}。删除/app/kafka_2.12-0.11.0.2/data/__consumer_offsets-21/00000000000000002076.timeindex，/app/kafka_2.12-0.11.0.2/data/__consumer_offsets-21/00000000000000002076.index和/app/kafka_2.12 -0.11.0.2 / data / __ consumer_offsets-21 / 00000000000000002076.txnindex和重建索引...（kafka.log.Log）
我们将时区从EST更改为PST的三天后重新启动了使用者，并开始再次看到偏移量为0的使用者消息。
答案 0 :(得分：0)
我认为这是因为您将在Commit新偏移之前重新启动程序。
管理偏移量
对于每个消费者组，Kafka维护每个消费分区的承诺偏移量。使用者处理消息时，不会将其从分区中删除。相反，它只是使用称为提交偏移量的过程来更新其当前偏移量。
如果使用者在处理消息之后但在提交其偏移量之前失败，则提交的偏移量信息将不会反映对消息的处理。这意味着该消息将由该组中要分配分区的下一个使用者再次处理。
自动设置偏移量
提交偏移量的最简单方法是让Kafka使用者自动执行偏移量。这很简单，但是与手动提交相比，它提供的控制更少。默认情况下，使用者每5秒自动提交一次偏移。无论用户在处理消息方面取得什么进展，此默认提交每5秒发生一次。另外，当使用者调用
poll()时，这也会导致从先前调用返回到poll()的最新偏移量被提交（因为它可能已被处理）。如果提交的偏移量超过了消息的处理，并且出现了使用者故障，则可能某些消息可能未处理。这是因为处理从提交的偏移重新开始，该偏移比故障之前要处理的最后一条消息晚。因此，如果可靠性比简单性更重要，通常最好手动提交偏移量。
手动设置偏移量
如果
enable.auto.commit设置为false，则使用者将手动提交其偏移量。它可以同步或异步执行此操作。一种常见的模式是基于定期计时器提交最新处理的消息的偏移量。此模式意味着每个消息至少要处理一次，但是提交的偏移量永远不会超过正在积极处理的消息的进度。定期计时器的频率控制着使用者失败后可以重新处理的消息数。当应用程序重新启动或组重新平衡时，将从上次保存的提交偏移量中再次检索消息。已提交的偏移量是从中恢复处理的消息的偏移量。通常，这是最近处理的邮件的偏移量加一。
来自this article，我认为这很有帮助。
答案 1 :(得分：0)
与Kafka v2.3.0相同 您可以设置
"enable.auto.commit" : "true",// default is true as well
"auto.commit.interval.ms" : "1000"
这意味着，因此，每隔1秒钟，消费者将把其偏移量提交给Kafka，或者每次从指定的主题中获取数据时，它将提交最新的偏移量。
因此，您的Kafka消费者启动并经过1秒钟后，它将永远不会读取消费者接收并已提交的消息。此设置不需要重新启动Kafka服务器。