缓存雪崩防护实战：随机TTL、缓存预热与降级策略

我到现在还记得那次事故的味道：凌晨1点37分，告警群一下子涌进来几十条消息，紧接着手机开始震动，没等我看完第一条，Redis集群CPU已经打到90%，数据库连接数告警弹出来的时候，整个交易链路已经拿不到任何价格数据了。那天晚上项目组折腾到快天亮才恢复，事后复盘的时候，方案里清清楚楚写着三个字：缓存雪崩。

很多团队在系统平稳的时候不会认真对待缓存优化，总觉得“Redis快得很，数据库扛得住”。但缓存雪崩这种坑，平时一点征兆都没有，一旦触发就是连锁反应。尤其现在业务量上来以后，一个晚上峰值流量可能是平时几十倍，如果缓存key在同一秒大规模失效，回源请求会瞬间把数据库打挂，数据库一挂，缓存也扛不住，整个系统就像多米诺骨牌一样往下倒。

这篇内容我想把缓存雪崩这件事讲透。我会结合自己做过的几次完整事故复盘，从雪崩的触发链路说起，再展开随机TTL、缓存预热、降级策略这三个核心手段，每一步都会讲清楚原理和实操细节，也会带一点LLM推理场景下的缓存命中率优化思路（毕竟现在大模型服务也和缓存这事杠上了）。无论你是后端开发、架构师，还是正在做大模型服务部署的工程师，这篇应该都能给你一些参考。

1. 一次“教科书级”缓存雪崩的完整复盘

1.1 事故链路：从整点失效到数据库被打挂

当时的情况是这样的：运营同学在后台配置了一批商品的限时促销价，由于批量导入工具的实现比较简单，所有商品写入缓存时都用了同一个过期时间——凌晨02:00整。到了02:00那一秒，差不多2万个缓存key同时过期，Redis的过期键淘汰线程开始批量清理，应用侧同时收到大量cache miss，于是每个请求都跑到数据库去查最新的促销价。

那一秒数据库收到的查询量大概是平时的60倍。MySQL的线程池一瞬间被打满，连接堆积，SQL执行越来越慢，慢SQL反过来拖垮了Redis的响应速度，应用侧的等待时间越来越长，最终雪崩式地把线程池耗尽，新请求进不来，老请求出不去，服务进入半死不活的状态。

这种事故的典型特征是：触发点非常明确，但破坏力会沿着调用链逐级放大。先死的是数据库，然后才是Redis，最后才是业务服务。很多人以为缓存雪崩是缓存服务挂了才叫雪崩，实际上更常见的是缓存服务和数据库互相拖累，最后一起崩。

1.2 穿透、击穿、雪崩：很多人一直没有分清楚

排查这类问题前，先把三个概念理清楚。它们表现相似，但成因和解法完全不同。

打个比方，穿透是“有人在大门上找一个根本不存在的门牌号，每次都跑去物业问一遍”；击穿是“唯一那扇最常用的门临时关了一下，所有人都堵在门口”；雪崩是“整栋楼的门一起关了，所有人都涌向物业，物业直接瘫了”。

1.3 事故复盘时最容易漏掉的一条链

那次事故还有一个让我印象特别深的细节：我们一开始以为是商品服务自己出了问题，排查了半天才发现真正的原因是另一个团队半夜上线了一个定时任务，任务逻辑是“每天凌晨把所有商品的当前价同步到缓存”。批量同步任务把所有key的过期时间设成了统一值，相当于人为制造了一个超大的集中失效窗口。

这也是雪崩排查中最难的地方——触发点可能不在你负责的服务里。所以做缓存优化的时候，不能只看自己代码里的设置，还要梳理所有可能往Redis里写数据的通道：后台任务、MQ消费者、数据同步工具、运营批量操作，这些都可能成为雪崩的源头。

2. 雪崩的成因图谱与确认方法：别急着改代码，先定位是哪一类

