缓存穿透是指查询根本不存在的key导致请求直达数据库，isset($cache[$key])无法防御因其不缓存“不存在”结果；需将空值以短ttl存入缓存，并用redis exists()精准判断存在性，结合布隆过滤器分层拦截。
缓存穿透是什么，为什么 isset($cache[$key]) 挡不住
缓存穿透本质是查一个**根本不存在的 key**，比如恶意请求 user_id=9999999999 这种非法 ID，缓存没命中，DB 也没数据，每次请求都打到数据库。你用 isset($cache[$key]) 或 array_key_exists() 判断缓存存在与否，但空值本身没被缓存，下一次照样穿透。
关键点在于：不是“缓存没设好”，而是“没把「不存在」这个事实也当有效结果存下来”。
- 空值缓存必须带较短过期时间（比如 2–5 分钟），否则真实数据上线后长期不可见
- 布隆过滤器不能直接用 PHP 原生数组模拟——它需要位运算和多个哈希函数，手写易出错且不省空间
- 如果用
Redis::setex($key, 300, 'NULL')存字符串'NULL'，记得业务层要显式判断该字符串，不能只靠=== null
用 Redis 实现空值缓存的实操要点
核心动作就三步：查缓存 → 查 DB → 把「空」也塞进缓存。难点在怎么区分「缓存未命中」和「查到了空结果」。
- 不要用
get($key) === false判断是否存在：Redis 返回false可能是网络失败、超时或真没值，得用exists($key)单独探活 - 空值推荐存成 JSON 字符串
'{"hit":false,"ts":1717023456}'，比纯字符串更易扩展字段（比如加 trace_id） - 过期时间别硬写数字，建议用配置项：
$ttl = $config['null_cache_ttl'] ?? 300，方便灰度调整 - 注意 PHP Redis 扩展版本差异：
Redis::setex()在 phpredis 5.3+ 支持毫秒级 TTL，但老版本只认秒，误传毫秒会导致缓存存几百年
if (($cached = $redis->get($key)) !== false) {
return json_decode($cached, true) ?: ['data' => null];
}
$data = $db->fetch("SELECT * FROM users WHERE id = ?", [$id]);
if (!$data) {
$redis->setex($key, 300, '{"hit":false}');
return ['data' => null];
}
$redis->setex($key, 3600, json_encode(['hit'=>true, 'data'=>$data]));
return ['data' => $data];PHP 里要不要自己实现布隆过滤器
答案很明确：**不建议**。布隆过滤器的价值在于内存极省 + 查询 O(1)，但 PHP 是进程模型，每个请求都要加载/初始化 filter，反而容易吃爆内存或引入竞态。
立即学习“PHP免费学习笔记（深入）”；
- 如果你用的是 Redis 7.0+，直接上
BF.RESERVE+BF.ADD，配合BF.EXISTS，PHP 层只做命令透传即可 - 想用纯 PHP？Composer 有
colinmollenhour/php-redis-bloom，但它依赖phpredis的rawCommand，线上环境常因扩展版本不匹配挂掉 - 布隆过滤器的 false positive 率要提前算好：100 万 key、误判率 1%，需要约 1.2MB 内存；PHP-FPM worker 里常驻这个 filter，内存碎片会加剧
组合策略：空值缓存 + 布隆过滤器怎么配才不翻车
真正上线时，二者不是二选一，而是分层拦截：布隆过滤器挡掉 99% 的非法 key，空值缓存兜底处理漏网的「合法但无数据」key。
- 布隆过滤器只存「已确认存在的 key」，比如用户注册成功后立刻
BF.ADD user_bf $id；千万不能把所有查询过的 key 都往里塞，否则误判率飙升 - 空值缓存的 key 命名要和布隆过滤器区分开，比如布隆用
bf:user:exists，空值用cache:user:9999999999，避免互相覆盖 - 上线前必做压测：用脚本生成 10 万个随机 ID（其中 9 万非法），观察 Redis
INFO memory的used_memory是否线性增长——布隆 filter 膨胀快说明哈希函数或容量设错了
最麻烦的其实是冷启动：新服务刚上线，布隆过滤器为空，所有请求都会穿透。这时候空值缓存就是唯一防线，它的 TTL 和降级逻辑必须经过验证。
