webman需搭配redis连接池与科学缓存策略才能真正发挥性能优势：必须用webman/redis扩展复用连接，key设计需含业务域、参数签名和版本号，配合请求级缓存、分布式锁防穿透及延迟双删保障一致性。
Webman 本身不自带缓存服务，但它的常驻内存 + 异步 I/O 架构，让缓存能真正“落地生效”——不是每次请求都重建连接、重连 Redis、重新查库。如果你还在用 PHP-FPM 模式下硬套缓存逻辑，那大概率没发挥出 Webman 的真实能力。
Redis 连接必须用连接池，不能 new Redis() 每次创建
在 Webman 中，每个 Worker 进程常驻内存，如果在控制器里每次 new Redis() 或 redis_connect()，会导致连接数爆炸、TIME_WAIT 堆积、Redis 服务端拒绝新连接。
正确做法是复用连接，推荐使用 webman/redis 扩展（基于 predis/predis 或 phpredis 封装），它自动管理连接池：
- 安装：
composer require webman/redis - 配置
config/redis.php，设置'pool' => ['min_connections' => 2, 'max_connections' => 20] - 业务中直接
Redis::get('key')，底层自动从连接池取可用连接
注意：不要在 onWorkerStart 里手动 new Redis 并赋值给全局变量，容易引发多进程间连接共享冲突或序列化失败。
缓存 Key 设计要带业务上下文和版本号
常见错误是写死 Cache::set('user_list', $data)，后续改了用户查询逻辑，缓存却一直不更新，或者多个环境共用一套 Redis 导致 key 冲突。
Key 应该包含三要素：业务域 + 参数签名 + 缓存版本，例如：
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
// 正确示例：带用户类型、分页参数哈希、缓存版本
$key = 'user:list:type_' . $type . ':page_' . md5(json_encode([$page, $size])) . ':v2';
$data = Cache::get($key);
if ($data === null) {
$data = Db::table('users')->where('type', $type)->paginate($page, $size);
Cache::set($key, $data, 3600);
}
- 避免用
serialize($params)作 hash，PHP 版本升级可能导致序列化格式变化 - 版本号
v2改动后全量失效，比删 key 更可控 - 不要把敏感字段（如用户 ID）直接拼进 key，防止缓存探测攻击
预加载 + 请求级缓存防穿透，别只靠 Redis
当缓存未命中、又遇到高并发请求同一 key（比如热门商品详情），大量请求会穿透到数据库，造成雪崩。仅靠 Redis 的过期策略不够。
Webman 可以在单个请求生命周期内做两级缓存：
- 第一级：请求内临时缓存（如
context()->get('cache')或静态变量），避免同一次请求多次查同个数据 - 第二级：Redis 缓存，供跨请求复用
- 第三级（可选）：加锁机制，只放一个请求回源，其余等待 —— 但注意
Webman是多进程，得用 Redis 分布式锁，不能用flock
简单防穿透示例：
$key = 'product:detail:' . $id;
$data = Cache::get($key);
if ($data === null) {
// 先设一个短过期空值，防止穿透
Cache::set($key . ':lock', 1, 10);
$data = Db::table('products')->find($id);
if (!$data) {
Cache::set($key, null, 60); // 空结果也缓存 1 分钟
} else {
Cache::set($key, $data, 3600);
}
}
这个逻辑必须配合 Redis 的原子操作（如 SETNX）才可靠，否则多进程同时判断 null 仍会并发回源。
缓存失效时机比缓存写入更难搞
很多人花大力气把数据塞进 Redis，却忽略“什么时候删它”。在 Webman 场景下，尤其要注意：
- 数据库写操作（增删改）后，必须同步清理相关缓存，不能等 TTL 到期 —— 否则用户看到脏数据
- 不要在事务外删缓存；若 DB 更新失败，缓存已删，就彻底丢数据
- 复杂关联场景（如订单更新影响用户积分、优惠券状态），建议用「延迟双删」：删缓存 → 更新 DB → sleep(100ms) → 再删一次缓存，覆盖主从延迟窗口
- Webman 没有 Laravel 那样的模型事件钩子，所以删缓存逻辑要显式写在 service 层，别藏在 controller 里
最易被忽略的一点：缓存的过期时间不能全设成固定值。比如所有商品详情都设 1 小时，就会在整点前后出现大量集中回源。建议加随机偏移：3600 + rand(0, 600)。
