高频缓存失效主因是失效逻辑未对齐业务节奏，需解决“不该删的被删”和“该删的没及时删”；优化键设计、批量操作感知、分层TTL、Redis性能配置及监控对齐。
高频缓存失效不是缓存设得少，而是失效逻辑没对齐业务节奏。核心要解决的是“不该删的被删了”和“该删的没及时删”这两类问题。
缓存键设计要避开动态陷阱
Hyperf 默认用 implode(':', $arguments) 生成键，数组参数一变，键就全乱。比如分页查询传 ['page' => 1, 'limit' => 20] 和 ['limit' => 20, 'page' => 1] 会生成两个不同键，但语义完全一样。
- 重写
hashArguments方法，统一用ksort排序键名再序列化 - 对分页、排序类参数，提取关键维度（如
user_list:status_1:sort_created_at），不带原始数组 - 敏感字段（如用户 token、时间戳）不参与键生成，改用独立缓存标记控制
批量操作必须开启缓存感知
直接调 User::where(...)->update(...) 不会触发模型缓存清理，旧数据还在 Redis 里躺着。
- 所有批量更新/删除前加
query(true)：User::query(true)->where('status', 0)->update(['status' => 1]) - 配合配置中的
'use_default_value' => true，空结果也缓存，避免穿透 - 删除整表或大范围数据时，优先走缓存标记 + 延迟重建，而不是暴力清空
失效策略要分层错开
同一业务模块的缓存如果 TTL 全设成 3600 秒，整点一到就集体雪崩。
- 基础数据（如城市列表）TTL 设为
86400 + rand(0, 3600) - 用户维度数据（如个人订单）TTL 加上用户 ID 哈希后取模偏移：
3600 + abs(crc32($uid) % 600) - 热点 key 单独启用「永不过期 + 后台刷新」：value 里存过期时间戳，协程定时任务检查并异步回填
Redis 本身要扛住突发压力
缓存失效瞬间涌来的 DB 请求，常卡在 Redis 连接或序列化环节。
- 连接池最小连接数不低于 20，最大不超过 200，按 QPS 动态压测调整
- 序列化统一用
PhpSerializerPacker，禁用JSON（性能差 3 倍以上） - 开启 AOF + everysec 模式，避免 Redis 重启后缓存全丢；RDB 作为兜底快照
- 对高频读 key，加一层
CoroutineMemoryDriver，同请求内免 Redis 往返
不复杂但容易忽略：高频失效往往不是代码写错了，而是缓存生命周期和业务变更节奏没对齐。多看监控里的命中率曲线和 delete 操作频次，比调参数更管用。