2.1 四类典型成因，对照你的业务排查

我把缓存雪崩的成因归纳成四类，每类的排查思路和处置策略都不一样。

第一类是过期时间集中。业务代码里写死了统一的TTL，比如所有商品详情缓存都是30分钟整，那么每小时的第0分钟和第30分钟就会形成两个集中失效点。批量任务写入时尤其容易踩这个坑，因为任务处理大量key通常会用一个固定过期时间。

第二类是热点key集中失效。哪怕大多数key的TTL是分散的，只要某几个key是超大热点，它们同时失效就能造成雪崩。比如大促期间的秒杀商品、热搜榜单、公共配置，这些key一旦失效，并发流量会是普通key的几百上千倍。我见过一个新闻类App，首页Top10文章的缓存同时失效，回源QPS直接打满存储层。

第三类是底层依赖故障引发间接雪崩。Redis自身出问题、网络分区、连接池耗尽，这种不一定是“失效”，而是“不可用”。这种情况下所有请求全部回源到DB，DB扛不住，整个调用链都开始雪崩。很多团队把缓存方案设计成“只有缓存挂了会影响性能，不会影响可用性”，但如果没做降级保护，这句话在极端情况下是不成立的。

第四类是缓存集群分片热点不均。Redis Cluster中某些slot集中了大量热点key，单个分片节点负载过高，甚至触发节点故障，故障转移过程中还有一部分slave提升为master之后，可能因为load过高继续抖动。这种属于基础设施层面的雪崩风险，需要从高可用架构层面解决，光靠业务代码里的随机TTL解决不了。

2.2 怎么确认你遇到的就是缓存雪崩

故障发生时，我的排查顺序是这样的：

1. 看缓存命中率曲线。正常情况命中率是平滑的，如果命中率在某个时间点突然跳水，说明大量key在同一时间段失效。
2. 看DB的QPS曲线和慢查询日志。雪崩时DB侧会同时出现慢查询数量飙升、活跃连接数打满、threads_running持续在高位。这些指标通常和缓存命中率跳水的时间点完全吻合。
3. 看应用日志里的cache miss来源。可以通过日志追踪一次请求处理中，哪些缓存的key是miss的，数量是否有成百上千的聚集。如果集中在相同的key前缀，多半是批量任务写入的key。
4. 看Redis侧expired_keys指标。Redis INFO里expired_keys字段会实时显示过期的key数量，凌晨02:00的那次事故里，这个字段在那一秒增量跳了几万——这是最直接的证据。

bash复制# 通过 INFO 观察 expired_keys 的增量
redis-cli -h your_redis_host info stats | grep expired_keys

如果想快速判断当前有多少key即将在同一秒过期，可以用DEBUG OBJECT或者SCAN遍历后逐个查看剩余TTL，不过生产环境不建议全量遍历，更稳妥的办法是在写入缓存的代码里埋点，统计设置的TTL分布。

2.3 找到成因之后，再决定用哪几招

很多团队的误区是：一听说缓存雪崩，就上来加随机TTL。但随机TTL只能解决第一类问题，对热点key集中失效、Redis宕机引发的雪崩几乎不起作用。真正靠谱的组合拳是：用随机TTL错开过期时间，用缓存预热消除冷启动时的集中回源，用降级策略兜住最坏情况。下面我分别展开讲这三招的实操细节。

3. 随机TTL：让“同时到期”变成“错峰失效”

3.1 为什么简单的TTL随机化这么有效

缓存雪崩的核心在于“并发回源”。就算只有1000个key，如果它们在1秒内全部过期，并且系统每秒能收到几万个请求，那这1秒内就会有大量请求打到DB。而如果这1000个key分散在5分钟内逐个过期，每一秒需要回源的请求量就变得非常小，DB完全可以轻松处理。

