请描述 Kafka 中消息重复消费的产生原因，并给出至少三种解决重复消费问题的方案。

回答思路

1. 【回答框架 1】重复消费的根源在于 Kafka 至少一次投递语义和消费者端处理的边界。当消费者在提交 offset 前崩溃或发生重平衡，会从上次提交位置重新拉取消息，导致重复。
2. 【回答框架 2】方案一：消费者端幂等。通过业务唯一标识或唯一键，在消费逻辑中保证重复消息不产生副作用，如数据库唯一约束、Redis 幂等表或记录处理状态。这是最推荐的基础方案。
3. 【回答框架 3】方案二：使用外部存储记录已处理消息的 ID 或业务键，如使用数据库或 Redis 保存消息 ID，消费前检查是否已存在；注意需要保证检查和写入的原子性。
4. 【回答框架 4】方案三：配合事务机制，如使用 Kafka 事务或数据库事务，将消息处理和 offset 提交绑定在同一事务中，实现精确一次处理，但性能开销较大。
5. 【回答框架 5】方案四：调整提交方式，如手动提交 offset，且在业务处理成功后再提交；但这样不能完全避免重复，只能减少重复窗口。
6. 【关键点 1】重复消费是 Kafka 至少一次投递语义的必然结果，无法完全避免，只能通过幂等或去重来缓解。
7. 【关键点 2】最可靠的方案是消费者端的业务幂等，利用唯一标识保证重复消息不影响最终结果。
8. 【关键点 3】使用外部存储记录消息标识时，需保证查询和记录的原子性。
9. 【关键点 4】事务机制可实现精确一次，但会牺牲一部分性能和吞吐量。
10. 【易错点 1】认为设置 enable.auto.commit=false 或提高提交频率即可完全避免重复，这只能缩小重复窗口。
11. 【易错点 2】在幂等检查中，未考虑并发场景，两个消费者线程同时处理相同消息可能导致重复执行。
12. 【易错点 3】误以为 Kafka 的 exactly-once 语义（如事务）对所有场景都适用，实际上对生产者和消费者配置都有要求，且会增加复杂度。