Hash 字段级过期适合哪些会话与属性缓存场景

会话缓存里最容易被误用的是整键过期：用户资料、登录态、设备信息都放在一个 Hash 中，却只能给整个 key 设置一个 TTL。Redis 7.4 起，Hash 支持字段级过期，可以让短期字段独立失效，同时保留同一对象的其他属性。

官方地址：https://redis.io/docs/latest/develop/data-types/hashes/

先按字段生命周期建模，再决定是否过期

把一个用户缓存想成 user:10086：昵称和灰度开关可能希望保留较久，登录会话只保留 30 分钟，临时设备令牌只保留 10 分钟。此时整键 TTL 会出现两种浪费：TTL 太短导致稳定属性频繁回源，TTL 太长又留下已经失效的短期数据。

字段级过期更适合“同一个业务对象、多个字段、生命周期明显不同”的数据。例如活跃会话计数、短期登录态、设备能力快照和按属性单独刷新的缓存。它不适合强一致主数据，也不适合字段数量巨大且频繁全量扫描的场景，因为过期只是缓存生命周期管理，不会替代数据库的权威状态。

用 HEXPIRE 给会话字段设置独立 TTL

下面的示例把用户资料、登录会话和设备令牌放进同一个 Hash。命令中的中文注释只解释示例意图；代码块展示的是可复用命令，不代表本机运行截图。

# 先写入同一个用户对象的三个字段
HSET user:10086 nickname "小林" login_session "sess-demo" device_token "device-demo"

# 登录会话 30 分钟后失效，设备令牌 10 分钟后失效
HEXPIRE user:10086 1800 FIELDS 1 login_session
HEXPIRE user:10086 600 FIELDS 1 device_token

# 昵称不设置字段 TTL，由业务更新或整键策略管理
HGET user:10086 nickname

HEXPIRE 的秒数是相对 TTL，后面通过 FIELDS 指定字段数量和字段名。批量设置多个字段时，一次命令可以列出多个字段；如果字段不存在，结果会提示该字段没有被设置。Redis 官方文档将字段级过期列为 Redis 7.4 引入的能力，因此部署前应先确认服务端版本和客户端是否支持对应 API。

用 HTTL、HPTTL 和 HLEN 观察状态

设置 TTL 后不要用整键的 TTL 猜字段状态，而要读取字段自己的剩余时间。秒级策略用 HTTL，需要更细粒度时用 HPTTL：

# 查询登录会话和设备令牌的剩余秒数
HTTL user:10086 FIELDS 2 login_session device_token

# 查询设备令牌的剩余毫秒数
HPTTL user:10086 FIELDS 1 device_token

# 统计当前 Hash 中还存在多少个字段
HLEN user:10086

读取结果应按字段顺序对应。剩余时间为负值时，要结合命令语义区分字段不存在、没有设置过期和已经过期；不要把它们都当成“还有很久”。字段过期后会从 Hash 中消失，全部字段都消失时，整个 Hash 也不再有可读内容，业务仍应在 HGET 为空时回源或重新建立缓存。

字段级过期与拆分 key 的选择清单

工程上建议把过期策略写进缓存封装层：写入字段时同时设置 TTL，读取时记录空值回源次数，并对即将过期的关键字段留出刷新窗口。不要在不同业务入口分别约定秒数，否则同一字段可能被新的写入覆盖成不一致的生命周期。

常见问题

Hash 设置了一个整键 TTL，还能单独设置字段 TTL 吗？

可以，但两种生命周期同时存在时，字段最多只能存活到整键消失。若字段需要独立长期存在，应重新检查整键 TTL 是否符合对象模型。

字段更新后原来的 TTL 会自动续期吗？

不要默认它会续期。把“更新值”和“续期”视为两个业务动作，在缓存封装中显式执行并记录策略，才能避免滑动会话和固定会话混淆。

什么时候应该继续使用多个 Redis key？

当字段需要独立权限、独立批量操作、跨版本兼容，或对象字段规模和扫描方式已经复杂到难以维护时，多个 key 往往更直观。