同Group ID水平扩展Kafka消费者消费不同Offset问题咨询

问题根因与解决方案 #

核心异常原因 #

你观测到的同消费者组新实例从最新offset消费、同分区被两个实例同时消费的问题，本质是消费者组重平衡（Rebalance）未正常触发，和客户端预拉取配置没有直接关联，具体触发场景如下：

• 新扩容的Pod未能成功加入现有消费者组：Kafka broker端没有识别到新实例归属于目标group.id，因此新实例默认触发auto.offset.reset=latest规则，直接从topic最新的offset（也就是你观测到的5.8万位置）开始独立消费，没有触发原有分区分配规则，才会出现两个实例同时消费同一个分区的异常
• 你提到的QueuedMinMessages默认10万的配置是客户端本地预拉取队列阈值，仅会让老消费者提前把大量消息拉到本地缓存，不会改变Kafka broker端的分区分配逻辑，也不是导致新实例跳转到最新offset的原因。重平衡完成后老消费者本地缓存的未提交offset消息只会出现重复消费，不会丢失。

无停机修复方案 #

你不需要终止正在运行的老消费者，按以下步骤操作即可避免消息丢失，恢复正常消费逻辑：

1. 首先校验新Pod的基础配置与网络连通性：
   • 确认新Pod的group.id和老实例完全一致，没有拼写、环境变量注入错误
   • 确认新Pod可以正常访问Kafka集群所有Broker、Coordinator节点的服务端口，没有K8s网络策略、防火墙限制
2. 调整消费者配置规避重平衡异常：
   • 将两个实例的session.timeout.ms调低为30000（30秒），heartbeat.interval.ms调低为10000（10秒），确保实例状态可以及时同步到Broker，快速触发重平衡
   • 将auto.offset.reset显式设置为earliest，避免新实例加入失败时跳过存量滞后消息
   • 建议将enable.auto.commit设为false，你现有每条消息处理完成后手动提交offset的逻辑已经足够可靠，同时开自动提交和手动提交可能出现冲突，导致未处理完成的offset被提前上报引发消息丢失
3. 重平衡触发后，60个分区会自动均衡分配给两个消费者实例，同分区重复消费的现象会自动消失，两个实例会各自负责对应分区的存量滞后消息，不会出现区间消息丢失的问题。

额外优化建议 #

你当前消费者组累计滞后90万条，目标topic共60个分区，最多可以扩容到60个消费者实例（每个实例负责1个分区），可以最大化消费吞吐，快速消化存量滞后消息。

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