随机TTL的本质，就是把集中失效的“峰值”转化为均匀分布的“长尾”。假设原来的过期时间是3600秒，2万个key会在到期那一刻集中消亡；引入随机抖动区间后，每个key的过期时间在3600到4200秒之间均匀分布，相当于把同一时刻的并发压力摊开到了10分钟的时间窗口里。

3.2 随机幅度怎么选：过大过小都会出问题

这个细节我在项目里调过好几次。随机幅度太小，比如base TTL是3600秒，random只加0到60秒，错峰效果不明显。随机幅度太大，比如base TTL只有300秒，random加到600秒，会导致部分key存活时间过长，用户看到的数据不够新鲜，而且缓存容量也会上涨，驱逐策略会提前开始回收key。

我比较推荐的做法是：以业务能容忍的最大缓存陈旧时间为上限，抖动区间取base TTL的10%到30%左右。

如果业务对数据新鲜度要求很高，TTL本身就不能设太长。此时再叠加“逻辑过期”策略——缓存里不存实际TTL而是存业务过期时间，由异步线程去刷新，也可以达到错峰的目的。

3.3 代码落地：两种主流写法

在Java里最直接的做法是给TTL加上ThreadLocalRandom：

java复制public class CacheKeyManager {
    private static final int BASE_TTL_SECONDS = 3600;
    private static final int MAX_JITTER_SECONDS = 600;

    public void setProductPrice(String productId, String priceJson) {
        String key = "product:price:" + productId;
        // 关键点：每次写入都生成一个新的过期时间
        int ttl = BASE_TTL_SECONDS + ThreadLocalRandom.current().nextInt(0, MAX_JITTER_SECONDS);
        redisTemplate.opsForValue().set(key, priceJson, Duration.ofSeconds(ttl));
    }
}

在Python项目里逻辑一样：

python复制import random
import time

def set_cache_with_random_ttl(redis_client, key, value, base_ttl=3600, jitter=600):
    ttl = base_ttl + random.randint(0, jitter)
    redis_client.set(key, value, ex=ttl)

这里有一个我在生产环境踩过的坑：如果你在写代码时只是把随机值算了一次然后放进公共配置，所有key还是会在同一时刻过期——正确的做法是每次写入时都重新计算TTL，而不是用同一个固定值。还有，如果你用Spring Cache的@Cacheable注解，默认的TTL是全局统一配置的，需要实现自定义的RedisCacheManager来动态计算过期时间，否则注解方式没法直接加随机值。

java复制@Bean
public RedisCacheManager cacheManager(RedisConnectionFactory factory) {
    RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
            .prefixCacheNameWith("cache:")
            .entryTtl(Duration.ofSeconds(3600));

    // 注意：这里不能直接写死entryTtl，需要在CacheLoader或CustomKeyGenerator里做动态TTL
    // 实际项目中我通常会为不同缓存区域分别定义配置
    RedisCacheManager cacheManager = RedisCacheManager.builder(factory)
            .cacheDefaults(config)
            .withCacheConfiguration("productPrice", 
                RedisCacheConfiguration.defaultCacheConfig()
                    .entryTtl(Duration.ofSeconds(300 + ThreadLocalRandom.current().nextInt(30))))
            .build();
    return cacheManager;
}

也顺便提醒一句，随机TTL不要把base和jitter定义成常量后在多个服务里共享，假如服务是分集群部署的，JVM时间不严格一致，同一批key在同一个窗口期过期，仍旧可能出现集中的小高峰。更精细的控制可以用hash(key)做确定性抖动，而不是纯随机——这样同一key多次重建后的过期时间是稳定的，对缓存命中率更友好。

3.4 超出TTL之外的“反模式”要避免

还有一些团队会给热点key设置“永不过期”，然后用后台线程主动更新。这个策略本身没问题，但它依赖一个前提：后台刷新线程必须足够快、足够稳。一旦刷新逻辑出bug或者更新延迟，缓存中的值就会一直保持旧数据。更严重的是，如果缓存服务重启，所有“永不过期”的key会一次性全部丢失，系统等于瞬间进入冷启动状态——这是另一种形态的缓存雪崩，后面讲缓存预热时会再提到。

