Spring Cloud Stream Kafka Streams Binder 3.x应用卡顿消费lag不下降问题排查

以下是测试与线上环境表现差异、线上消费lag停滞的最可能原因：

• 状态存储故障：线上flatTransform使用的RocksDB持久化状态存储出现文件损坏、磁盘IO不足、目录权限异常问题，导致有状态操作阻塞，处理线程无法推进消费进度。嵌入式Kafka测试场景下状态存储为临时内存实例，不会触发持久化层故障。即使参数配置完全一致，线上环境的存量状态数据量远大于测试环境，也可能触发缓存刷写死锁、内存溢出前兆等问题，导致处理线程被挂起。
• 序列化/反序列化异常：线上topic2存在测试环境没有的脏数据、历史版本序列化消息、超大消息体，触发flatTransform或aggregator的反序列化失败。如果应用配置的错误处理策略为静默跳过或吞掉异常，会导致消费线程无报错但实际停止处理。测试环境发送的都是统一格式的测试消息，不会触发该类问题。
• 消费者分区所有权冲突：线上存在相同group.id的其他僵死消费者实例，占用了topic2的唯一分区，导致当前应用的Processor2无法获取分区消费权，自然无法消费消息、lag不会下降。嵌入式Kafka测试环境只有一个消费者实例，不会出现所有权冲突。
• 事件时间窗口逻辑阻塞：如果aggregator使用事件时间驱动的窗口聚合，线上topic2的消息存在极端乱序、超前/滞后异常时间戳，会导致水印（Watermark）无法推进，窗口永远达不到触发条件，聚合结果不会向下游输出，看起来就是消费进度停滞。测试环境消息顺序发送、时间戳连续，窗口可以正常触发。
• 事务与位移提交异常：如果线上Kafka集群开启了事务强制校验，Processor2处理逻辑中的未捕获异常会导致事务持续回滚，消费位移永远无法提交。嵌入式Kafka默认关闭强事务校验，异常会直接抛出不会阻塞位移提交。
• 系统资源与网络故障：线上应用节点存在CPU、内存不足，或与Kafka集群之间存在网络分区、防火墙限流，导致消费者无法正常拉取消息但会话仍保持存活，lag数值维持恒定。测试环境为本地部署，资源充足且无网络限制。

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