Redis 缓存穿透怎么用空值保护：TTL、并发回源与失效边界

缓存穿透大多不是 Redis 本身故障，而是大量请求反复查询数据库里根本不存在的数据。比如恶意请求批量扫随机商品ID，或是业务侧残留了大量已删除记录的旧链接，应用每次查Redis没命中就直接打数据库，最后再把库返回的空结果直接抛给前端。给这些不存在的查询结果设置一个短TTL，就能让同一无效ID的后续请求在一段时间内直接在缓存层挡住，不用反复往数据库回源。

空值保护的关键不是“把空字符串永久写进 Redis”，而是给空结果一个足够短、可主动失效的生命周期，并在读取、创建和并发回源之间保持一致。

先把一次查询拆成三个结果

应用读取商品时，缓存层至少要区分“缓存没有这个键”“缓存明确记录了不存在”和“缓存里有正常对象”三种情况。最容易出错的写法是把三者都映射成空字符串：这样既无法判断是否应该回源，也可能把正常的空字段误判成不存在。

value, err := rdb.Get(ctx, key).Result()
switch {
case err == nil && value != "__NULL__":
    return decodeProduct(value)
case err == nil && value == "__NULL__":
    return ErrNotFound
case errors.Is(err, redis.Nil):
    // 真正的缓存未命中，继续访问数据库
default:
    return err
}

示例中的标记只是演示协议，生产代码应选择不会与真实序列化结果冲突的格式，并把判断封装在缓存适配层，不要让每个业务函数都自行比较字符串。

用短 TTL 写入空结果

数据库确认没有记录后，再写入空值标记。TTL 的目的在于吸收短时间内重复出现的无效请求，而不是让缓存永久记住“没有这条数据”。常见做法是正常对象使用较长缓存时间，空值只保留几十秒到几分钟，具体数值要结合创建频率、请求量和数据库承载能力压测后确定。

if errors.Is(err, sql.ErrNoRows) {
    // 空值 TTL 只用于防止短时间重复回源
    return ErrNotFound, rdb.Set(ctx, key, "__NULL__", nullTTL).Err()
}
if err != nil {
    return err
}
return rdb.Set(ctx, key, encode(product), normalTTL).Err()

写入失败不能覆盖原始数据库错误，也不能因为缓存不可用就把“未找到”变成“服务正常返回空对象”。缓存是保护层，数据库结果仍然是业务判断的来源。

并发回源时要处理同一个键

短 TTL 只能拦截后续重复请求，不能阻止缓存刚过期时的一群请求同时回源。可以按业务需求使用单飞、互斥锁或带过期时间的短锁，让同一个商品键只有一个请求查询数据库，其余请求在短暂等待后重新读取缓存。锁本身也必须有过期时间，并且释放时要校验持有者，避免误删其他请求的锁。

如果项目暂时不引入并发合并组件，至少要把回源超时、数据库连接池状态和每个键的失败次数记录下来。看到数据库 QPS 随着不存在 ID 数量同步上升时，说明空值策略可能没有命中，或是空值 TTL 设置得太短。

新建数据时主动删除空值

空值缓存会带来一个反直觉问题：某个商品第一次查询不存在，随后管理员马上创建了它，但 Redis 里还留着之前写入的空值。这时即使数据库已有记录，读请求仍会在空值 TTL 内得到不存在的返回。创建、恢复和导入数据的成功路径都应删除对应缓存键，或者直接写入最新对象，而不是等待空值自然过期。

if err := repo.Create(ctx, product); err != nil {
    return err
}
// 创建成功后清掉可能残留的空值或旧对象
return rdb.Del(ctx, productKey(product.ID)).Err()

删除失败要进入可观测的补偿流程，例如发送一条待重试消息或记录待处理键。不要把“缓存删除失败”静默吞掉，否则问题只会在用户再次读取时暴露。

运行检查：确认保护层真的生效

可以用一个全新的不存在 ID 做小范围验证：第一次请求应出现一次数据库查询并写入空值；在 TTL 内重复请求不应继续增加数据库查询次数；等待过期后再次请求才允许回源。随后创建同一 ID，再立即发起请求，应该能读到新对象，而不是继续命中空值。

# 只观察测试键，不要在生产环境批量清理
redis-cli TTL product:missing:9001
redis-cli GET product:missing:9001

验收时同时看应用日志、数据库慢查询计数，以及 Redis 的命中率。只看 Redis 命中率是不够的：如果空值标记写入失败，命中率可能没有明显变化，但数据库回源次数已经升高。

几个容易忽略的边界

• 不要把所有数据库异常都缓存成空值；连接失败、超时和权限错误都不是“数据不存在”。
• 不要让空值标记没有 TTL；后续数据被创建时会形成长期错误返回。
• 不要只在查询接口加删除逻辑，后台导入、批量恢复和异步消费也可能创建同一个键。
• 不要用随机无效键做无限制压测；先设置请求上限并观察数据库连接池负载。

相关问题

空值 TTL 应该和正常缓存一样长吗？

通常不应设置成一样长。空值主要用来吸收短时间重复请求，过长会放大新建数据后的旧结果问题；正常数据则可以按业务更新频率设置更长的过期时间。

缓存击穿和缓存穿透是一回事吗？

不是。穿透是请求查询根本不存在的数据，空值保护针对的是它；击穿通常指热点数据失效后大量请求同时回源，需要互斥、单飞或提前刷新等其他策略处理。

Redis 不可用时要不要继续访问数据库？

要由业务的降级策略决定。可以在有明确限流和连接池保护时有限回源，也可以快速失败；不要因为 Redis 故障而无限放大数据库压力。

总结

空值保护的最小闭环是：区分未命中与明确不存在，给空值设置短 TTL，在热点键并发回源时做合并，并在数据新建或恢复后主动删除空值。最后用数据库查询计数和实际TTL效果验收，而不是只看代码里是否调用过一次 SET。