所以我的建议是：热点key可以用“逻辑过期时间”方案，也就是在业务字段里保存一个expireAt，读取时通过比较当前时间判断是否过期，过期后由后台任务刷新，而不是彻底放弃TTL。这样Redis重启后，最多丢失的是逻辑过期时间戳，进程内的异步刷新机制还可以兜底。

4. 缓存预热：把风险消灭在流量到达之前

4.1 什么时候需要做预热

随机TTL解决的是“已有缓存周期性失效”的问题，但还有一个更危险的窗口期：系统刚发布、缓存刚清空、流量洪峰刚刚抵达。这时候缓存里什么都没有，任何请求都是冷启动miss，系统会退化成直连DB的模式。如果不做预热，在大促或活动开始的那一刻，DB会直接撞上流量峰值。

我经历过一次典型的冷启动故障：版本发布时运维把Redis里某个业务前缀的key清掉了，正好第二天早上8点是上班高峰，结果一上午这个业务线的DB QPS打到平时的十几倍，核心接口平均延迟从30ms涨到2秒。后来我们做了一次缓存预热，把发布流程改成先预热再切换流量，问题就再也没有出现过。

需要预热的关键场景有三类：

• 大促/活动开始前：活动商品、价格、库存等核心数据提前灌入。
• 应用发布后：新版本代码切换前，先填充新版本依赖的缓存key。
• Redis重启/故障切换后：运维操作完成后需要自动触发预热任务。

4.2 经典预热流程：从日志统计到流量回放

我在项目里沉淀了一套预热流程，每一步都可以直接落地上线：

1. 准备热点key列表。从接入层访问日志或业务日志里，取出最近一天访问量Top N的key。数量按业务定，商品类系统一般预热Top 10000就够了，超出这个量级的key建议走惰性加载。
2. 按负载情况错峰执行。预热任务不能一口气把所有key一次性写进Redis，否则预热过程本身就是一次对源存储的集中访问。建议分批执行，每批500个key，批次间加少量延时。
3. 数据构建与校验。预热的来源数据不一定是DB——很多系统有离线数仓或对账系统，数据口径和线上不完全一致，如果直接灌入可能引发线上数据不一致的问题。所以预热前要校验数据版本，最好直接从DB查询并做序列化，保证和线上读写逻辑完全一致。
4. 验证预热覆盖率。预热结束后，抽样检查Redis中的key数量和内容长度，确认命中率预期达到80%以上。达不到就查一下是key列表过期还是批量任务写失败了。

bash复制# 简单的预热任务伪代码
# 1. 拉取热点key列表
hot_keys = get_hot_keys_from_log(top_n=10000)

# 2. 分批灌入缓存
for batch in chunks(hot_keys, size=500):
    for key in batch:
        value = load_from_db(key)
        ttl = compute_random_ttl(key)
        redis.set(key, value, ex=ttl)
    time.sleep(0.5)  # 控制回源压力

# 3. 抽样校验
check_sample_keys(hot_keys, redis)

4.3 预热时机的选择：发布流程中嵌入preload环节

预热不是事后补救，而是要嵌入到发布编排里。我们的做法是在滚动发布流程中增加一个preload阶段：新实例扩容完成后先不接流量，而是触发一次预热任务，等缓存命中率达到阈值后再把实例注册到负载均衡上。这样最坏情况下，也只有第一批流量会触发少量回源，不会出现全量回源。

如果用的是Kubernetes，可以在postStart钩子里做轻量预热，或者在Service的readinessProbe里加一条预热状态检查。

4.4 顺带聊聊：LLM推理服务的缓存命中率优化思路

