双十一订单暴增，实时同步消息堆积如何应对？

日期：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 与安全余量，用真实数据演练故障和积压恢复。

学习清单

会区分并行度、倾斜和下游瓶颈。
理解预扩容与限速追赶。