分级过期是将同一业务数据按访问频次、更新敏感度、失效容忍度拆分为多个key，各自设定不同TTL策略；单层随机TTL无法解决语义冲突，如高敏数据被拖入低敏窗口或低频数据反复回源。
分级过期不是“加一层缓存”，而是把同一个业务数据按访问频次、更新敏感度、失效容忍度拆成多个 key，各自走不同的过期节奏——雪崩压不垮一个有层次的缓存结构。
为什么单层随机 TTL 在社交平台仍不够用
社交场景下，用户 feed、关系链、消息未读数等数据天然存在强时效梯度：首页 feed 可接受 30 秒陈旧，但“新关注”提示必须 2 秒内生效；用户资料页可缓存 5 分钟，但头像 URL 更新需秒级同步。若全用 SETEX + 随机偏移，会把高敏数据拖进低敏窗口，或让低频数据反复回源。
- 随机偏移只解决“时间对齐”，不解决“语义冲突”——比如给
user:123:profile和user:123:unread_count都加 ±90 秒扰动，后者失效延迟直接导致未读红点滞留 - feed 流中大量 key（如
feed:123:page:0）共享同一基础 TTL，即使加了随机值，仍可能在 1 分钟内集中失效，因为它们被写入的时间戳高度一致（批量生成） - 客户端 SDK 若未区分 key 类型统一走默认过期策略，会覆盖业务侧的分级意图
分级过期的三层 key 设计（以用户主页为例）
把一个用户主页拆成三个逻辑层级，每个层级对应不同 Redis 操作和 TTL 策略：
-
热态层（
user:123:profile:hot）：仅存 nickname、avatar_url、is_following 等高频读、低更新频次字段；TTL 固定为1800秒（30 分钟），不加随机——靠预热+主动刷新保鲜，避免随机导致关键字段长期 stale -
动态层（
user:123:profile:dynamic）：存 last_active_time、post_count、follower_count 等需分钟级更新的数据；TTL =base_ttl(600) + random.randint(1, 60)，确保每 10–11 分钟自然轮转一次 -
兜底层（
user:123:profile:fallback）：存 bio、location 等低频访问字段；TTL 设为86400（24 小时），但加noeviction内存策略 + 客户端强制 fallback 逻辑——即使过期也不穿透，返回本地兜底值
读取时按顺序查：user:123:profile:hot → 缺失则查 user:123:profile:dynamic → 再缺则用 user:123:profile:fallback 填充部分字段。数据库只在 :hot 层缺失且请求带 force_refresh=true 参数时才触发。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
写入阶段必须卡死的三个控制点
分级过期失效的主因永远是写入端失控，不是读取逻辑没写好：
- 禁止任何业务代码直接调用
redis.setex()或redis.set(..., ex=...)—— 全部收敛到统一的cacheWriter.writeProfile(userId, profileData, level="hot")封装方法，level 决定 TTL 和 key 命名规则 - 所有批量写入（如 feed 分页预生成）必须用 Lua 脚本原子执行，且每个 key 的 TTL 必须独立计算：
redis.call("SETEX", key, base_ttl + math.random(1, 30), value)，不能传入统一 ttl 参数 - 上线前静态扫描：用正则匹配所有
.set.*?ex=或.expire.*?出现位置，CI 流水线失败阻断——这是比监控更前置的防线
容易被忽略的客户端适配细节
分级过期真正起效的前提，是客户端能识别并尊重层级语义：
- Android/iOS SDK 必须支持多级缓存 miss 后的 fallback 行为，不能在
:hot层 miss 后直接报错或降级为空，要自动降级到:dynamic层 - Web 前端若用 localStorage 做本地缓存，其 TTL 必须与 Redis 的
:hot层对齐（如都设 30 分钟），否则会出现“Redis 已更新但前端还在展示旧头像”的现象 - Lettuce 客户端需配置
ClusterClientOptions.builder().topologyRefreshOptions(TopologyRefreshOptions.builder().enableAllAdaptiveRefreshTriggers().build())，否则扩容后节点迁移导致的 key 重分布会让分级失效节奏彻底错乱
分级过期的复杂性不在实现，而在对每个 key 的业务语义理解是否准确——一个 user:123:settings 看似静态，但如果包含“是否开启隐私模式”，它的失效敏感度就该对标 :hot 层。这种判断没法自动化，只能靠领域知识卡点。
