背景

??kafka消费者采用批量拉取的方式，一次拉取一批记录来消费，如果消费者线程消费超时会导致整批消息的回滚，从而导致已经消费过的数据再消费一遍，消费者不幂等会出大问题，这也是为啥要强调使用消费队列一定要考虑幂等性的原因。

??如果某一次拉取数据后在规定的时间内不能消费完毕，有可能进入拉取-->超时-->回滚-->拉取的循环中。

消费超时会发生什么？

Client Will Seek Soon: org.apache.kafka.clients.consumer.CommitFailedException: Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member. This means that the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms, which typically implies that the poll loop is spending too much time message processing. You can address this either by increasing the session timeout or by reducing the maximum size of batches returned in poll() with max.poll.records.

??集群以为消费者线程挂了，触发了rebanlance（这一批已经给别的消费者线程消费了）。当前消费者线程业务逻辑执行完了再去同步游标报错了，没有提交成功，这就导致了两个消费者线程把同一批消息消息了两遍。

参数详解

max.poll.interval.ms 拉取时间间隔 400s 每次拉取的记录必须在该时间内消费完

max.poll.records 每次拉取条数 600条 这个条数一定要结合业务背景合理设置

fetch.max.wait.ms 每次拉取最大等待时间 时间达到或者消息大小谁先满足条件都触发，没有消息但时间达到返回空消息体

fetch.min.bytes 每次拉取最小字节数 时间达到或者消息大小谁先满足条件都触发

heartbeat.interval.ms 向协调器发送心跳的时间间隔 3s 建议不超过session.timeout.ms的1/3

session.timeout.ms 心跳超时时间 30s 配置太大会导致真死消费者检测太慢

max.poll.interval.ms 和session.timeout.ms区别

KIP-62(kafka规范)前只有session.timeout.ms参数

KIP-62后不通过poll()方法发送心跳，而是后台另起一个心跳线程，这就允许单次poll处理更长时间。不会因为单次处理超时假死引发不必要的rebanlance

max.poll.interval.ms 检测消费者处理线程死亡

session.timeout.ms 检测整个消费者死亡

建议

1.一定要结合具体业务背景，预估消费能力，合理设置【max.poll.records】和【max.poll.interval.ms】

默认情况下max.poll.records=600条，max.poll.interval.ms=400秒， 也就是说400s必须消费完600条，否则超时回滚！！！

2.将【session.timeout.ms】设置为【heartbeat.interval.ms】的三倍。即连续三次收不到心跳认为消费者挂了。

官网是poll中timeout的描述：

The time, in milliseconds, spent waiting in poll if data is not available in the buffer

If 0, returns immediately with any records that are available currently in the buffer, else returns empty. Must not be negative.