我要评论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秒的数据，已经确认是这里的问题了。
优化思路
- 适当调大参数
max.poll.interval.ms，或者调小每次拉取的消息数max.poll.records。 - 因之前压测未出现此问题，需要进一步定位到底是哪一块用时较长，进行业务上的优化。
发表评论