最近大模型服务火起来之后，“缓存命中率”这个词又多了一层含义。vLLM这类推理框架里的缓存不再只是KV对，而是KV Cache——也就是transformer推理过程中已经计算好的Key和Value矩阵。关注vLLM如何优化大模型的缓存命中率的朋友应该知道，这类系统里有两个核心概念：一个是前缀缓存，另一个是KV Cache复用。

和Web缓存不太一样，LLM推理时重复计算历史token的开销非常大。比如一次多轮对话里，前面几轮的内容在每轮生成时都会被重新处理一遍，如果不缓存这些已生成token的KV状态，越长的对话浪费的算力越多。vLLM通过PagedAttention把KV Cache分块管理，并支持自动探测相同前缀，当新的请求前缀和之前计算过的前缀一致时，直接复用已有的KV结果，跳过prefill阶段，显存占用和首token延迟都能明显下降。

在这种场景下，缓存预热也是可以借鉴的思路：如果业务能预判哪些提示词（prompt）前缀会被高频使用，比如系统提示词、固定知识库前缀，可以提前对它们做一次“预计算”并驻留在KV Cache池里，让后续请求直接走缓存命中。这也解释了为什么现在很多服务端推理框架都在做“prompt前缀固定化”的工程规范——前缀越稳定，前缀缓存命中率越高。

虽然技术栈不同，底层的思路是一模一样的：把高频访问的数据在流量到达前处理好，减少运行时的重复计算和回源压力。

5. 降级策略：雪崩发生时的“最后一道闸门”

5.1 为什么随机TTL和预热还不够

有人可能会问：既然随机TTL错开了失效时间，预热也做了，是不是就不用管降级了？我的回答是：不够。随机TTL防御的是“大范围key周期性失效”，预热防御的是“冷启动”，但这两招都防不住Redis整体不可用、DB慢查询拖垮链路、突发流量远超预估这些黑天鹅。降级策略是整个缓存体系的安全兜底，可以在最坏情况下保住核心业务的可用性。

降级不是简单地把服务关掉，而是精细地把服务从“全量可用”切换成“核心可用”。设计降级方案时，要回答三个问题：降级后返回什么？触发降级的条件是什么？如何恢复？

5.2 三级降级体系：从缓存过期到兜底数据

我在实际项目中会把降级策略拆成三个等级：

L1本地缓存降级。当Redis不可用或超时时，应用进程内的本地缓存（Caffeine/Guava Cache）接住读请求。这个级别的数据在分布式环境下可能不是最新的，但至少能保证基础功能可用。实现时，本地缓存的容量不宜太大，一般每个实例限制在几百MB以内，过期时间也比Redis短，防止数据太陈旧。

java复制Cache<String, String> localCache = Caffeine.newBuilder()
        .maximumSize(10_000)
        .expireAfterWrite(Duration.ofSeconds(60))
        .build();

// 读流程：Redis -> 本地缓存 -> 兜底数据
public String getPrice(String productId) {
    String key = "product:price:" + productId;
    try {
        String value = redisTemplate.opsForValue().get(key);
        if (value != null) {
            localCache.put(key, value);
            return value;
        }
    } catch (Exception e) {
        // Redis异常时读取本地缓存
        String localValue = localCache.getIfPresent(key);
        if (localValue != null) {
            return localValue;
        }
    }
    String fallback = getFallbackPrice(productId);
    localCache.put(key, fallback);
    return fallback;
}

L2默认值/旧值降级。业务上允许返回旧数据时，可以在Redis里额外保存一份“最近一次成功的值”，甚至保存上次的TTL过期时间。Redis不可用的时候，直接把最近一次有效值返回给上层。这个方案的实现成本很低，只需要在写入缓存时多写一份“带永久TTL的旧值备份”。

有一点需要注意：核心交易链路如果涉及金额、库存这类非常敏感的数据，降级返回旧值可能带来资损或超卖风险，这时候宁可拒绝服务也要保证数据准确。所以L2降级要分业务评估，不是所有场景都适合。

