Kafka Rebanlace次数过高问题

kafka rebanlace次数过高问题

缘起：

最近发现kafka rebalance次数着实有点多，一天达到了六十多次，感觉不太正常，于是查了下日志发现：

offset commit cannot be completed since 
the consumer is not part of an active group for auto partition assignment; 
it is likely that the consumer was kicked out of the group.

大意是某个kakfa client提交offset失败，因为已经在分组中下线。

为什么会下线？

我们来了解下什么情况下会掉线，常见情况如下：

1. 心跳原因：

kafka在n次心跳未收到后认为这个kafka client已经离线，于是server端会踢下线，至于n次是多少次，需要计算，有两个参数，一个是heartbeat.interval.ms,代表多久一次心跳，默认是3000ms，也就是3秒，还有一个参数是session.timeout.ms，代表保持session的超时时间，默认10000ms，也就是10秒。n = session.timeout.ms / heartbeat.interval.ms，也就是说3次之后不到第四次就会被踢下线，至于为什么不是正好3倍，官网解释是heartbeat.interval.ms的值建议小于session.timeout.ms的 1/3，两个参数官网解释如下：

以上来自kafka官网 https://kafka.apache.org/28/documentation.html#consumerconfigs

2. 拉取间隔原因

和这个原因有关的参数是max.poll.interval.ms，这个参数的意思是两次poll()操作之间如果超过了这个值，也会被服务端踢下线，默认300000ms，也就是300秒，5分钟。

以上来自kafka官网 https://kafka.apache.org/28/documentation.html#consumerconfigs

定位

当时做性能优化的时候，这个kafka处理逻辑统计了时间于是找到了以下日志：

当前拉取了数据条数 10 耗时 411260ms thread: kafkaxxxreceiver-pool-3

处理10条数据居然用了411260ms，这是只是其中一条，通过模糊查询还找到了更多了超过300秒的数据，已经确认是这里的问题了。

优化思路

1. 适当调大参数max.poll.interval.ms，或者调小每次拉取的消息数max.poll.records。
2. 因之前压测未出现此问题，需要进一步定位到底是哪一块用时较长，进行业务上的优化。