尽管这个问题已经提了几个月了，但我只是在为自己的问题做研究时偶然发现的。我创建了一个简单的示例来说明压缩是如何与java一起工作的，也许它对您也有帮助：
https://gist.github.com/anonymous/f78184eaeec3ee82b15182aec24a432a
此外，通过查阅文档，我在主题级别上使用了以下配置，以便尽可能快地进行压缩：

min.cleanable.dirty.ratio=0.01
cleanup.policy=compact
segment.ms=100
delete.retention.ms=100

在运行时，这个类显示压缩是有效的—在主题上只有一条消息具有相同的键。
通过适当的设置，这将在命令行上重现。

实际上，只有当原木的数量达到一个非常高的数值（例如100万）时，原木的压缩才是可见的。所以，如果你有那么多数据，那就好了。否则，使用配置更改，您可以将此限制减少到100条消息，然后您可以看到在具有相同密钥的消息中，只有最新的消息会出现，前一条消息会被删除。如果每次都有完整的数据快照，最好使用日志压缩，否则可能会丢失具有相同关联键的以前的日志，这可能很有用。

最好也看看log.roll.hours，默认情况下是168小时。简单地说：即使你没有那么活跃的主题，你不能在一周内填满最大的段大小（默认情况下，正常主题为1g，偏移主题为100m），你也会有一个大小低于log.segment.bytes的封闭段。该路段可在下一个转弯时压实。

为了从cli检查topics属性，您可以使用kafka topics cmd：
https://grokbase.com/t/kafka/users/14aev0snbd/command-line-tool-for-topic-metadata

你可以用Kafka来做。我是从docker那里查的( confluentinc/cp-enterprise-kafka:6.0.0 ).

$ docker-compose exec kafka kafka-topics --zookeeper zookeeper:32181 --describe --topic count-colors-output
Topic: count-colors-output  PartitionCount: 1   ReplicationFactor: 1    Configs: cleanup.policy=compact,segment.ms=100,min.cleanable.dirty.ratio=0.01,delete.retention.ms=100
    Topic: count-colors-output  Partition: 0    Leader: 1   Replicas: 1 Isr: 1

但如果在配置字段中没有看到任何内容，请不要感到困惑。如果使用了默认值，就会发生这种情况。所以，除非你看到 cleanup.policy=compact 在输出中-主题未压缩。