共计 1472 个字符，预计需要花费 4 分钟才能阅读完成。
此法可能有危险，还请读完文章再操作。
本文中的命令能够在 Kafka 非启动状态下执行。
起因
Kafka 服务器在运行几个月后，存储空间耗尽了。剖析 Kafka 的占用空间状况，发现 Kafka 主动生成的“__consumer_offset”topic，占用了大量空间，它用于记录每个用户 topic 的生产偏移量。这一 topic 实用的清理规定与其余 topic 不同，某些非凡状况下，它可能始终得不到清理，耗尽服务器资源。
查看清理策略
因为服务器上的 Kafka 版本较老，这里应用的参数是 –zookeeper，而非−−bootstrap-server 参数。
应用以下命令查看清理策略：./kafka-configs.sh --zookeeper zk01:2181,zk02:2181,zk03:2181/kafka --entity-type topics --entity-name __consumer_offsets --describe
在这台服务器上，失去了上面后果：Configs for topics:__consumer_offsets are segment.bytes=104857600,cleanup.policy=compact,compression.type=uncompressed
翻译一下就是：每个文件块大小 100MB，清理策略为 压缩 ，压缩策略为 不压缩 。
那当然服务器空间会被用完了。
解决
首先，将解决__consumer_offset 的非凡清理策略删除：./kafka-configs.sh --zookeeper zk01:2181,zk02:2181,zk03:2181/kafka --entity-type topics --entity-name __consumer_offsets --alter --delete-config cleanup.policy
据说这样曾经能够让这里的清理策略与一般 topic 统一了，然而以防万一，再手动增加一组清理策略：./kafka-configs.sh --zookeeper zk01:2181,zk02:2181,zk03:2181/kafka --alter --entity-name __consumer_offsets --entity-type topics --add-config retention.ms=604800000./kafka-configs.sh --zookeeper zk01:2181,zk02:2181,zk03:2181/kafka --alter --entity-name __consumer_offsets --entity-type topics --add-config cleanup.policy=delete
这两行命令将__consumer_offset 的清理逻辑调整为“清理 7 天前数据，清理策略为删除”
之后，将 Kafka 运行起来，就能看见大量数据被标记删除，静静期待一分钟（如果延时参数没被调整的话），Kafka 就会主动将 7 天前的数据删除了。后续也不用操心服务器空间问题。
危险
尽管服务器空间问题失去了解决，但也有一个疑难：这是否会导致一些分区的 offset 记录隐没，导致反复生产？
举例来说：一个 topic 有 200 条记录，消费者在 8 天前生产了 100 条，这 8 天内无消费者生产，也无生产者生产。
那么如果这个消费者在明天去生产，因为之前的生产记录超过 7 天无变动，很有可能已被删除。那消费者是否会从 0 号音讯开始生产？
目前的环境中，topic 保留数据也有 7 天的限度，躲避了这个问题，但它的确有导致一些问题的可能。
