Kafka事件重复消费问题排查：请求分析配置错误原因

生产者配置潜在问题 #

• maxInFlightRequestsPerConnection: 5 与幂等性的冲突：虽然开启了isIdempotent: true（幂等生产者），但当maxInFlightRequestsPerConnection大于1时，若生产者发送消息过程中出现超时重试，可能因消息乱序导致幂等性机制无法完全生效，进而产生重复消息。建议将该值调整为1，确保消息严格按顺序发送，配合幂等性彻底避免重试带来的重复。
• retries: 100 过高的重试次数：高重试次数虽能提升投递成功率，但如果broker端临时故障导致响应超时，生产者会反复重试。即使幂等性生效，极端情况下仍可能因broker状态不一致产生重复。可根据业务容忍度适当降低重试次数，结合deliveryTimeout（当前120s）合理设置，避免无意义的重试。

消费者配置核心排查点 #

• 缺失位移提交相关配置：提供的消费者配置未提及enable.auto.commit（自动提交开关）和auto.commit.interval.ms（自动提交间隔）。若开启自动提交，消费逻辑处理时间超过提交间隔、或消费者在提交前崩溃，未提交的位移会导致重新拉取已消费消息；若为手动提交，未在消息处理完成后正确调用提交逻辑，也会引发重复消费。
• batchSize: 1 的影响：每次仅拉取1条消息会增加网络开销，若消费过程中出现异常（如处理失败未捕获），容易导致单条消息反复被拉取。建议根据业务场景调整合理批量大小，同时确保异常处理逻辑中正确处理位移提交（如失败时跳过或重试后提交）。
• maxPollInterval: 300000 的合理性：当前设置为5分钟，若消费逻辑处理单条消息的时间接近或超过该阈值，消费者会被判定为失效并踢出消费组，重新加入后会从上次提交的位移处重新消费。需确认业务逻辑处理单条消息的耗时是否在阈值内，若存在超长耗时处理，需调大该值或优化消费逻辑。

其他可能的配置遗漏 #

• 消费者是否配置了auto.offset.reset？若该值设为earliest，当消费者组首次启动或位移丢失时，会从头开始消费所有消息，导致重复。建议根据业务需求设为latest（仅消费新消息）或none（位移丢失时抛出异常）。

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