商协会系统里，会员详情、活动详情这类数据读多写少，上缓存是标准动作。但上了缓存不等于高枕无忧——我们线上出过三次问题，事后复盘发现都是同一类原因：缓存并没有坏，是用法让它失效了。
这篇把三类典型故障的成因和对策整理一遍。
第一类是穿透：查询一个根本不存在的键。
会员id 是数字自增的，有人用脚本循环请求不存在的 ID，缓存里查不到，每次都打到数据库上。缓存形同虚设，数据库连接池很快被打满。
对策有两层。第一层是空值缓存——数据库也查不到的时候，往缓存里写一个空标记，过期时间设短一点，比如一分钟到五分钟。这样同一个不存在的 ID 在短时间内不会反复穿透。
第二层是布隆过滤器。它的作用是前置判断"这个键是否存在"，不存在的直接返回，连缓存都不查。特点是内存占用极小，但有误判率——它会把不存在的判成存在（不会漏判），所以放行之后的请求仍然要走缓存和数据库。这个特性决定了它是用来挡掉大部分无效请求的，不是用来做精确判断的。
需要注意的是，布隆过滤器要在数据写入时同步添加，删数据时它不支持删除。会员这类基本不删的数据很合适；如果是频繁增删的场景，要考虑计数布隆过滤器或者定期重建。
第二类是击穿：某个热点键过期的瞬间，大量请求同时涌进来。
典型场景是热门活动的详情页。这个键被高频访问，正好在某一刻过期，成百上千个请求同时发现缓存没了，一起去查数据库、一起重建缓存。数据库在这一瞬间承受的压力，跟完全没上缓存时差不多。
对策是重建过程加互斥。第一个发现缓存失效的请求拿到锁去查库重建，其他请求要么短暂等待后重试读缓存，要么直接返回兜底数据。
async function getActivity(id) {
const key = `act:detail:${
id}`;
const cached = await redis.get(key);
if (cached) return JSON.parse(cached);
const lockKey = `lock:rebuild:${
id}`;
const token = randomUUID();
const got = await redis.set(lockKey, token, 'PX', 3000, 'NX');
if (got) {
try {
const data = await db.activity.findById(id);
// 数据库也没有，写空值防穿透
await redis.set(key, JSON.stringify(data ?? {
}), 'EX', 300 + Math.floor(Math.random() * 120));
return data;
} finally {
await redis.eval(
`if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end`,
1, lockKey, token
);
}
}
// 没拿到锁：短暂等待后重读缓存，拿不到就返回兜底
await sleep(50);
const retry = await redis.get(key);
return retry ? JSON.parse(retry) : null;
}
这里有个改进点值得提：更好的做法是逻辑过期，也就是缓存里存一个业务上的过期时间戳，物理上永不过期。请求发现逻辑时间到了，返回旧值的同时触发异步重建。这样用户完全感觉不到延迟，也不会有集火。上面的代码是物理过期的互斥重建版本，逻辑更直白，适合大多数场景。
第三类是雪崩：大批键在同一时刻集体过期。
常见于批量预热或者定时任务刷新的场景——一次性把几千个会员详情写进缓存，过期时间都设成一样的，到点全部失效，数据库瞬间被压垮。
对策很简单：过期时间加随机抖动。比如基础过期时间三百秒，再加上零到一百二十秒的随机值，让失效时间分散开。上面代码里的那串随机数就是干这个的。
再稳妥一点可以做多级缓存：本地缓存加分布式缓存，本地的过期时间更短，即使分布式缓存整批失效，本地还能扛一阵。代价是一致性变差，适合对实时性要求不高的展示类数据。
还有个前置动作是预热。活动开放报名这种可预知的热点，提前把数据刷进缓存，别等流量来了再建。预热的时候也要注意打散过期时间，否则预热本身就成了雪崩的源头。
三个方案之外，有两条基础规则比什么都重要。
一是缓存的键设计要能失效。会员详情用 member:detail:${id} 这类带 ID 的键，改了数据能精确定位删除；不要用列表查询条件拼出来的复杂键，改一条数据你不知道该删哪些键。
二是监控要盯三个指标：缓存命中率、数据库 QPS、缓存键的数量变化。命中率突然掉下来通常说明有穿透或者雪崩正在发生，数据库 QPS 尖峰往往对应击穿。这三个指标不做告警，等用户反馈就晚了。
我们这边在跑的商会管理系统叫未来漫城·商会互联平台，会员和活动详情走的就是空值缓存加互斥重建这套，过期时间带随机抖动，热门活动开放前会做一次预热。上线之后再没出现过缓存失效导致的数据库压力。
最后提醒一句：这些防护都是成本。会员量小、访问量低的商协会，单靠空值缓存加随机过期就够了，别一上来就上布隆过滤器和逻辑过期。先把监控做好，看数据再决定加哪一层。
