削峰核心策略：请求排队、限流降级、异步化与缓存预热

服务目录平台在冷启动阶段面临瞬时流量洪峰，若不加控制，后端数据库与模板引擎将直接被打满，导致整体雪崩。削峰的本质是“削平流量尖峰，将突发请求分散到更长的时间窗口内处理”。本章围绕四种核心策略展开：请求排队、限流降级、异步化与缓存预热，它们分别从等待、拒绝、转移、预加载四个维度解决流量冲击问题。

2.1 请求排队：用时间换空间

请求排队将瞬时溢出的请求暂存到队列中，按固定速率或优先级依次处理，避免后端系统被并发击穿。排队策略适用于“可接受一定延迟”的场景，例如模板预生成、批量报表导出。

2.2 限流降级：主动拒绝保护核心

限流是削峰的第一道防线，降级是限流后的兜底策略。当流量超过系统阈值时，限流直接拒绝部分请求，降级则用简化结果（如缓存旧数据、静态占位模板）替代完整处理，保证核心链路可用。

2.2.1 限流算法对比

2.2.2 降级策略分级

• 一级降级（强降级）：直接返回静态模板或 503 页面，适用于系统濒临崩溃。
• 二级降级（弱降级）：返回缓存中的旧版本模板，放弃实时渲染，适用于模板引擎负载过高。
• 三级降级（功能裁剪）：关闭非核心功能（如模板预览、历史版本对比），保留生成主链路。

2.3 异步化：将同步阻塞转为异步事件

异步化是削峰的核心手段，将耗时的模板生成、数据聚合等操作从请求线程中剥离，放入后台异步处理。请求线程立即返回“任务已接收”标识，前端轮询或回调获取最终结果。

2.3.1 异步化架构模型

下图展示了服务目录平台冷启动阶段的异步化削峰流程：请求先进入限流层，通过后立即写入消息队列，消费者按自身处理能力拉取任务，生成结果写入缓存或数据库。

2.3.2 异步化关键参数

2.4 缓存预热：让数据提前就位

缓存预热是削峰的“预防性策略”。在冷启动阶段，大量请求会穿透到数据库，导致连接池耗尽。通过提前将热点模板、元数据、配置信息加载到缓存，可以大幅降低后端压力。

2.4.1 预热策略

• 全量预热：服务启动时，将全部模板元数据加载到 Redis 或本地缓存，适用于数据量小于 10 万条的场景。
• 热点预热：根据历史访问日志或业务规则，预加载 Top 20% 的热点模板，覆盖 80% 的请求。
• 分层预热：一级缓存（本地 Caffeine）存最热数据，二级缓存（Redis）存全量热点，三级数据库兜底。

2.4.2 预热流程

下图展示了缓存预热的完整流程，从预热触发到缓存就位，确保请求到达时命中缓存而非穿透数据库。

2.5 四种策略协同关系

四种策略并非孤立使用，而是形成完整的削峰链路：

1. 缓存预热 提前减少数据库穿透，是第一层防护。
2. 限流降级 在入口处控制流量，拒绝超限请求。
3. 请求排队 将允许通过的请求暂存，平滑处理速率。
4. 异步化 将耗时任务后台处理，释放请求线程。