一句话答案

Consumer Group 内消费者分摊 Partition，Rebalance 在成员变化时重新分配，期间消费暂停需优化避免频繁触发。

核心要点

Rebalance 定义：

当 Consumer Group 中的消费者数量或订阅的 Topic Partition 数量发生变化时，Kafka 会重新分配 Partition 到消费者的映射关系，这个过程叫 Rebalance。

触发条件（三种）：

1. 消费者加入/离开 Group：新消费者上线、消费者宕机、消费者主动调用 close()
2. 消费者心跳超时：消费者未在 session.timeout.ms（默认 45s）内发送心跳，被 Coordinator 踢出
3. Topic Partition 数量变化：新增 Partition

Rebalance 流程（Eager 协议）：

1. Coordinator 发现需要 Rebalance
2. 通知所有消费者撤销当前 Partition 分配（Stop-The-World）
3. 所有消费者发送 JoinGroup 请求
4. Coordinator 选出 Consumer Leader
5. Leader 执行分区分配策略，返回分配方案
6. Coordinator 将分配方案下发给所有消费者
7. 各消费者开始消费新分配的 Partition

分配策略：

策略	特点
RangeAssignor（默认）	按 Topic 维度均匀分配，可能导致部分消费者分到更多 Partition
RoundRobinAssignor	跨 Topic 轮询分配，更均匀
StickyAssignor	尽量保持原有分配不变，减少不必要的迁移
CooperativeStickyAssignor	增量式 Rebalance，不需要 Stop-The-World

Rebalance 的问题与优化：

• 问题：Rebalance 期间整个 Group 停止消费（Eager 模式），影响可用性
• 优化方案：
  1. 使用 CooperativeStickyAssignor（Kafka 2.4+），实现增量 Rebalance，只迁移需要变更的 Partition
  2. 合理设置 session.timeout.ms 和 heartbeat.interval.ms，避免误判消费者下线
  3. 合理设置 max.poll.interval.ms，避免消费逻辑太慢导致被踢出

追问与易错

追问方向：

• 这个概念在你的项目中是怎么应用的？
• 和相关技术/方案相比有什么优劣？
• 如果出了问题你会怎么排查？

易错点：

• ❌ 只知道概念不知道原理——面试官会追问底层实现
• ❌ 缺乏实际使用经验——结合项目场景回答更有说服力

💡 记忆锚点

Rebalance = 班级换座位：有人来/走/请假超时都要重新排座(触发条件三种)。Eager模式全班起立重排(Stop-The-World)，CooperativeStickyAssignor只让需要换的人动(增量Rebalance)。避免频繁换座的关键是调好心跳和poll超时参数。