Webman不能直接用Memcached扩展，因其原生扩展无连接池、多进程状态隔离导致缓存不一致、无熔断机制，易引发连接爆炸、脏读和锁失效；推荐改用webman/redis。
Webman 为什么不能直接用 Memcached 扩展
Webman 不支持原生 Memcached 扩展，不是配置问题，而是架构冲突。常驻进程模型下，每次 new Memcached() 都会新建 TCP 连接，Worker 进程数 × 并发量 = 瞬间打爆服务端连接数；更严重的是，各 Worker 进程间状态完全隔离，add() 和 get() 在不同进程里可能返回不一致结果，缓存击穿、脏读、锁失效全都会发生。
常见错误现象：Memcached::get(): failed to get key 频繁报错但服务端连接数正常；或同一请求在不同 Worker 上缓存命中率波动极大；或 set('lock', 1, 10) 后其他进程仍能成功 set —— 根本没锁住。
- 原生扩展无连接复用，每次 new 都是新连接
- 无心跳检测和自动重连，网络抖动后连接静默失效
- 不支持熔断降级，单点故障会拖垮整个 Webman 实例
Webman 多级缓存该分几层、每层存什么
APCu + Redis 是 Webman 最稳妥的两级组合，但职责必须严格切割，否则立刻出现本地有旧值、Redis 已更新的脏读。
APCu 只允许存三类数据：路由映射表、配置白名单、枚举字典——体积小（300（5 分钟），避免长期驻留导致内存泄漏。
Redis 存所有带业务逻辑的数据：用户详情、商品列表、搜索聚合结果。Key 必须含版本号，例如 user:detail:id_123:v3，避免因字段变更导致反序列化失败；绝对禁止存 session 或 订单状态——APCu 进程重启即丢，且无法跨 Worker 同步。
- 浏览器和 CDN 层由 Nginx 控制，与 Webman 无关
- Webman 内部不实现「进程内对象缓存」（如 Laravel 的 Cache::remember），易引发内存膨胀
- 不要在 APCu 里存任何带用户上下文的数据（如
user_token_123）
webman/redis 配置要点和高频踩坑点
Webman 官方唯一深度集成的缓存客户端是 webman/redis，它自带连接池、分布式锁、原子计数，不是简单封装 phpredis。
配置文件 config/redis.php 中，default 实例必须设 'database' => 0；若需多实例（如缓存、会话分离），新增 'cache' 和 'session' 即可，但每个实例的 database 值必须不同，否则 Redis SELECT 切库会出错。
性能关键参数：'pool_size' => 12（建议值，Worker 数 × 2～3）、'timeout' => 0.1（单位秒，超时必须设，否则阻塞协程）、'retry_times' => 2（网络抖动时自动重试）。
- 生产环境禁用
'password' => null，必须设强密码 - 不要手动调用
$redis->connect()，连接池会在首次get()时自动预热 -
setex()和set()+expire()效果不同：前者是原子操作，后者两步执行可能被中断
缓存穿透和一致性怎么兜底
缓存穿透不是加个空值就能解决。Webman 场景下，必须用 SETNX + GETSET 组合实现分布式锁，否则高并发下多个请求同时查 DB 再写缓存，穿透依然发生。
示例逻辑：先 setnx('lock:user:123', 1)，成功再查 DB 并 setex('user:123', 3600, $data)，最后 del('lock:user:123')；若 setnx 失败，就 sleep(10) 后重试，而不是直接返回空。
数据更新时，必须「先删 Redis，再改 DB」，而非反过来。否则 DB 更新成功但 Redis 删除失败，就会出现脏数据；删除失败要记录告警，不能静默忽略。
- APCu 缓存更新必须同步触发
apcu_delete()，不能依赖过期自动清理 - Redis Key 版本号变更时，旧 Key 要主动
del，避免残留 - 不要在事务里嵌套缓存操作，Swoole 下 MySQL 事务和 Redis 操作无法真正原子
实际压测中，2000 QPS 下 Webman + Redis（连接池 12）P99 延迟稳定在 0.8ms；而硬上 Memcached 的方案，P99 会跳到 120ms+，且伴随大量连接拒绝。真正的瓶颈不在缓存本身，而在连接管理是否适配常驻进程模型——这点容易被忽略，但决定了整个架构是否可靠。
