缓存穿透是指高频查询根本不存在的key，导致请求直击数据库；典型表现是redis get返回none且db也无数据，需通过入口校验、空值标记（如"__null__"）、布隆过滤器（限可枚举场景）等多层防御。
缓存穿透是什么，为什么 get 返回 None 就得警惕
缓存穿透本质是查一个**根本不存在的 key**，导致每次请求都击穿缓存直抵数据库。典型表现：Redis 里 get 返回 None，DB 查询也返回空，但请求量不小——说明有人在刷无效 ID（比如订单号、用户 ID），或接口被恶意探测。
关键不是“没数据”，而是“没数据还高频查”。不拦住它，DB 很快被拖慢甚至挂掉。
- 常见错误现象：
redis_client.get("user:999999999")总是None，日志里这类 key 出现频率远高于正常业务分布 - 别只依赖「查完 DB 再写缓存」——如果 DB 也没查到，你又不写任何东西，下一次还是穿透
- 注意区分缓存雪崩（大量 key 同时过期）和缓存击穿（单个热点 key 过期瞬间并发查询），穿透是「从不存在」，不是「曾经存在」
用布隆过滤器拦截非法 key，但别直接手写 BloomFilter
布隆过滤器（Bloom Filter）适合做「存在性预检」：如果它说“不存在”，那一定不存在；如果说“可能存在”，还得去 Redis 查。但它本身有误判率，且需要预加载全量合法 key——这在动态 ID 场景（如自增 ID、UUID）里根本不现实。
所以实际中，不要为所有业务 key 建布隆过滤器，而应该聚焦在「可枚举、有规律、易守门」的入口上：
立即学习“Python免费学习笔记（深入）”；
- 例如用户登录态校验：用
user_id做布隆过滤前，先检查 token 是否格式合法、是否在有效期内——很多穿透请求连基础校验都过不去 - 对订单号这种看似随机实则有规则的字段（如前缀+时间戳+序列），可用正则或前缀树快速 reject 明显非法格式（如
"order:abc123"） - Python 里用
pybloom_live或bitarray手写布隆过滤器容易误设容量/误差率，建议只在离线预热、ID 池固定场景用；线上服务优先用更轻量的方案
setex 存空值？小心缓存污染和 TTL 同步问题
最常用也最容易翻车的方案：DB 查无结果后，往 Redis 写一个空值 + 短 TTL，比如 setex("user:999999999", 60, "")。它能挡穿透，但副作用明显：
- 如果业务逻辑把空字符串当有效值（比如某些字段允许为空），后续读到这个
""可能直接返回给前端，造成脏数据 - TTL 设太短（如 10s）挡不住突发扫描；设太长（如 1h）又可能把刚注册的新用户卡住——他还没写 DB，你却已缓存了“不存在”
- 多个服务共用一套缓存，A 服务写入空值，B 服务读到后可能误以为这是共识结果，不再走自己的兜底逻辑
- 推荐做法：统一用特殊标记值，比如
setex("user:999999999", 60, "__NULL__")，读取时明确判断if result == b"__NULL__": return None
用 pipeline 和 exists 减少穿透漏网，但别滥用 lua 脚本
单次请求里，如果要查多个 key（比如批量查用户信息），用 pipeline 批量执行 exists + get，比逐个 get 更高效，也能提前筛掉一批非法 key。
至于 Lua 脚本——它确实能原子性地完成「查缓存 → 查 DB → 写空值」，但要注意：
- Redis 集群模式下，Lua 脚本里的 key 必须落在同一个 slot，否则报
CROSSSLOT错误；用{user:123}这种标签方式强制路由，但会增加维护成本 - 脚本逻辑复杂后难调试，出错时整个 pipeline 失败，反而不如 Python 层分步控制清晰
- 真正需要原子性的场景其实不多：多数业务可以接受「短暂窗口内重复穿透」，只要 DB 有连接池限流 + 读写分离扛住压力即可
缓存穿透防御从来不是靠某一个开关解决的，而是层层设防：入口校验、参数归一化、空值标记策略、DB 查询限流——最常被忽略的是，压测时没模拟非法 key 流量，上线后才暴露。
