kafka CommitFailedException

一 异常产生原因分析

CommitFailedException，顾名思义就是 Consumer 客户端在提交位移时出现了错误或异常，而且还是那种不可恢复的严重异常。出现这个情况的原因是，你的消费者实例连续两次调用 poll 方法的时间间隔超过了期望的 max.poll.interval.ms 参数值。这通常表明，你的消费者实例花费了太长的时间进行消息处理，耽误了调用 poll 方法。
 

二 问题产生原因

1.每次poll拉取数据过多导致总数据处理时间过长，导致拉取频率过低

2.单个数据处理事件过长导致拉取频率过低

三 解决方案

1.缩短单条消息处理的时间。

比如，之前下游系统消费一条消息的时间是 100 毫秒，优化之后成功地下降到 50 毫秒，那么此时 Consumer 端的 TPS 就提升了一倍。

推荐 2.增加 Consumer 端允许下游系统消费一批消息的最大时长。

这取决于 Consumer 端参数 max.poll.interval.ms 的值。在最新版的 Kafka 中，该参数的默认值是 5 分钟，但是不一定会生效，如果设置了session.timeout.ms,没有设置 max.poll.interval.ms，那么它的默认值不一定会生效。如果你的消费逻辑不能简化，那么提高该参数值是一个不错的办法。Kafka0.10.1.0 之前的版本可以通过调整session.timeout.ms， 0.10.1.0 版本引入 max.poll.interval.ms 参数。

// 默认300000
props.setProperty(ConsumerConfig.MAX_POLL_INTERVAL_MS_CONFIG, "600000");

3.减少下游系统一次性消费的消息总数。

这取决于 Consumer 端参数 max.poll.records的值。当前该参数的默认值是 500 条，表明调用一次 KafkaConsumer.poll 方法，最多返回 500 条消息。可以说，该参数规定了单次 poll 方法能够返回的消息总数的上限。如果前两种方法对你都不适用的话，降低此参数值是避免 CommitFailedException 异常最简单的手段。

4.下游系统使用多线程来加速消费。

这应该算是“最高级”同时也是最难实现的解决办法了。具体的思路就是，让下游系统手动创建多个消费线程处理 poll 方法返回的一批消息。之前你使用 Kafka Consumer 消费数据更多是单线程的，所以当消费速度无法匹及Kafka Consumer 消息返回的速度时，它就会抛出 CommitFailedException 异常。如果是多线程，你就可以灵活地控制线程数量，随时调整消费承载能力，再配以目前多核的硬件条件，该方法可谓是防止 CommitFailedException 最高档的解决之道。事实上，很多主流的大数据流处理框架使用的都是这个方法，比如 Apache Flink 在集成Kafka 时，就是创建了多个 KafkaConsumerThread 线程，自行处理多线程间的数据消费。不过，凡事有利就有弊，这个方法实现起来并不容易，特别是在多个线程间如何处理位移提交这个问题上，更是极容易出错。