高流量到来前要补哪些防线面对高流量平均 QPS 常常最会骗人。它看不出突发、热点 Key、慢请求和多层重试也看不出加应用实例后共享缓存或数据库是否先到极限。上线前要先找出每一段资源的安全容量和拒绝方式再用演练确认压力会停在预定的位置而不是一路压到存储层。先找热点与放大回路商品详情、活动配置等少数对象可能形成 Hot Key集群总体不忙一个分片却已经发热。缓存变慢后上游连接占用更久客户端与服务端若同时重试对同一 Key 的访问又会增加。容量模型必须包含这条回路不能只用均匀随机请求压测。还要观察集中失效。许多 Key 同时过期会让请求一起回源。互斥重建、逻辑过期、预热和适度抖动都可选但需要先定义允许陈旧多久、重建失败如何回应。缓存不是“打开就安全”的开关失效语义本身就是业务决策。防线按路径逐层布置边缘层让静态资源用内容哈希与合适的缓存策略接入层按租户、用户、接口和优先级尽早拒绝非核心请求应用与共享缓存处理热点时要限制本地内存并验证失效数据库和队列则根据业务是否允许稍后完成决定同步或异步。CPU 只能作为信号之一排队长度、尾部延迟和下游余量同样重要。type Gate struct { overloaded atomic.Bool } func (g *Gate) Allow(priority string) bool { if !g.overloaded.Load() { return true } return priority core }这个闸门刻意很简单真实控制器还需平滑采样、迟滞、最小可用并发和接口权重且由队列与延迟共同驱动。无差别地看到 CPU 高就拒绝所有请求会把核心交易和可延后任务混为一谈。关闭、切换与恢复的负责人也应明确避免多个控制器互相覆盖。用演练得到容量结论节点数量可以从预期到达率和单节点实测能力估算但共享 Redis、消息分区和数据库另有总上限应用扩容不会提高它们的容量。全链路压测应使用隔离账号、可清理数据和流量标记覆盖热点、集中失效、依赖变慢、实例退出与降级恢复。最终交付不该是一句“扛得住”而是一张经过演练的容量和失败路径图哪些流量会被挡住核心请求保留多少资源异常解除后怎样平稳恢复。演练结束还要复盘开关是否可控。限流、降级和缓存策略的变更应能快速撤回并明确值班时谁有权限操作。监控要区分真实用户流量与演练流量避免错误告警掩盖问题。只有恢复过程也被验证过防线才算闭环。对于核心接口提前和业务确认最低可接受体验是排队等待、返回稍后查询的任务标识还是明确拒绝。不同答案对应不同的队列、超时和数据一致性要求。把这些选择写进演练脚本容量讨论才不会只停留在技术侧的假设中。上线当天持续观察同一套指标并为扩容失败准备人工处置路径。预案应能在不依赖临场记忆的情况下执行。