ThinkPHP缓存穿透问题严重_利用布隆过滤器与空值缓存优化

缓存穿透这事儿，说起来其实挺常见的，但一旦被攻击或者流量异常，就是直接压垮数据库的节奏。最直接、最快速的做法，就是上“空值缓存”——哪怕查不到数据，也把结果存起来，设个短暂的过期时间。但这里面坑不少，尤其是用 ThinkPHP 的时候，一不小心就踩雷。

缓存穿透导致数据库被打崩，怎么快速止血

直接上空值缓存，这算是最简单也最快速的止血方案了。比如用户查一个根本不存在的 user_id=9999999，Redis 没命中，就会去打 DB，DB 返回 null——但你要做的，是顺手把 cache_set('user:9999999', null, 60) 写进去。即便值是 null，也得给它设个 60 秒过期。不然攻击者轮着刷一堆非法 ID，缓存永远不生效，数据库就悬了。 这里有个细节必须注意：ThinkPHP 的 Cache::set() 默认会序列化 null，存进去就变成了字符串 "b:0;"。等你取出来用 === null 判断，永远对不上。所以要关掉序列化，要么用 Cache::set($key, null, $ttl, ['serialize' => false])，要么统一用个标记值，比如 Cache::set($key, '__NULL__', $ttl)。别嫌麻烦，这一步决定了很多方案的可靠性。

布隆过滤器不是万能的，别在 TP 里硬塞 RedisBloom

布隆过滤器这玩意儿，听起来很高大上，但实际上在 ThinkPHP 里直接用起来，坑还是不少的。框架本身不直接支持，硬集成 redis-bloom 扩展或者 Lua 脚本，往往带来额外的运维成本和兼容问题。更务实的思路是：只对“固定、可预知”的 ID 空间做前置过滤。比如说用户表主键范围明确是 1~1000 万，那就可以考虑用本地位图（$bloom = new \SplFixedArray(20000000)）加上双 hash 函数做轻量级过滤。如果是商品 ID 这类不可预估的场景，优先走空值缓存加请求限流，比硬上布隆要稳得多。 常见错误包括：

• 用 md5($id) % size 当 hash 函数——分布不均匀，误判率直接飙升
• 把布隆过滤器放在 Cache::get() 之前，却没处理并发写入时的竞态，漏写频发
• 误以为布隆返回 false 就一定不存在——实际上它只保证“true 时一定存在”，false 仍然需要查缓存和 DB

ThinkPHP 的 cache 配置容易让空值缓存失效

TP 默认的缓存驱动，比如 File 或者 Redis，对 null 值的处理其实并不一致。File 驱动遇到空值会直接跳过写入，Redis 驱动默认序列化后存成字符串。这些隐藏在配置参数里的差异，一旦不注意，空值缓存就等于没开。 需要在 config/cache.php 中显式配置驱动参数，比如： 'redis' => ['host' => '127.0.0.1', 'port' => 6379, 'serialize' => false] 不然你执行 Cache::set('x', null)，实际存进去的是 "N;"，再用 Cache::get('x') === null 去判断，永远是 false。 另一个容易翻车的地方：TP 的 Cache::remember() 方法内部会先 get，再判断是否为空。如果缓存里存的是 "__NULL__" 字符串，它不会触发回调，直接返回字符串——所以空值缓存必须绕开 remember()，老老实实手写三段式逻辑，别偷懒。

高并发下空值缓存击穿，得加一层原子写锁

两个请求同时发现 user:123 缓存 miss，都去查 DB，都拿到 null，又都去 set 缓存——表面上看无害，但 DB 查询本身是有成本的，比如连了慢查询或做了复杂计算。一旦并发放大，数据库依然扛不住。 解决方案不是加分布式锁，那太重了。更轻量的是利用 Redis 的 SET key value EX 60 NX 原子操作：

if (false === Cache::store('redis')->handler()->set($key, '__NULL__', ['nx', 'ex' => 60])) {
    // 说明别人已经写进去了，当前请求直接放弃 set
}

注意：Cache::store('redis')->handler() 返回的是原生 Redis 实例（Predis 或 phpredis），这样才能调用底层命令。用 Cache::set() 无法实现这种原子性。 这件事很难指望框架来自动兜底，每次写空值缓存，都得自己多写两行判断。漏一次，就可能被扫出雪崩来。