L3熔断和限流。当并发量超过系统能处理的阈值时，触发熔断，直接把部分请求挡在门外，返回降级提示。这个级别相当于手术台上的“截肢保命”，虽然用户体验有损，但能保住系统不彻底瘫痪。实现上可以用Resilience4j、Sentinel等框架，也可以自己在网关层做简单的令牌桶。

5.3 保护数据库：回源并发的“闸门”

降级策略中有一个非常容易忽略的环节——回源数据库。缓存miss之后，如果1000个并发请求都去数据库查同一条数据，数据库压力直接翻了1000倍。这就是典型的缓存击穿，也是雪崩前最常见的放大器。

业内通用的做法是singleflight——将同一个key的多个并发请求合并成一个，只有一个请求真正去查DB，其他请求等待并共享这个结果。Go里golang.org/x/sync/singleflight很成熟，Java里可以用Caffeine的get(key, mappingFunction)或者自己维护一个ConcurrentHashMap+Future的请求合并器。

java复制// 用ConcurrentHashMap实现简单的singleflight
private final ConcurrentHashMap<String, CompletableFuture<String>> inflightRequests = new ConcurrentHashMap<>();

public String getWithSingleFlight(String key) {
    CompletableFuture<String> future = inflightRequests.computeIfAbsent(key, k -> 
        CompletableFuture.supplyAsync(() -> loadFromDB(k))
            .whenComplete((v, e) -> inflightRequests.remove(k))
    );
    return future.get();
}

在分布式多实例部署下，singleflight只是减少了单机内的重复请求，跨机器的回源可以用Redis分布式锁做二次控制，但锁的过期时间必须设置合理，防止持有锁的线程还没执行完锁就过期了，导致其他线程继续抢锁回源。

5.4 业务级降级的实际案例

我在一个交易类项目里设计过降级矩阵，每个场景单独定义降级后的表现，方便运营和技术一起决策：

每个降级动作都必须有开关控制，并且开关要能独立于代码发布实时生效。用配置中心（如Apollo、Nacos）管理降级开关和降级比例，出现问题时可以在10秒内完成全局降级，不需要重新发版。这一点非常重要，很多团队平时不配降级开关，真出了事只能干瞪眼改代码上线，等代码发出去系统已经崩了。

6. 稳定性验证与压测复盘：怎么确定雪崩防护真的有效

6.1 故障注入：故意制造一次缓存雪崩

代码写完不等于防护生效，我见过太多团队代码review的时候觉得没问题，上线后一压测就露馅。为了验证随机TTL、缓存预热、降级策略这套组合是否真的有效，一定要做故障注入演练。最常见的演练项目就是把Redis中某个业务前缀的key全部删掉，模拟“瞬时全量miss”。

ChaosBlade这类工具可以直接创建故障演练场景，比如模拟Redis延迟、Redis宕机、DB连接池耗尽。我们内部每个月会做一次随机故障演练，重点验证三件事：

1. 缓存全量miss时，数据库回源QPS是否被限制在安全水位以内。
2. Redis不可用时，降级逻辑是否按预期生效，接口是否仍然能返回降级数据。
3. 故障恢复后，缓存重建过程是否平稳，不会产生二次雪崩。

拿缓存全量miss的演练来说，操作步骤大致是：

bash复制# 通过脚本只保留指定前缀的key，其他全部删除
redis-cli --scan --pattern "product:price:*" | xargs -r redis-cli DEL
# 然后在监控页面上观察DB QPS、回源比例、错误率的变化

有时我们会故意把某个核心接口的缓存key改成固定的短TTL，比如全部改成剩余5秒过期，让它们在下一次高峰到来时同步到期。这种演练对随机TTL是否生效的验证非常直观：如果随机TTL生效了，即使基础数据同步到期，DB侧也不应该出现瞬时的超大QPS。

