Flink消费Kafka突然全停了，Doris大盘一片空白——Rebalance怎么排查？
先说结论
Rebalance是Consumer Group重新分配Partition的过程。当Consumer加入、退出或Partition数量变化时触发。Rebalance期间所有Consumer暂停消费（Stop The World），是生产环境的性能杀手。
面试答三个层面：① 什么时候触发（4种条件）；② 三种分配策略；③ 怎么减少Rebalance次数。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
这道题是Kafka面试高频题，也是生产环境最让人头疼的问题之一。我在某元宇宙社交公司做实时数仓时被Rebalance折磨过不止一次——Flink消费好好的，突然所有消费全停了，Doris的实时大盘一片空白，产品经理追过来问'数据怎么不动了'。排查下来发现是Consumer Rebalance。今天把这个讲透。
什么时候会触发Rebalance？
| 触发原因 | 典型场景 | 是否可控 |
|---|---|---|
| Consumer加入 | 新部署Flink Job、扩容 | ✅ 主动触发 |
| Consumer主动退出 | 下线Job、缩容 | ✅ 主动触发 |
| Consumer被踢出 | 心跳超时、poll间隔超时 | ❌ 被动触发，最坑 |
| Partition数变化 | 增加Partition（很少） | ✅ 主动触发 |
最坑的是Consumer'被踢出'。往往不是Consumer真的挂了，而是处理太慢或GC暂停导致心跳超时，Coordinator以为它挂了就触发Rebalance。在Flink场景下，如果下游写入很慢（比如Doris在做compaction），就容易触发。
Rebalance的完整过程
# Rebalance的5个阶段（以Flink消费Kafka为例）
#
# 1. Coordinator检测到Consumer Group成员变化
# 比如：某个Flink TaskManager心跳超时
# 2. 向所有Consumer发送Rebalance信号
# 3. 所有Consumer停止消费，提交当前offset ← 全部暂停！
# 4. Consumer重新发送JoinGroup请求
# 5. Leader Consumer执行Partition分配，通过SyncGroup下发
#
# 步骤3到5期间，整个Consumer Group完全不消费
# 6个Partition + 6个Consumer，重新分配可能需要20-60秒
# 这段时间下游Doris没有数据写入，实时大盘一片空白三种Partition分配策略
| 策略 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| Range（默认） | 按Partition范围连续分 | 简单直观 | 多Topic时不均匀 |
| RoundRobin | 所有Partition打散轮询 | 最均匀 | Rebalance后变动大 |
| Sticky（推荐） | 尽量保持原分配不变 | 变动最小恢复快 | 逻辑稍复杂 |
Kafka 2.4+推荐CooperativeStickyAssignor：增量Rebalance模式，只revoke需要移动的Partition，其他不停消费。对Flink场景特别有用。
// Flink的Kafka Consumer配置分配策略
properties.setProperty("partition.assignment.strategy",
"org.apache.kafka.clients.consumer.CooperativeStickyAssignor");
// Flink KafkaSource（新API）示例
KafkaSource<String> source = KafkaSource.<String>builder()
.setBootstrapServers("broker1:9092,broker2:9092")
.setTopics("user_event")
.setGroupId("flink-realtime-dashboard")
.setStartingOffsets(OffsetsInitializer.committedOffsets())
.setProperty("partition.assignment.strategy",
"org.apache.kafka.clients.consumer.CooperativeStickyAssignor")
.build();怎么减少Rebalance？——参数调优
核心是避免Consumer被误踢。三个关键参数：
// ① session.timeout.ms —— 心跳超时
// Coordinator超过这个时间没收到心跳就认为Consumer挂了
props.put("session.timeout.ms", 45000); // 默认10s太短，建议30-45s
// ② heartbeat.interval.ms —— 心跳间隔（一般是session.timeout的1/3）
props.put("heartbeat.interval.ms", 15000);
// ③ max.poll.interval.ms —— 两次poll的最大间隔
// Consumer处理太慢超过这个时间没poll就被踢
props.put("max.poll.interval.ms", 600000); // 默认5分钟，处理慢时调大
// ④ max.poll.records —— 每次poll拉取的最大记录数
props.put("max.poll.records", 200); // 默认500，按处理速度调实战踩坑：Rebalance风暴
在某元宇宙社交公司做实时数仓时，有一次晚高峰直播间送礼高峰，gift_txn这个Topic消息量突增。下游Flink Job写Doris变慢了（Doris在做compaction），其中一个Flink TaskManager处理一批数据超过了max.poll.interval.ms的默认5分钟，被Coordinator踢出。
踢出后触发Rebalance，剩下的Consumer重新分配Partition。但另一个TaskManager本来就在边缘状态，分到更多Partition后也超时了，又被踢出。连锁反应下Rebalance反复触发了4次，整个消费链路停了将近3分钟，Doris实时大盘一片空白。
解决方案四步走：① max.poll.interval.ms从5分钟调到10分钟；② max.poll.records从500调到200；③ 换成CooperativeStickyAssignor；④ Doris写入从逐条INSERT改成批量Stream Load。调整后再没出现过类似问题。
面试高频追问
追问一：Flink消费Kafka和普通Consumer有什么区别？
Flink有自己的Checkpoint机制保证Exactly-Once，不完全依赖Kafka的offset提交。Flink在Checkpoint时保存Kafka offset到State Backend，恢复时从Checkpoint的offset开始消费。这是Flink+Kafka配合的核心优势。
追问二：怎么监控Consumer Lag？
三种方式：① kafka-consumer-groups.sh命令行；② 我用Know Streaming的Web界面看，直观方便；③ Flink自身暴露的Kafka Consumer Lag指标，接Prometheus+Grafana。Lag持续增长就要报警。
总结
Rebalance面试三个层面：什么时候触发（4种条件，最坑是被误踢）、怎么分配（推荐CooperativeSticky）、怎么避免（调session.timeout、max.poll.interval、max.poll.records）。如果你用Flink消费Kafka，一定要提Flink Checkpoint和Kafka offset的配合。讲出Rebalance风暴的排查经历，面试官就知道你是真正被Kafka折磨过的人。
下一篇聊另一个高频场景：晚高峰消息堆了50万条，Consumer处理不过来怎么办？
你们Flink消费Kafka遇到过频繁Rebalance吗？怎么解决的？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长