日期：2026-07-12
标签：#面试 #八股 #后端 #数据同步 #消息堆积 #场景题
一句话答案
先保护源端和下游并判断瓶颈，通过提前扩分区/消费者、批量压缩、优化 Sink、热点拆分和非关键链路降级提升吞吐，恢复时限速追赶并保证幂等。
面试口语版
先看生产速率、各分区 Lag、消费处理时间、checkpoint、下游写入和热点分区，确认是消费实例不足、单条变慢、数据倾斜还是数仓限流。活动前按峰值压测并预扩 Kafka 分区、Flink 并行度和 Sink 容量；活动中批量写、压缩、异步 I/O，热点店铺/订单做二阶段分区，暂停非关键 enrichment 或转旁路存储。若下游已饱和，继续加消费者无效，应背压、扩容目标或先落对象存储。追赶积压时按下游安全水位限速，不能再次冲垮系统。
关键细节
- 增加消费者数量不能超过有效分区并行度。
- 临时改分区会影响按 Key 顺序，需规划路由版本。
- 延迟升高不代表丢数据，向业务暴露数据水位。
- 保证 MQ 保留时间覆盖最坏恢复时长。
面试官追问
- 如何判断是热点分区？
- 为什么恢复后不能全速消费？
- 活动前如何做容量规划？
面试官追问参考答案
1. 如何判断是热点分区？
比较各分区生产速率、Lag 和处理耗时，若少数分区明显高而消费者资源空闲，通常是 Key 倾斜。采样 Key 频率确认超级店铺/用户，并改为加盐局部聚合或热点独立通道。
2. 为什么恢复后不能全速消费？
积压回放流量加上实时流量可能远超数仓、数据库或第三方的安全容量，导致再次超时和故障。使用令牌桶按下游水位渐进提高追赶速率，并保留实时流优先级。
3. 活动前如何做容量规划？
基于峰值订单事件数、单订单事件放大、消息大小和目标延迟，分别估算 Kafka 带宽/存储、分区、计算并行度和 Sink TPS，再加入 N+1 与安全余量，用真实数据演练故障和积压恢复。
学习清单
- 会区分并行度、倾斜和下游瓶颈。
- 理解预扩容与限速追赶。
维护与整理 · Yihui在 GitHub 上编辑