Webman需用webman/redis连接池复用Redis连接，避免新建实例；Key须含业务域、参数签名和版本号；单请求内加临时缓存防穿透；更新时用延迟双删+分布式锁保障一致性。
Webman 本身不提供内置缓存服务，但它的常驻进程模型 + 异步 I/O 架构，让 Redis 缓存能真正“复用连接、落地生效”。直接在控制器里 new Redis() 或用原生 redis_connect() 是典型错误，会导致连接数爆炸、TIME_WAIT 堆积、Redis 拒绝新连接。
必须用 webman/redis 扩展管理连接池
Webman 每个 Worker 进程长期存活，不能每次请求都新建 Redis 实例。手动 new 或全局变量存储连接，在多进程下会引发共享冲突或序列化失败。
- 安装：
composer require webman/redis - 配置
config/redis.php，重点设好连接池参数：'pool' => ['min_connections' => 2, 'max_connections' => 20] - 业务中直接调用：
Redis::get('key')，底层自动从连接池取可用连接，无需手动 connect / close - 别在
onWorkerStart里 new Redis 赋值给 static / global 变量 —— 这不是复用，是制造隐患
Cache::set() 的 key 必须带业务域、参数签名和版本号
写死 Cache::set('user_list', $data) 看似简单，实际极易导致缓存污染、跨环境冲突、更新后不生效。
- 正确结构示例：
'user:list:type_'.$type.':page_'.md5(json_encode([$page,$size])).':v2' - 用
json_encode()而非serialize()生成参数哈希，避免 PHP 版本升级导致 hash 不一致 - 版本号（如
:v2）用于批量失效，比遍历删 key 更安全可控 - 敏感字段（如用户 ID）不要直接拼进 key，防止被枚举探测
单请求内加一级临时缓存，防穿透
Redis 缓存未命中 + 高并发请求同一 key（比如热门商品详情），大量请求仍会打到数据库，仅靠 TTL 不够。
- 利用 Webman 请求生命周期，在单次请求中用
context()->get('cache')或静态变量做第一级缓存 - 例如：同一次请求中多次调用
getUser(123)，第二次起直接返回内存结果，不查 Redis 也不查 DB - Redis 层作为第二级，供跨请求复用；两级配合才能真正扛住穿透压力
- 对高频分页数据（如
/users?page=1&size=20），尤其建议加上这层
延迟双删 + 分布式锁，保障写操作一致性
更新数据库后立刻删 Redis key，仍可能因主从延迟或并发导致脏读。纯靠“先删再写”或“先写再删”都不稳妥。
- 推荐组合策略：更新 DB 前先加分布式锁（用
Redis::set('lock:user:123', 1, ['nx', 'ex' => 5])） - 成功加锁后，先删缓存 → 写 DB → 延迟 100–500ms → 再删一次缓存
- 延迟时间需略大于主从同步最大耗时，避免旧值回写
- 锁要设置合理过期时间，防止死锁；释放锁必须用 Lua 脚本保证原子性
缓存不是加了就高枕无忧，Key 设计、连接复用、多级缓存、写一致性，每个环节漏掉一个，都可能让性能优化变成负优化。尤其是连接池配置和请求级缓存，最容易被跳过，也最影响实际水位。
