缓存失效需从键设计、过期策略、客户端行为三层面协同约束；setex() TTL 失效常因 pipeline/事务未提交、Redis 版本过低、集群未用 hash-tag、随机数不安全或 maxmemory-policy 拒绝写入所致。
缓存失效不是“修一下就能好”的问题，而是必须从键设计、过期策略、客户端行为三个层面同时约束，否则补丁越打越多。
setex() 设置的 TTL 为什么没生效？
PHP 的 setex() 看似简单，但实际受 Redis 服务端配置和客户端连接模式双重影响。常见失效不是代码写错了，而是 Redis 没真正收到带 TTL 的指令。
- 检查是否用了
pipeline或multi/exec：在事务块中调用setex()，若未正确提交，TTL 不会落地 - 确认 Redis 版本 ≥ 2.6.12：旧版对
setex的原子性支持不完整，可能只设了值、丢了过期时间 - 集群模式下避免直接用
setex()对非 hash-tag 键操作：比如user:1001会被散列到不同槽，而user:{1001}:profile才能保证同节点、同生命周期 - 用
redis-cli手动验证：TTL user:1001返回-2（key 不存在）或-1（永不过期），说明写入失败或被覆盖
随机 TTL 真的能防雪崩？关键在怎么“随机”
单纯 rand(300, 600) 在高并发下仍可能撞出局部集中——比如 100 个请求在同一秒内执行，mt_rand() 种子若未重置，结果高度趋同。
- 改用
random_int(300, 600)：PHP 7+ 提供密码学安全随机数，避免伪随机碰撞 - 把“随机偏移”加在业务逻辑层而非缓存层：比如用户数据按
userId % 10分组，每组固定加+$group * 30秒，比纯随机更可控 - 禁止在 CLI 脚本中复用同一随机种子：Web 请求天然隔离，但定时任务若用
swoole或常驻进程，需每次显式random_bytes(16)初始化
Redis 集群里缓存总“找不到”，大概率是 key 分片错位
PHP 客户端没启用 hash-tag 解析，或 key 命名没包裹大括号，会导致同一个业务实体的数据被分到不同节点，读写分离时必然失效。
立即学习“PHP免费学习笔记（深入）”；
- 必须用
{}包裹实体标识：如order:{12345}:items，而不是order:12345:items—— 只有花括号内部分参与 CRC16 计算 - 禁用 phpredis 的
redis.cluster模式：它不支持原生集群的 MOVED/ASK 重定向，应改用Predis\Client并配置'cluster' => 'redis' - 检查
CLUSTER NODES输出：若发现某 key 对应的 slot 被分配到已下线节点，说明集群拓扑未同步，需执行redis-cli --cluster fix
空值缓存为什么还是穿透？布隆过滤器没起作用
空值缓存（如 setex('user:-999', 60, '')）只能挡住重复请求，对新出现的非法 ID 完全无效；布隆过滤器若未随数据库变更实时更新，就是摆设。
- 布隆过滤器必须与写库联动：用户注册成功后，立即
bf.add users_bf 1001；删除用户时，无法删除布隆项，所以要配合定期重建（如每天凌晨全量同步） - 空值缓存 TTL 必须短于业务容忍窗口：比如订单查询超时是 2 秒，空值最多缓存 5 秒，否则错误响应会滞留太久
- 不要依赖
get()返回false判定为空：phpredis 在连接失败时也返回false，应先用ping()或异常捕获确认服务状态
最易被忽略的一点：Redis 的 maxmemory-policy 若设为 noeviction，内存满时写入直接失败，setex() 看似成功返回 true，其实什么都没存进去——务必用 INFO memory 定期核对 mem_used 和 maxmemory 比值。
