PHP项目Redis缓存三大问题需区分应对：穿透是查不存在ID致DB全表扫描，用参数校验、空值缓存、布隆过滤器；击穿是热点key过期瞬间并发查库，用互斥锁、逻辑过期、本地缓存；雪崩是大批key同时失效，用TTL随机化、多级缓存、预热熔断。
PHP项目用Redis做缓存，真正上线后常被三类问题拖垮：穿透让数据库反复查空数据、击穿在热点key过期瞬间压爆连接池、雪崩则让整批key同时失效引发流量海啸。这三者不是“差不多的问题”，而是触发机制、影响范围和应对逻辑完全不同的故障类型，必须分清楚再动手。
缓存穿透：查一个根本不存在的ID
典型表现是大量请求带着非法或随机ID（比如id=-1、id=999999999）直冲数据库，Redis完全不拦，每次都是全表扫描。关键点在于：数据库没数据 → 不写缓存 → 下次还来查。
- 优先加参数校验：接口层拦截明显非法值，如ID≤0、超长字符串、非数字字符，直接返回400，不进缓存逻辑
- 空值缓存兜底：查库为空时，往Redis写一个占位符（如"NULL"），设短过期时间（60秒～5分钟）。注意避免恶意刷大量不同非法ID导致内存膨胀
- 布隆过滤器防攻击：启动时加载所有有效主键到布隆过滤器（Bloom Filter），查询前先过一遍。它不会漏判“不存在”，但可能误判“存在”——这刚好符合场景：说不存在就真不查，说存在再走缓存/数据库流程
缓存击穿：单个热点key过期那一秒
比如首页商品、秒杀库存这类高频访问key，一旦TTL到期，几十甚至上百并发请求同时发现缓存空了，全去查库重建，数据库瞬间被打满。它只影响一个key，但并发强度极高。
- 用互斥锁控制重建：查不到缓存时，先尝试加分布式锁（可用Redis的SET key value NX PX 3000）。只有拿到锁的请求去查库并回写缓存；其他请求等待几毫秒后重试读缓存
- 逻辑过期替代物理过期：缓存值里额外存一个“逻辑过期时间戳”。过期后不删key，而是由第一个请求异步刷新，其余请求继续用旧值，保证服务不卡顿
- 本地缓存预热：对极热key，在PHP进程内加一层Caffeine或APCu缓存，降低Redis访问频次，也减少锁竞争
缓存雪崩：大批key在同一秒集体消失
常见于批量设置相同TTL（比如全部设2小时）、系统重启未预热、或Redis集群节点宕机。监控上会看到命中率断崖下跌，数据库QPS飙升，且请求分散在大量不同key上。
立即学习“PHP免费学习笔记（深入）”；
- TTL随机化：写入缓存时，基础过期时间叠加一个随机偏移量（如3600 + rand(0, 600)），打散过期高峰
- 多级缓存兜底：本地缓存（APCu）+ Redis组成两级。本地缓存设较短TTL（如1分钟），Redis设较长TTL（如1小时）。本地失效后才查Redis，Redis失效后再查库
- 缓存预热与熔断：服务启动或低峰期主动加载热点key；当数据库慢查询率超过阈值（如30%），自动降级为返回本地缓存旧数据或默认值
实际落地时，别指望一个方案通吃。穿透靠布隆过滤器+空值双保险，击穿靠锁+逻辑过期组合使用，雪崩靠随机TTL+多级缓存分层扛压。重点不是代码多炫，而是每个环节有对应监控：Redis命中率、空查询占比、锁等待时长、本地缓存命中率——这些指标一波动，就能快速定位是哪位“兄弟”来了。
