Kafka Streams：主题消息统计值大于实际值的原因排查

这个问题在Kafka Streams的实际使用中并不少见，结合你的代码逻辑和场景，我整理了几个最可能的诱因：

1. 生产者端的消息重复写入 #

Kafka生产者默认开启了重试机制，如果消息发送后未收到Broker的确认回执，生产者会自动重试发送这条消息。这就会导致同一条消息被多次写入主题，主题内实际的消息数量早已超过最初的1000条，最终统计结果自然会大于预期值。

2. Kafka Streams故障恢复时的重复处理 #

Kafka Streams是基于状态的流处理框架，当流处理任务遭遇故障（比如进程重启、节点宕机）或发生任务重新分配时，框架会从最近的检查点（checkpoint）或状态快照恢复状态。为了保证Exactly-Once语义，框架会重新处理检查点之后的消息——如果这些消息之前已经被处理过并更新过count值，再次处理就会导致count被重复累加，结果自然超过1000。

3. 全局变量count的副作用问题 #

你代码里用了全局的int count变量来累加结果，这是典型的非线程安全的副作用操作。在Kafka Streams的分布式环境中，任务可能会在多线程或多实例间重新分配，而这个全局变量并没有纳入Kafka Streams的状态管理体系。当任务重新分配时，之前的处理结果没有被正确清理，新任务实例继续累加该变量，就会导致最终数值偏大。

另外，foreach本身是终端操作，它的执行不受Kafka Streams状态机制保障，在任务重启等场景下可能被重复触发，进一步加剧重复累加的问题。

4. 消费者偏移量提交异常导致重复消费 #

如果你的消费者配置中enable.auto.commit设为true但提交时机不合理，或者手动提交偏移量时出现延迟/失败，消费者重启后会从未提交的偏移量位置开始消费，导致已处理过的消息被再次消费并计数，最终结果超过1000。

内容的提问来源于stack exchange，提问作者Anouer Hermassi