极高困难

系统设计高压展开模板#

一句话答案#

系统设计高压追问必须覆盖四个维度：容量估算（DAU→QPS→存储→机器数）、监控告警（四黄金信号+业务指标）、回滚降级（feature flag+熔断+兜底方案）、压测验证（影子流量+梯度加压+混沌工程），任何场景题只要叠上这四层就能扛住深追。

核心要点

一、容量估算展开法

步骤	公式/方法	示例（秒杀场景）
日活→峰值QPS	QPS_peak = DAU × 每人日均请求 / 86400 × 峰值系数(3~10)	100万DAU × 5次/86400 × 10 ≈ 580 QPS（常态），秒杀瞬时 50万/10s = 5万 QPS
存储估算	单条大小 × 日新增 × 保留天数	订单200B × 10万/天 × 365天 ≈ 7GB/年
带宽估算	QPS × 平均响应体大小	5万QPS × 2KB = 100MB/s
机器数	QPS_peak / 单机承载（通常1000~3000）	5万 / 2000 = 25台应用服务器

面试展开话术：「这个场景我先估一下量级：假设日活X，每人每天Y次请求，峰值系数取Z，那峰值QPS大约是……存储方面，单条记录约N字节，日增M条，一年大概……所以至少需要K台机器来扛。」

二、监控告警展开法

四黄金信号（Google SRE）：

Latency（延迟）：P50/P99，区分成功请求与失败请求的延迟
Traffic（流量）：QPS/RPS，按接口维度统计
Errors（错误率）：HTTP 5xx 占比、业务错误码占比
Saturation（饱和度）：CPU/内存/连接池/线程池使用率

业务指标补充：

下单成功率、支付转化率、库存扣减失败率
缓存命中率、MQ 消费延迟、DB 连接池等待时间

告警分层：

P0（立即响应）：错误率 >5%、P99 >3s、核心链路全断
P1（15分钟内）：错误率 >1%、P99 >1s、非核心服务异常
P2（1小时内）：饱和度 >80%、慢查询增多

面试展开话术：「上线后我会监控四个黄金信号：延迟看P99不超过Xms，流量看QPS是否在预期范围，错误率告警阈值设1%，饱和度关注线程池和连接池。业务层额外加[具体指标]。告警分P0/P1/P2三级。」

三、回滚降级展开法

决策树：
异常检测（错误率飙升/延迟突增）
  ├─ 是配置变更？→ 配置回滚（Apollo/Nacos热更新，秒级）
  ├─ 是代码发布？→ 滚动回滚（kubectl rollout undo，分钟级）
  ├─ 是DB变更？  → 评估是否可逆
  │    ├─ 加字段/加索引 → 通常不需回滚
  │    └─ 改字段/删字段 → 执行预准备的反向SQL
  └─ 是依赖方故障？→ 启动降级
       ├─ 缓存降级：跳过缓存直连DB（限流保护）
       ├─ 服务降级：返回兜底数据/静态页
       └─ 功能降级：关闭非核心功能（feature flag）

plaintext

降级手段优先级：

Feature Flag 关闭（最快，预埋开关）
熔断（Sentinel/Resilience4j，自动触发）
限流（令牌桶/滑动窗口，保护核心链路）
兜底返回（静态数据/缓存快照/默认值）

面试展开话术：「回滚方面，我会区分变更类型：配置类走Nacos秒级热更新；代码类走K8s滚动回滚；数据库类提前准备反向脚本。降级方面，核心服务预埋feature flag，非核心服务接入熔断器，最坏情况返回兜底数据保证可用性。」

四、压测验证展开法

阶段	方法	目的
单接口压测	wrk/JMeter 对单API	找出单接口瓶颈（DB/Redis/CPU）
全链路压测	影子流量/流量录制回放	验证系统整体承载
梯度加压	10%→30%→50%→80%→100%	找到拐点和第一个瓶颈
混沌工程	注入故障（网络延迟/节点宕机）	验证降级和容错机制

