凌晨23点，商品详情页缓存命中率从96%降到82%，看起来只少14个百分点，热门直播间的单一热点键却同时产生1.2万QPS回源。源站连接池上限200，单次查询80毫秒，理论吞吐约2500 QPS；瞬时缺口随即造成排队、超时与重试，最终拖垮源站。真正危险的不是总流量，而是热点集中度、过期同步率与源站并发容量叠加出的击穿。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：zgovps（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
普通未命中分散在低频键上，击穿则是少数键突然承接绝大多数回源。整体命中率会掩盖问题：长尾请求仍命中，热门键却在各边缘节点同时失效。缺少跨节点请求合并时，同一逻辑键会从多个节点打到源站，回源量取决于“节点数×单节点并发”，而非用户请求总数。
源站不能只看CPU。连接池200、P95耗时80毫秒时，持续吞吐约为200÷0.08=2500 QPS；1.2万QPS的瞬时MISS即使每次仅耗80毫秒，也会形成积压。超时重试、客户端重连与刷新流量会放大缺口，形成“越慢越多、越多越慢”的正反馈。
治理要串联三层：TTL加入随机抖动以实现过期削峰；CDN到源站之间以信号量限制回源并发控制，并用令牌桶执行回源限流；单节点内还要合并同键请求，预算耗尽时返回旧值、静态页或限流响应，执行故障降级。只扩容缓存解决不了失效瞬间，进程内加锁也挡不住不同节点的并发。
热点键识别不能只看总命中率。应按缓存键、节点和时间窗聚合日志，拆出TOP键的回源QPS、EXPIRED比例与响应体大小。例如总命中率仍为92%，前10个键却贡献81%的MISS；若它们几乎同时到期，即可确认是热点集中，而非全站缓存质量下降。这正是缓存击穿分析需要先回答的问题。
再对齐TTL到期、主动刷新或删除、版本变更三类事件。MISS峰值只与到期重合，才是典型过期击穿；若随外部流量同步升高，更可能是冷启动或批量失效。还要区分EXPIRED、条件校验成功但正文未命中、回源5xx，它们都会增加源站压力，却需要不同处置。核对重试次数也很关键，否则同一用户请求会被重复计为多次回源，进一步高估压力。
最后换算并发预算：可承受QPS≈并发上限÷P95耗时，再乘安全系数。预计MISS超过预算就应限流，不能等连接池耗尽。可借助随身服务器汇总短窗口脱敏日志，但生产侧源站保护策略应保持只读采样。还要警惕分钟级均值掩盖尖峰、忽略节点差异，以及把缓存预热机制当永久修复；预热只覆盖可预测峰值，削峰、限流和降级参数仍需压测。
基于前半部分得到的访问频率、回源流量和对象体积排行，应把候选热点键按“可重建性”和“失效影响”分级。不同参数、编码或路径可能映射到同一对象，热点键识别必须统一键规范；命中后字节流量仍高时，还要排查键冲突、压缩失效和重定向。
缓存击穿分析不能只看未命中。预热结束、TTL 同时到期、对象被删或刷新失败，都会让并发请求同时穿透。日志应关联 cache_status、对象版本和失效时间，统计同键的 miss 并发、等待时长与回源成功率。源站返回 404、403、5XX 时，先区分对象不存在、权限错误和瞬时故障，再采用短时负缓存、鉴权结果缓存或 stale-while-revalidate，避免把业务错误当成击穿。
回源并发控制宜放在 CDN 回源层。最容易踩的坑，是只靠单台应用实例的进程锁，这既无法覆盖多节点，也不能限制总量。单飞请求可把同键并发合并为一个回源请求，但等待者要有超时与降级结果；信号量或令牌桶限制全局并发，分布式锁只负责协调。临近过期的键应提前刷新并随机抖动；源站不稳时快速熔断并返回最近成功版本，阻断失败重试。
源站保护策略还应隔离普通回源、预热和后台刷新，后台刷新可暂停，核心交易优先。重试须指数退避、随机抖动并限制次数；遇到 429、503 不得无条件重试，否则跨节点重试链仍会形成新风暴。
缓存预热机制上线前，应按峰值 QPS、对象大小和回源预算估算速率，分批导入高频、可重建对象。逐项确认：①热点键清单与参数规则已版本化；②同键合并、并发上限、排队超时和熔断阈值已压测；③TTL 带抖动并支持提前刷新；④源站队列与 CDN 配额隔离；⑤后台刷新可暂停，重试有上限；⑥预热失败可重放且不挤占在线流量；⑦监控能按键、节点、地域拆分命中率、回源 QPS、排队长度与错误率。上线前按“到期、删除、刷新失败、源站变慢、热点更新”演练，并核对降级内容、告警阈值、回滚开关和责任人。
先以小流量灰度观察一个完整 TTL 周期，回源并发持续低于预算且 P95 延迟稳定后再放量。治理目标不是禁止回源，而是让热点和故障时的压力始终处于源站承受范围内，同时保证关键对象可用、更新可追踪、异常可回滚。
