负载特性分析：峰值负载、平均负载、突发流量、负载模式识别
做性能建模这么多年，我最大的体会是：不懂负载特性，架构设计就是闭着眼睛开车。你想想看，连系统要扛什么样的压力都没搞清楚，怎么敢拍板用哪种架构？
这一节，咱们就聊聊负载分析这件事。说白了，就是搞清楚你的系统到底在什么场景下干活，干多重的活，活是怎么来的。
一、峰值负载 vs 平均负载：两个数字，天壤之别
很多团队做容量规划时，习惯看平均负载。我个人觉得，这是个危险的信号。平均负载只能告诉你系统「通常」在干什么，但架构设计真正要关心的，是系统「最惨」的时候能不能扛住。
核心观点：峰值负载决定架构的上限，平均负载决定资源的利用率。
举个例子。我参与过一个电商平台的架构评审，对方说日均订单量 100 万，平均 QPS 大概 1200。听起来还行对吧？但一查历史数据，双十一当天的峰值 QPS 冲到过 8 万。如果按平均负载去设计，系统早就被打穿了。
| 指标 | 定义 | 架构意义 |
|---|---|---|
| 平均负载 | 一段时间内请求量的均值 | 决定日常资源配比、成本预算 |
| 峰值负载 | 单位时间内的最大请求量 | 决定系统弹性上限、限流阈值 |
| P99 负载 | 排在前 1% 的高负载时刻 | 决定缓存策略、降级方案 |
我的习惯：做性能建模时，至少要看三个数字——平均、峰值、P99。峰值决定你能不能活，P99 决定你活得好不好。
二、突发流量：最容易被忽视的杀手
峰值负载好歹还能预测，突发流量才是真正的噩梦。它来得毫无征兆，走的时候可能已经把你的系统打趴下了。
突发流量有几个典型特征：
- 上升斜率极陡——几秒内流量翻几倍
- 持续时间短——通常几十秒到几分钟
- 不可预测——没有明显的周期性规律
我曾经遇到过一个案例。某社交 App 的 feed 流服务，平时 QPS 稳定在 5000 左右。有一天某明星突然发了一条动态，粉丝瞬间涌入，QPS 在 3 秒内飙到了 12 万。数据库连接池直接被打满，整个服务挂了 20 分钟。
事后复盘，问题出在哪？我们只做了基于平均负载的限流，没有针对突发流量的快速扩容机制。
避坑指南：我曾经以为突发流量靠限流就能解决。后来发现，限流只能保护系统不崩溃，但业务损失已经造成了。更好的做法是「快速扩容 + 优雅降级」双管齐下。
三、负载模式识别：看懂流量的「脾气」
不同的业务场景，负载模式完全不同。我习惯把常见的负载模式归纳为三类：
1. 秒杀模式
特点：流量在瞬间达到顶峰，然后快速回落。典型的「尖峰」形态。
- QPS 曲线像一根针，又尖又细
- 请求集中在少数热点商品上
- 读写比例严重失衡（读多写少，但写是关键瓶颈）
应对策略：提前预热缓存、请求排队、库存预扣、限流熔断。我见过最夸张的秒杀场景，QPS 峰值是平均值的 200 倍。
2. 直播模式
特点：流量随着主播开播而上升，下播后回落。有多个「小高峰」。
- 流量波动大，但相对可预测
- 实时性要求高（延迟不能超过几百毫秒）
- 弹幕、礼物、点赞等并发写入量大
应对策略：WebSocket 长连接、消息队列削峰、读写分离。我记得有一次直播大促，同时在线 300 万人，弹幕系统每秒要处理 50 万条消息，全靠消息队列在扛。
3. 周期性任务模式
特点：流量呈现规律的波峰波谷，比如日报、月报、定时结算。
- 时间点固定，可以提前准备
- 通常是计算密集型任务
- 对资源的需求是突发性的
应对策略：任务调度 + 资源预留。我建议用分布式定时任务框架，配合弹性容器，在任务高峰期自动扩容。
四、负载模式识别流程图
下面这张图，是我自己总结的负载模式识别流程。每次接手新系统，我都会按这个思路走一遍。
五、实战：如何做负载特性分析
光说不练假把式。我分享一下自己常用的分析步骤：
- 拉取至少 3 个月的历史监控数据——只看一周的数据，很容易漏掉周期性规律
- 绘制 QPS 曲线图——按天、按小时、按分钟三个粒度分别看
- 标记异常事件——大促、发版、运营活动、故障等
- 计算关键指标——峰值/均值比、P99 负载、上升斜率
- 匹配负载模式——看属于秒杀、直播、周期性还是混合模式
一个小技巧：我习惯用「峰值/均值比」这个指标来快速判断系统的压力特征。比值小于 5 的，算是比较平稳的系统；比值超过 20 的，一定要做弹性设计。
嗯，负载特性分析这块，核心就这些。你想想看，搞清楚了系统的「脾气」，后面做架构设计、做性能建模，心里就有底了。说白了，这就是性能工程的「望闻问切」——先诊断，再开药方。
公众号:蓝海资料掘金营，微信deep3321