单消费者组分配新分区前未全量撤销消费者的原因及解决方法

异常产生原因 #

• 消费者重平衡通知的响应逻辑依赖poll()调用：消费者C调用close()主动离开组后，协调者会向所有存活消费者的心跳响应中标记重平衡状态，但消费者不会主动中断当前消费流程，只有下次调用poll()时才会感知到重平衡通知，触发分区撤销逻辑。不同消费者的单批次消息处理速度不同，调用poll()的时机有先后，自然会出现撤销分区的时间差。
• 启用了协作式（增量）重平衡策略：Kafka 2.4及更高版本默认优先使用CooperativeStickyAssignor分配策略，该策略的设计目标就是降低重平衡停顿，不需要一次性撤销所有消费者的全部分区，而是分多轮完成分配调整，每轮仅修改部分分区的归属，因此会出现部分消费者先完成撤销、拿到新分区，其余消费者后续再调整的现象，属于该策略的正常表现。

解决方案 #

• 如需严格遵循「所有分区先统一撤销再重新分配」的预期，切换为Eager类分配策略，修改消费者配置即可：

  partition.assignment.strategy=org.apache.kafka.clients.consumer.RangeAssignor
  

  切换后协调者会等待所有存活消费者都完成分区撤销、提交加入组请求后，再统一向所有消费者下发新的分区分配结果，不会出现部分消费者先拿到新分区的情况。
• 若需保留协作式重平衡低停顿的优势，优化消费逻辑的重平衡响应速度：
  • 调小max.poll.records参数，减少单次拉取的消息数量，缩短单批次消息处理时长，提高poll()调用频率，让消费者更快感知重平衡通知。
  • 排查消费逻辑中的阻塞点（比如慢数据库查询、第三方接口超时等），避免单批次处理时长超过max.poll.interval.ms阈值。
• 可在自定义ConsumerRebalanceListener的onPartitionsRevoked和onPartitionsAssigned回调中增加日志埋点，明确各个消费者的重平衡执行进度，快速定位慢消费实例。

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