6.2 压测时需要盯住的关键指标

做压测或者故障演练的时候，想判断防护策略是否有效，不能只看接口成功率，要盯住几个核心指标：

• 回源比例：缓存请求中落到DB的比例，正常情况下应该小于5%，故障期间如果回源比例高于30%，就说明缓存保护已经失效。
• DB QPS曲线：理想情况下应该是一条平滑的线，如果出现尖峰，说明过期时间还是太集中。
• Redis命令耗时：如果get命令的平均耗时从0.5ms涨到10ms以上，缓存集群可能已经处于过载状态。
• 应用线程池活跃度：如果Tomcat/Netty线程池出现大量等待，说明上游服务或数据库响应变慢，需要触发降级。
• 降级开关触发次数：熔断限流的触发次数是否在预期范围，降级后业务成功率是否重新回到阈值以上。

建议把这些指标都接入Prometheus和Grafana，故障时直接看dashboard而不是临时写查询语句。我们每次演练都会保存当时的监控截图，和代码变更一起归档，方便后续复盘比对。

6.3 复盘SOP：不要只改代码，还要改流程

最后说说复盘。每次缓存雪崩事故处理完之后，我都会按一套固定模板把问题归档：

1. 时间线：从第一个告警到恢复的完整时间点，精确到分钟。
2. 影响范围：哪些业务接口受影响，影响时长多久，损失多少。
3. 根因分类：是TTL设置问题、批量任务写入问题、Redis运维操作问题，还是容量规划不足。
4. 触发条件：什么条件下这个故障可以再次被触发，如果条件仍然存在，说明没有真正修复。
5. 改进清单：每一项改进都要落到具体的负责人和deadline。

比较重要的一点是，每次事故都要检查自己团队的发布流程、定时任务管理和容量评估体系是否有漏洞。很多雪崩问题其实不是代码bug，而是流程缺失：批量任务没有review、TTL设置没有规范、发布步骤里没有缓存预热环节。我自己在经历了几次类似的深夜事故之后，专门整理了一份《缓存使用规范》，把TTL设计、key命名、预热要求、降级开关等全部写进团队开发规范，让新同学在写第一行代码之前就能看到这些约束。

7. 按业务特性组合策略：一套可复用的决策清单

如果你现在正在为团队的缓存系统做体检，不知道从哪里下手，可以参考我通常用的决策流程来梳理：

1. 列出所有写缓存的代码入口，包括业务代码、定时任务、MQ消费者、数据同步工具。
2. 检查每个入口的TTL设置，凡是使用固定TTL的地方都要改成随机抖动。
3. 找出访问量Top 100的key，为它们单独设计过期和刷新策略，必要时使用逻辑过期加后台刷新。
4. 梳理所有会一次性写入大量key的逻辑，比如促销批量上架、全量配置发布，这些场景一定要设计预热任务。
5. 为所有核心读链路的Redis操作设计降级路径，至少要做到“Redis挂了，本地缓存还能顶住几秒”。
6. 检查回源DB的路径有没有并发控制，没有singleflight或者分布式锁的，优先补上。
7. 把故障演练纳入日常运维，每隔一段时间故意制造一次缓存失效，验证防护策略没有退化。

这套检查流程执行下来，大多数团队都会发现自己系统里至少有三分之一的风险点是被忽视的。我在复盘过那么多次事故之后必须说一句：缓存优化这件事，方案不在多，关键在闭环——把每一层防护都落到底，然后验证它确实在工作。

最后再分享一个小技巧，我每次重构缓存代码的时候，都会在海量接口里保留一个特殊的开关，通过配置中心动态调整“是否启用随机TTL”和“是否启用降级”，这样在线上出了一点小问题时可以快速A/B验证，不必走完整的版本发布流程。这种小开关平时用不上，真到事故发生在凌晨2点的时候，能救命的往往就是这些看起来不起眼的准备。