重平衡（rebalance）可以理解成：
班组里的人数或订阅关系变了，城市调度中心要重新分配各条分区的值班员。
常见触发原因：
- 有新 consumer 加入 group
- 某个 consumer 挂了
- 某个 consumer 长时间没心跳
- topic 分区数变了
- 订阅的 topic 变了
比如原来这样：
Group: inventory-service
C1 -> P0
C2 -> P1
C3 -> P2如果 C2 挂了，重平衡后可能变成：
Group: inventory-service
C1 -> P0, P1
C3 -> P2#为什么重平衡会带来重复消费风险
因为分区所有权在切换。
如果你还没来得及提交位点，分区就被收走了，新 consumer 接手后会从“上次已提交的位置”继续读，于是某些消息可能再处理一次。
所以重平衡的正确认知不是：
- “Kafka 怎么老抽风”
而是：
- “消费者组成员变化，本来就必须重新分区”
现代 Kafka 不断改进 rebalance 协议，减少停顿和全量迁移，但基础心智始终不变：
重平衡 = 分区归属重算 = 位点管理必须严谨 = 消费逻辑必须幂等。