Kafka Streams应用单输入生成两条存储消息问题排查求助

针对你遇到的问题，结合Kafka Streams的核心运行机制，可能的原因如下：

1. 状态存储存在键的残留数据 #

如果键"123"之前在状态存储中有过聚合记录（哪怕是已被标记删除的tombstone），当新消息"123":"foo"到来时，Kafka Streams会尝试将新值与残留的旧聚合值执行reducer逻辑。你的reducer函数无论输入是什么都返回"bar"，因此会直接生成"bar"并写入状态主题。若后续因状态恢复或重平衡再次处理这条消息，会重复执行该逻辑，最终写入两条相同记录。

2. 任务重平衡/重启导致重复处理 #

当Kafka Streams应用发生重平衡、任务重启时，会重新消费输入主题的消息以恢复状态。如果这条"123":"foo"被重复处理两次：

• 第一次处理：若状态初始化异常（或使用的版本存在bug），错误触发reducer调用（而非直接将"foo"作为初始聚合值），生成"bar"写入状态主题；
• 第二次处理：此时状态已存在"bar"，调用reducer("bar", "foo")仍返回"bar"，再次写入状态主题，形成两条记录。

3. 对Reduce操作的逻辑误解 #

你提到"首次处理该键时不应调用reducer"，这个预期存在偏差：Kafka Streams的reduce操作仅在状态中完全无该键的任何数据时，才会直接将第一条消息的值作为初始聚合结果。一旦状态中有残留数据（包括tombstone），就会触发reducer逻辑合并新旧值。

排查建议 #

• 检查输入主题"input"中键"123"的历史消息，确认是否存在旧消息或tombstone；
• 查看应用日志，排查是否有重平衡、任务重启的记录；
• 验证Kafka Streams版本是否存在已知的reduce逻辑bug（比如早期版本中首次处理错误调用reducer的问题）；
• 临时修改reducer函数，打印agg和val的具体值，观察首次处理时的参数情况，确认是否有旧值残留；
• 检查key/value序列化器配置，确保输入流、groupByKey、状态存储的序列化器完全一致。

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