Kinesis KCL V1消费者仅从单个分片拉取记录的问题咨询

已配置4个分片的Kinesis流，采用KCL V1实现消费者，但存在以下异常行为：

• 消费者持续仅从shardId-000000000000分片拉取记录
• 重启消费者后，会短暂从所有分片拉取少量旧记录，但后续仍仅聚焦于单个分片

记录统计数据 #

9月1日记录数（注：当日已重启消费者）

228830 shardId-000000000000
  98697 shardId-000000000001
    579 shardId-000000000002
    306 shardId-000000000003

9月2日记录数

163170 Shard: shardId-000000000000

注：消费者已配置InitialPositionInStream.LATEST

可能原因及修复方案 #

1. 分片Lease管理异常

KCL V1依赖DynamoDB表存储分片lease和检查点信息。如果该表中部分分片的lease记录状态异常，会导致消费者无法获取这些分片的处理权限：

• 定位KCL使用的DynamoDB表（默认命名格式为{你的应用名}-kinesis），查看leaseKey字段是否包含全部4个分片的记录
• 若存在缺失或状态异常的lease记录，手动删除后重启消费者，触发KCL重新分配分片

2. 单实例处理阻塞

即使仅运行1个消费者实例，理论上应能处理所有分片，但如果单分片的记录处理逻辑耗时过长，会阻塞lease续约和分片切换：

• 检查RecordProcessor的processRecords方法，确认是否存在长时间阻塞操作（如同步IO、复杂计算）
• 优化记录处理逻辑，确保每个分片的处理能及时完成，避免占用过多时间导致无法处理其他分片

3. 检查点提交不完整

如果消费者在处理非0号分片时未正确提交检查点，KCL会认为该分片处理未完成，后续不再分配该分片：

• 验证RecordProcessor的shutdown方法，确保在ShutdownReason.TERMINATE场景下调用checkpointer.checkpoint()提交检查点
• 增加定期检查点提交逻辑（例如每处理1000条记录或每30秒提交一次），避免因未提交检查点导致分片被标记为未完成

4. 检查点记录无效

虽然配置了InitialPositionInStream.LATEST，但重启后拉取旧记录说明非0号分片的检查点未被正确存储：

• 查看DynamoDB表的checkpoint字段，确认非0号分片是否有有效检查点记录
• 若检查点缺失，消费者重启后会从LATEST位置读取，但如果无法获取该分片的lease，仍无法持续拉取

内容的提问来源于stack exchange，提问作者ankit.vishen