Kafka 4.0 的新 Rebalance 协议（KIP-848）解决了什么问题？
技术点：Rebalance
面试怎么回答
老协议的分配是在客户端做的：成员变化时所有成员重新 JoinGroup，选一个 Leader 算分配，再 SyncGroup 下发，本质上有一个全局同步屏障，一个慢成员就能卡住整个组，分配逻辑在客户端也不好升级和排查。KIP-848 把分配搬到 Broker 端的 Coordinator，客户端通过心跳上报状态，Coordinator 在心跳响应里告诉每个成员该释放和获取哪些分区，各成员独立增量地收敛，没有全局屏障，一个成员变化只影响要移动的分区。用的时候客户端配 group.protocol=consumer，分配策略和超时改由 Broker 端配置，老组可以滚动切换。升级前要先迁到 KRaft，确认客户端支持，自定义分配策略要重新评估。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
Kafka 4.0 除了彻底去掉 ZooKeeper，另一个重要变化是新一代消费者组协议（KIP-848）正式可用。面试官问这题，通常是接着「Rebalance 频繁怎么排查」往下问：老协议的根本问题在哪，新协议换了什么思路。
老协议的问题
老的消费者组协议（现在叫 classic）里，分区分配是在客户端做的：
- 有成员加入或离开时，Coordinator 通知所有成员重新 JoinGroup；
- 选出一个 Leader 消费者，由它根据分配策略算出分配方案；
- 再通过 SyncGroup 把方案下发给所有成员。
这带来几个问题：
- 全局同步屏障：所有成员都必须重新加入才能完成一轮 Rebalance，只要有一个成员处理慢（比如卡在 poll 里），整个组都得等；
- 影响面大：即使用了 Cooperative Sticky 做增量 Rebalance，仍然需要多轮全组参与；
- 逻辑在客户端：分配策略、版本兼容都在客户端，升级、排查都很麻烦，不同语言的客户端实现还不一致。
新协议怎么做
KIP-848 把分配逻辑搬到了 Broker 端的 Group Coordinator：
- 服务端分配：Coordinator 根据组成员和订阅关系直接计算目标分配（内置 uniform、range 等分配器），客户端不再选 Leader 计算；
- 心跳驱动、增量收敛：成员通过心跳上报自身状态，Coordinator 在心跳响应里告诉每个成员「你需要释放哪些分区、新拿哪些分区」，每个成员各自独立地往目标分配收敛；
- 没有全局屏障：一个成员的加入或离开，只影响需要移动的那些分区，其他成员照常消费，一个慢成员不会卡住全组。
使用上的变化
- 客户端配置
group.protocol=consumer启用新协议； - 原来客户端上的
partition.assignment.strategy不再生效，会话超时、心跳间隔等改成由 Broker 端的组配置控制； - 已有的 classic 组可以通过滚动重启成员，在线切换到新协议；
- Kafka Streams 有单独的新协议，进度和普通消费者不同，要单独评估。
升级要注意
- 先确认 Broker 版本和 KRaft 模式（4.0 已经不支持 ZooKeeper 模式，老集群要先迁移到 KRaft）；
- 确认所用语言的客户端是否支持新协议；
- 依赖自定义分配策略（比如按机房分配）的业务，要评估服务端分配器能否满足；
- 新协议下依然要处理好
max.poll.interval.ms：处理慢的成员仍然会被踢出，只是影响范围变小了。