kafka问题集（二）：__consumer_offsets topic的分区中有一个分区数据很多，多达1T

仅个人实践中所遇到的问题，若有不对的，欢迎交流！

---

一、场景描述

　　kafka集群中有几台突然挂了，后台日志显示设备空间满了，消息无法写入__consumer_offsets topic的分区中了。查看kafka数据目录下各个文件的大小，发现__consumer_offsets topic分区中有一个分区__consumer_offsets-5数据很多，多达1T，而其他分区只有4KB，相差巨大。且__consumer_offsets-5中保留了一年多的数据。什么情况？不应该自动清除吗？

二、问题分析

　　1）__consumer_offsets分区中数据量相差这么大？

　　　　__consumer_offsets topic的分区中存放的是consumer的offset等信息，其存放机制是用消费组id的hash值对分区数取模得到的。而我们只有一个消费组，所以会导致__consumer_offsets topic中的数据都写入一个分区。

　　2）__consumer_offsets-5保留的一年多数据，为什么没有被清理？不是已经设置了log.retention.hours、log.retention.bytes这些参数了吗？

　　　　首先说一点，__consumer_offsets的cleanup.policy策略是compact，而我们新建topic的清理策略默认是deleted，前者可以使用--describe 加上--topic  __consumer_offsets 可以看到，而后者可以在server.properties上可以看到。参数log.cleaner.enable参数对清理策略为compact起作用，且不是通过压缩（compact）文件达到减少数据的目的，通过测试，我们发现当文件属性不满足log.retention.hours、log.retention.bytes其中任何一项时，.log的数据文件文件就会被删除。当然也不是直接删除，是先将文件标记为-deleted，然后被清除。因为测试的时候被标记为-deleted后，再次执行ll命令时，文件已经被删除了，不知道删除时间间隔是否和参数log.retention.check.interval.ms有关，若有大佬知道欢迎留言分享。

　　　　知道文件清理规则后，检查log.cleaner.enable设置，为false，故将其改为true即可。

三、测试过程

　　修改参数log.segment.bytes的大小为1M，使得__consumer_offsets topic的分区中.log文件大小保留为1M；为了尽快确定log.cleaner.enable改为true是否会减小__consumer_offsets topic的分区中数据量的大小，需要修改触发删除的阈值。为减小阈值，修改log.retention.bytes为2M。但是在实际测试中我们发现当__consumer_offsets topic的分区中的.log大小为50M的时候还是没有触发删除。使用以下命令查看__consumer_offsets topic时发现，其默认的configure :segment.bytes大小为104857600，即为100M。

 kafka-topics --decribe --zookeeper localhost:/kafka --topic __consumer_offsets

　　通过查看kafka官网上有关segment bytes配置说明，发现删除时是以一个文件执行的，这个参数控制着文件大小。原文如下：

This configuration controls the segment file size for the log. Retention and cleaning is always done a file at a time so a larger segment size means fewer files but less granular control over retention.

　　使用命令将这个segment.bytes改为10M，发现__consumer_offsets-5分区的数据很快就变为400+KB了。修改命令如下：

 kafka-topics --zookeeper localhost:/kafka --alter --topic __consumer_offsets --config segment.bytes=

四、应急策略

　　当时因为是生产环境出现问题，来不及分析，要尽快将生产恢复正常，只能临时将日志等信息保留下来，以待后续分析。上述的分析还是自己后来查找资料知道的。当时采取的策略如下：

　　停止程序；增加磁盘；删除topic；新建topic；启动程序；

　　耗时近一个半小时，消费正常。这个步骤肯定是不行的，但是当时不是很懂，所以采取了临时的策略，欢迎大佬分享自己遇到这种问题时采取的措施！　　　　

五、参考文献

　　1）https://support.huawei.com/enterprise/zh/knowledge/KB1000676043/

　　2）https://www.sohu.com/a/136881236_487514