关键注意：

压测环境隔离（影子库/影子表，标记压测流量）
逐步加压观察指标拐点，而非一次打满
压测后输出瓶颈报告：第一瓶颈是什么、优化措施、优化后数据

面试展开话术：「上线前我会做三轮压测：先单接口找瓶颈，再全链路用影子流量梯度加压到预估峰值的1.5倍，最后注入故障验证降级是否生效。压测结果要输出瓶颈点和优化方案。」

五、完整示例——秒杀场景 5 分钟展开

先估量：100万用户抢1000件商品，10秒内涌入，峰值QPS约5万。存储方面订单200字节，1000单很小。带宽5万×2KB=100MB/s需要关注。机器数：25台应用+主从Redis集群。

监控：核心看库存扣减成功率（应≈商品数/请求数）、Redis Lua执行延迟P99（应<5ms）、MQ消费延迟（应<1s）、DB订单写入成功率。告警：库存扣减失败率>0.1%立即告警。

降级：Redis挂了→降级到DB乐观锁+限流（QPS降到2000保护DB）；MQ积压→启动多消费者并行+告警；DB慢→限流+排队。回滚：代码问题kubectl rollout undo，Lua脚本问题走配置中心秒级回滚。

压测：提前用影子流量模拟5万QPS打Redis+MQ链路，验证Lua脚本不超时、MQ消费跟得上、DB不被打满。注入Redis主节点故障验证哨兵切换+降级链路。

面试回答（2分钟版）

我在做系统设计时会从四个维度完整展开。第一是容量估算：先从DAU推导峰值QPS，估算存储和带宽需求，算出需要多少机器，这决定了整体架构选型。第二是监控告警：上线必须覆盖延迟、流量、错误率、饱和度四个黄金信号，再加业务核心指标，告警分三级对应不同响应时间。第三是回滚降级：区分配置变更、代码发布、数据库变更和依赖故障四种情况，每种都有对应回滚手段；降级方面预埋feature flag、接入熔断限流、准备兜底数据。第四是压测验证：上线前做单接口压测找瓶颈、全链路影子流量梯度加压找拐点、注入故障做混沌工程验证容错。这四个维度不管什么系统设计题都能套用，面试时即使只展开其中两个也能体现工程落地能力。

追问与易错

追问方向：

“容量估算不准怎么办？”→ 预留 1.5~2 倍 buffer 应对估算偏差，配置弹性扩缩容（K8s HPA）自动应对流量波动，限流兜底防止超出系统极限
“监控指标太多怎么治理？”→ 核心指标（RED+业务转化率）做常驻 Dashboard 一屏可见，长尾指标按需查询不常驻，告警收敛/抑制避免风暴（同类告警聚合、短时间内不重复报）
“回滚如果也失败了怎么办？”→ 启动人工介入 SOP（值班 oncall 升级到架构师），同时紧急限流保护系统，对外挂公告页或降级页告知用户，事后做根因分析和回滚预案完善
“压测流量怎么和线上隔离？”→ 影子库/影子表存压测数据（表名加 _shadow 后缀），请求 Header 标记压测流量（x-test=true），中间件识别标记路由到影子资源，防止污染线上数据
“降级后如何恢复？”→ 观察核心指标（错误率/延迟/饱和度）恢复到正常基线 → 逐步开放流量（10%→50%→100%）→ 确认稳定后关闭降级开关 → 写恢复复盘记录

易错点：

❌ 只讲方案不讲数字——面试官要听到具体QPS/延迟/机器数
❌ 监控只说”我会加监控”——要说具体监控什么指标、阈值多少
❌ 回滚只说”回滚代码”——要区分配置/代码/数据/依赖四种回滚路径
❌ 压测跳过——很多候选人忘记提压测，这是高分项
✅ 每个系统设计场景结尾主动加一句”上线前会做压测验证，上线后监控X指标，异常时Y方案降级”