凌晨大促零点，CDN 上约 10 万个商品详情键同秒到期，边缘节点集中回源。源站 CPU、连接池和数据库线程瞬间打满，原本 2 秒完成的请求拖到 30 秒，最终大面积超时。单个爆款键被集中刷新也会制造类似压力：批量过期造成多键流量尖峰，热点键失效则是单键并发风暴。只盯缓存命中率，容易漏掉两者叠加形成的源站雪崩。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：tmhhost（全球代理网络），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
{PROMO}
一、热点键失效与批量过期，冲击路径并不相同
热点键失效发生在少数键承载极高并发时。缓存被刷新、淘汰或因发布切流失效后，多地边缘节点拿着同一键同时回源，若未合并请求，源站会重复执行上百次重建。批量过期源于大量键共享相近 TTL，或被任务集中删除，短时间内缺失键总数陡增。前者看单键并发，后者看失效键规模；两类风险还可能同时出现。
治理应组合使用：活动前用预热写入热门 URL、参数和变体；边缘侧用请求合并把同键并发回源折叠为一次；源站用互斥重建只放行一个重建者，其余请求等待或短暂重试；用随机化过期将基准 TTL 叠加随机窗口，打散到期时刻；用陈旧缓存服务在软 TTL 到期后返回旧对象并限额后台刷新。预热挡不住突发热点，随机 TTL 也救不了集中删除，不能只押一种手段。
二、从回源曲线判断雪崩是否发生
判断时按 1 分钟窗口对比基线。热点键失效通常表现为回源 QPS 激增、缺失键种类变化不大、单键并发陡升；批量过期则表现为缺失键种类和整体回源量一起上升。可计算“回源 QPS÷边缘请求 QPS”观察放大系数，再比较同一键的并发回源数与日常值。别只看总命中率，长尾键的高命中会掩盖爆款键已经击穿。
排查时可用 ServLlama 查看源站日志、进程负载和连接数，再按边缘命中、源站接收、缓存重建三段对齐时间戳。检查状态码、Age、连接池等待和数据库耗时：若回源已合并仍有重复查询，互斥范围或缓存键生成可能不一致；若键分布异常，可能是参数或编码造成碎片；若旧内容反复刷新，说明后台重建未限流。坑点包括预热后立即刷新、锁租期短于重建、只合并单一地域、陈旧服务误返个性化内容。源站还应限制回源并发，设置队列、熔断和等待超时，避免保护机制自身阻塞。
热点键失效：合并回源与互斥重建
热点键失效后，并发请求若直接回源，就会形成缓存击穿。可用请求合并阻断洪峰：单节点用 singleflight 共享一次重建；多节点使用分布式锁、领导者选举，或由支持跨节点合并的网关统一处理，避免各实例重复回源。
互斥重建只覆盖“确认未命中读取源站写入缓存”。拿到锁后必须再次查缓存，防止前一个重建者已经写回。锁要有持有超时和续期，等待者要有上限；锁失效或持有者宕机时应释放并重新选举，不能无限阻塞。
结果应完整生成、校验后，通过临时键原子切换，避免读到半成品。失败时保留旧值并记录指标，不要先删缓存再穿透；还要校验锁持有者标识，防止误删他人的锁。命中请求不应参与重建，否则互斥会变成全局串行点。
随机化过期与陈旧缓存服务
随机化过期用于打散批量键的失效时刻：在基础 TTL 上加入小幅抖动，并让不同节点采用略有差异的 TTL。范围太小削峰无效，太大则会降低数据新鲜度，因此应按业务容忍度设置。
当刷新尚未完成或源站短时故障时，可先返回带时间戳的旧值，再由后台单任务更新，即陈旧缓存服务。刷新失败时可按 stale-if-error 继续返回旧值，但必须设置最大陈旧时间、降级标记和告警，不能永久兜底。
常见误区是只加随机 TTL 却不合并热点回源，或开启陈旧服务却不设上限。余额、库存扣减、权限撤销等强一致场景应禁用陈旧返回；个性化数据必须按用户或租户隔离。压测要模拟热点到期、锁持有者宕机、源站超时和写缓存失败，并监控回源并发、锁等待、错误率及陈旧比例。
可执行检查清单：①确认热点键采用请求合并或跨节点互斥，且锁后二次查缓存；②确认锁有超时、续期、持有者校验和失败释放；③为批量 TTL 设置合理抖动，并为陈旧返回设置最大时长；④强一致数据已关闭陈旧服务；⑤监控回源 QPS、重建耗时、锁等待、击穿次数与陈旧比例；⑥定期演练源站超时、节点宕机和缓存不可用，验证降级、告警及恢复流程。
喜欢 
顶
难过
囧
围观
无聊
