Cache::get()挡不住缓存击穿，因其仅读取且与Cache::set()无原子性；高并发下多个请求同时判定缓存缺失，全量回源查库并竞争写入，导致数据库压力激增和缓存覆盖。
ThinkPHP 5.1 中 Cache::get() 为什么挡不住缓存击穿
因为 Cache::get() 只读，Cache::set() 只写，两者之间没有原子性保障。高并发下多个请求同时执行 Cache::get($key) 返回 false，接着全去调 $db->find()，再全去 Cache::set($key, $data) ——这不是缓存，这是“并发写缓存竞赛”。数据库瞬时被打满，缓存还可能被脏数据覆盖。
关键点不是“有没有用 Redis”，而是“失效那一刻谁有资格重建”。TP 5.1 原生不提供互斥锁（Mutex）能力，必须自己补，且不能只靠 setnx 简单判断。
-
Cache::handler()->set($lockKey, 1, ['nx', 'ex' => 5])才是等效于 Redis 的SET lock:key 1 NX PX 5000，但前提是驱动是Redis且配置了'persistent' => true - 锁 key 和缓存 key 必须同 DB、同命名空间，比如缓存用
goods:123，锁就该用lock:goods:123，并确认配置中'select' => 0 - 别在模型的
getAttr或控制器里零散写锁逻辑——容易漏del、难复用、多实例部署时锁失效
用 Redis SET + Lua 脚本安全释放锁
直接 $redis->del($lockKey) 是危险操作：A 进程加锁后卡住超时，B 进程抢到锁并完成写入，A 恢复后又执行 del，把 B 的锁删了。下次请求进来，A 和 B 同时重建缓存，击穿重现。
必须用 Lua 脚本做原子校验释放：
立即学习“PHP免费学习笔记（深入）”；
eval "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" 1 lock:goods:123 1678901234
对应 PHP 封装建议：
- 锁 value 写成唯一标识，如
microtime(true).mt_rand(1000,9999)，避免不同进程误删 - TP 5.1 中调用方式：
Cache::handler()->eval($script, [$lockKey], [$lockValue])（需确认底层 Redis 扩展支持eval） - 如果驱动不支持
eval，退而求其次：用GET + DEL两步，但要在业务层加重试+超时兜底，不能裸奔
重试策略与锁超时怎么设才不放大问题
锁超时不是越长越好。若缓存 TTL 是 60 秒，锁却设成 30 秒，可能出现：A 拿锁查库慢（比如 DB 延迟突增），锁自动释放；B 立即抢到锁又查库，A 最终写入缓存，B 也写入——两个不同结果交替覆盖。
合理设定原则：
- 锁 TTL 必须 严格小于 缓存 TTL，建议为缓存 TTL 的 1/5～1/3（如缓存 300 秒，锁设 30～60 秒）
- 重试最多 3 次，每次间隔 20–100ms（用
usleep(50000)），避免请求堆积雪崩式放大 - 查库失败时，不要直接抛异常，应主动
del $lockKey并返回旧缓存（TP 支持Cache::get($key, null, true)强制读过期值，需驱动开启ignore_expire）
本地内存锁 + Redis 锁双层过滤有必要吗
有必要，但只对极热点接口有效。APCu 或 Swoole Table 做第一道轻量过滤，能拦掉本进程内重复请求，减少 Redis 网络开销和锁竞争压力。
示例场景：商品详情页 PV 百万+/天，单个 ID 请求集中在秒级洪峰。
- 先查
apcu_fetch("local:goods:123")，命中直接返回 - 未命中再走 Redis 互斥锁流程
- 成功写缓存后，顺手
apcu_store("local:goods:123", $data, 10)（本地缓存 10 秒即可） - 注意：CLI 模式下 APCu 不共享，Swoole 多 Worker 需用
Swoole\Table替代
真正容易被忽略的是锁 key 的命名一致性与连接池配置——'persistent' => true 和 'select' => 0 没配对，锁和缓存可能落在不同 DB 或短连风暴拖垮 Redis 响应，这时候再好的 Lua 脚本也救不了。
