单层缓存不够用，因其存在网络延迟（Redis RTT 0.2–2ms vs 本地纳秒级）、服务抖动易致穿透、连接数限制降低命中率，且无法缓冲雪崩时的瞬时数据库压力；多级缓存按频次、一致性、失效成本分层，如 APCu→Redis→MySQL，通过职责链解耦各层读写逻辑，确保空值缓存、并发控制（Redis层SETNX）、key隔离与分级监控。
为什么直接用 Memcached 或 Redis 单层缓存不够用？
当业务增长到一定规模，单点缓存会成为瓶颈：网络延迟、服务抖动、连接数限制都会导致缓存命中率下降。比如 Redis RTT 通常在 0.2–2ms，而本地内存读取是纳秒级；再比如缓存雪崩时，所有请求穿透到数据库，单靠远程缓存无法缓冲瞬时压力。
多级缓存不是“堆得越多越好”，而是按访问频次、一致性要求、失效成本分层。典型组合是：APCu（进程内）→ Redis（集群共享）→ MySQL（兜底源）。职责链模式在这里的作用，是把“查一级没命中就查下一级”的逻辑解耦，避免硬编码嵌套 if ($a = getA()) { ... } elseif ($b = getB()) { ... }。
怎么用职责链组织 CacheHandler 类？
每个处理器只负责自己那一层的读写和是否继续传递，不关心上游或下游。关键点在于：上层失败必须明确返回 null（而非抛异常），下游才可接管；且每层需定义自己的过期策略和 key 命名空间，避免互相污染。
-
ApCuHandler：使用apcu_fetch()，不设 TTL（由 APCu 自身 TTL 控制），key 加前缀如"apcu:{$key}" -
RedisHandler：用Redis::get()，支持自定义 TTL，key 如"redis:{$key}"，并确保连接复用（Predis\Client的 persistent 连接或Redis扩展的长连接） -
DatabaseHandler：仅作兜底，查完立刻写回上层缓存（注意避免击穿，可用setnx+ 随机延时防并发）
链式调用示例：
立即学习“PHP免费学习笔记（深入）”；
$handler = (new ApCuHandler())
->setNext(new RedisHandler($redis))
->setNext(new DatabaseHandler($pdo));
$value = $handler->handle('user:123');
handle() 方法里哪些细节决定成败？
不是简单地“没拿到就 next”，容易踩的坑集中在三处：空值缓存穿透、并发重建、跨层 key 冲突。
- 空值必须缓存：若
DatabaseHandler返回null，仍要调用$this->next->set(...)写入空值（带短 TTL，如 60s），否则重复穿透 - 并发控制放在哪一层？推荐在
RedisHandler层用SETNX占位，成功者加载数据并写入全链，失败者等待后重试（避免每层都加锁） - 各层
get()必须用不同 key：不能所有层都用原始$key，否则ApCu里存了旧值，Redis更新了新值，会导致不一致 - 注意
ApCu的进程隔离性：FPM 模式下每个 worker 有独立 APCu 空间，重启 worker 后缓存丢失，不适合存长期稳定数据
性能和一致性怎么权衡？
多级缓存天然存在最终一致性。例如用户更新头像后，ApCu 层可能还缓存着旧图 URL，直到自然过期或被主动清除。解决思路不是强一致，而是分场景控制：
- 高频读+低频写（如商品标题）：允许
ApCu存 5 秒，Redis存 30 分钟，用版本号或时间戳做 key 后缀，写时批量 del - 强一致要求（如账户余额）：跳过
ApCu，直连Redis，用 Lua 脚本保证读写原子性 - 冷热分离：用
Redis的OBJECT IDLETIME或 LRU info 统计热度，自动将热 key 推送至ApCu，无需人工配置层级
最易被忽略的是监控——必须对每层的 hit/miss 比率、平均耗时、失败原因（连接超时？序列化失败？）单独埋点，否则链越长越难定位慢在哪一级。
