Webman 不支持 Memcached，因原生扩展无连接池、多进程状态混乱、无熔断机制；推荐用 webman/redis 替代，其支持连接池、分布式锁、原子计数，高并发下更稳定。
Webman 里不能直接用 Memcached 扩展
Webman 官方生态不支持 Memcached，webman/redis 是唯一被深度集成、带连接池管理的缓存客户端。你如果硬装 memcached PHP 扩展并手动 new Memcached()，会立刻掉进三个坑：连接不复用、多进程间状态混乱、无超时熔断机制。Webman 的常驻进程模型要求所有 I/O 客户端必须支持连接池，而原生 Memcached 扩展是阻塞式、无池化设计的——每次请求 new 一个实例，Worker 进程数 × 并发量 = 瞬间打爆 Memcached 服务端连接数。
替代方案只有两个：
• 改用 webman/redis（推荐，已验证高并发下稳定）
• 自研封装 Memcached 连接池（需基于 Swoole\Coroutine\Channel + 连接预热 + 心跳检测，开发成本高且无社区维护）
Redis 替代 Memcached 的关键适配点
很多人抗拒换 Redis，觉得“Memcached 更轻更快”，但 Webman 场景下这个认知是错的。Redis 在以下三点反而更合适：
• PERSIST 命令可精准控制 key 过期，Memcached 的 expire 是相对时间且无法重置
• 支持 SETNX + GETSET 组合实现分布式锁，防缓存穿透比 Memcached 的 add/get 更可靠
• INCR/DECR 原子计数器能直接支撑限流、库存扣减等场景，Memcached 需额外加锁+读写两步
实际压测数据：在 2000 QPS 下，Webman + Redis（连接池 10~20）平均延迟 0.8ms；同等配置下 Memcached（手动 new）因连接争抢导致 P99 延迟飙升至 120ms+
立即学习“PHP免费学习笔记（深入）”；
APCu + Redis 多级缓存怎么配才不翻车
本地缓存不是加一层就完事。APCu 和 Redis 的职责必须严格切分，否则会出现“本地有旧值、Redis 已更新”的脏读：
- APCu 只存只读、不变、小体积数据：路由映射表、配置白名单、枚举字典，过期时间设为
300（5 分钟），避免长期驻留 - Redis 存业务实体、带参数的查询结果：用户详情、商品列表、搜索聚合结果，Key 必须含版本号（如
user:detail:id_123:v3） - 绝对禁止 APCu 存用户 session 或订单状态——进程重启即丢，且无法跨 Worker 同步
示例代码逻辑：
$apcu_key = 'config:site_lang';
$apcu_data = apcu_fetch($apcu_key);
if ($apcu_data === false) {
$apcu_data = Db::table('configs')->where('key', 'site_lang')->value('value');
apcu_store($apcu_key, $apcu_data, 300);
}
$redis_key = 'user:profile:id_' . $uid . ':v2';
$redis_data = Redis::get($redis_key);
if ($redis_data === null) {
$redis_data = Db::table('users')->find($uid);
Redis::set($redis_key, json_encode($redis_data), 3600);
}
缓存失效策略必须和数据库更新强绑定
“先删缓存再更新 DB”或“先更新 DB 再删缓存”都不保险。Webman 场景下唯一稳妥的是延迟双删 + 版本号强制淘汰：
- DB 更新成功后，立即
Redis::del('user:profile:id_'.$uid.':v2') - 延时 500ms 后再次
Redis::del('user:profile:id_'.$uid.':v2')（覆盖主从延迟窗口） - 同时把 Key 版本号升级为
v3，让旧缓存自然失效，避免误删其他业务线同名 key
注意：不要依赖 Redis 的 EXPIRE 自动过期——高并发下 key 过期时间可能被批量延迟触发，造成雪崩。版本号才是最可控的失效开关。
真正容易被忽略的是：APCu 缓存不会随 Redis 删除而自动失效，所以涉及配置变更时，必须同步调用 apcu_delete()，否则本地缓存会持续返回旧值长达 5 分钟。
