2. 削峰填谷基本概念
2.1 流量峰值产生原因
在分布式系统与微服务架构中，流量峰值是导致系统过载、响应延迟甚至雪崩的核心诱因。理解峰值的来源是设计削峰策略的前提。
| 峰值类型 | 典型场景 | 特征描述 |
|---|---|---|
| 业务突发型 | 秒杀、大促、抢票、热点事件 | 瞬时请求量可达常态的 10~100 倍，持续时间短（秒~分钟级） |
| 定时触发型 | 整点签到、定时任务、批量结算 | 大量客户端或服务端在同一时间点发起请求，形成周期性尖峰 |
| 冷启动型 | 新实例上线、缓存过期、服务重启 | 初始阶段无缓存或连接池未预热，请求穿透至后端，造成瞬时压力 |
| 连锁放大型 | 重试风暴、超时堆积、熔断恢复 | 单点故障引发客户端重试，流量层层放大，形成二次峰值 |
关键指标： 峰值流量通常用 QPS（Queries Per Second）或 TPS（Transactions Per Second）衡量。削峰的目标是将 瞬时峰值 QPS 平滑为 平均处理 QPS，使系统在资源上限内稳定运行。
2.2 削峰策略分类
削峰策略按处理时机和机制可分为三大类：请求排队、缓存预热、异步处理。以下通过对比表格和流程图进行详细说明。
| 策略 | 核心原理 | 适用场景 | 典型实现 |
|---|---|---|---|
| 请求排队 | 将瞬时超量请求暂存队列，按固定速率消费 | 秒杀下单、API 限流、消息推送 | Kafka/RabbitMQ 队列、令牌桶、漏桶算法 |
| 缓存预热 | 在流量到达前将热点数据加载到缓存层 | 冷启动、定时活动、首页推荐 | Redis 预加载、本地缓存预热、CDN 预热 |
| 异步处理 | 将耗时操作异步化，主线程快速返回，后台消费 | 订单处理、日志上报、图片处理 | 消息队列 + Worker、CompletableFuture、事件驱动 |
2.3 削峰与冷启动的关系
冷启动阶段是系统最脆弱的时期，此时流量峰值与资源不足叠加，极易引发故障。削峰策略在冷启动场景中承担着“缓冲垫”和“加速器”的双重角色。
核心洞察： 冷启动削峰不是简单的限流，而是通过 请求排队 防止实例被瞬间压垮，通过 缓存预热 缩短启动后的慢速期，通过 异步处理 将非关键路径剥离，让系统优先处理核心请求。
冷启动削峰的三阶段模型
- 启动初期（0~T1）： 实例刚上线，无缓存、无连接池。此时启用 请求排队，将流量控制在实例处理能力的 60% 以下，避免过载。
- 预热期（T1~T2）： 缓存逐步填充，连接池建立。配合 缓存预热 策略，主动加载热点数据，加速系统进入稳态。
- 稳态期（T2 之后）： 系统达到正常处理能力。削峰策略降级为常规限流，异步处理持续运行。
削峰策略在冷启动中的具体作用
| 削峰策略 | 冷启动中的作用 | 风险点 |
|---|---|---|
| 请求排队 | 防止实例在无缓存时被瞬时流量压垮，提供缓冲时间 | 队列堆积可能导致延迟增加，需设置超时与降级 |
| 缓存预热 | 主动加载热点数据，减少冷启动期间的缓存穿透 | 预热数据可能过时或不全，需配合失效策略 |
| 异步处理 | 将非关键路径（如日志、统计）异步化，释放主线程资源 | 异步任务积压可能造成数据不一致，需保证最终一致性 |
常见误区： 冷启动阶段单纯依赖限流（请求排队）而不做缓存预热，会导致系统长时间处于低吞吐状态；反之，只做预热而不做排队，预热期间仍可能被突发流量击穿。三种策略需组合使用，形成“排队保底 + 预热加速 + 异步分流”的立体削峰方案。