Redis 哈希字段过期能力怎样改变缓存键设计

Redis 7.4 开始支持给 Hash 中的单个字段设置过期时间。缓存键设计因此可以从“一个 key 绑定一个 TTL”变成“一个对象共用 Hash、字段各自管理生命周期”：例如用户资料可以长期保留，登录会话或临时推荐结果则单独过期。官方入口：https://redis.io/。但这不是把所有 key 都改成 Hash 的理由，是否拆分仍要看字段的生命周期、访问方式和 Redis 版本。

变化一句话：Hash 不再只能共享一个生命周期

过去常见的缓存模型是一个业务对象对应一个 key，再用 EXPIRE 给整个 key 设置 TTL。只要 TTL 到期，key 内全部字段都会消失。Redis 7.4 增加了哈希字段过期能力后，可以用 HEXPIRE、HPEXPIRE、HEXPIREAT 或 HPEXPIREAT 针对字段设置相对或绝对过期时间，并用 HTTL、HPTTL 读取剩余 TTL。

两种模型的差别不只是命令名称。整 key TTL 适合“对象整体失效”，字段 TTL 适合“对象还在，但其中一部分数据先失效”。当缓存对象里同时存在稳定资料、短期状态和一次性令牌时，这个边界会直接影响键的数量和更新逻辑。

为什么这会改变缓存键设计

设计缓存键时，先问每个字段是否拥有相同的失效条件。若用户资料、会员等级和头像地址都由同一次刷新产生，整 key 过期更直观；若资料长期有效、会话令牌只保留几分钟，再把它们拆成多个顶层 key，应用每次读取都要拼接更多键名，也容易让对象的读写路径变散。

字段级 TTL 提供了第三种选择：把同一对象的相关字段放在一个 Hash 中，仍使用 HGET、HSET 等命令读写，但只对短生命周期字段调用 HEXPIRE。字段过期后，Hash 仍可存在，未过期字段也不会被连带删除。这样可以减少一些对象级键的拆分，不过代价是调用方必须接受“字段不存在”是正常状态，不能把它一律当成整个对象丢失。

从数据关系上看，键名表达“对象是谁”，字段名表达“对象的哪一部分”，TTL 表达“这一部分还能使用多久”。如果一个字段的失效会让整个对象不可用，就不要为了减少 key 数量强行采用字段级 TTL。

对旧代码的影响：命令、版本和空字段都要重新判断

第一，字段过期命令的可用版本边界是 Redis 7.4。部署环境、云服务兼容层和客户端封装都需要确认是否能透传这些命令；不能只看客户端方法名是否存在。第二，字段过期返回的是按字段排列的结果数组，某字段不存在、条件不满足和成功设置对应不同结果，批量设置时要按位置解释。

第三，字段过期后，HGET 可能得到空结果，而 Hash 的其他字段依然可读。原先用“key 不存在”判断缓存未命中的代码，需要区分“对象不存在”和“对象存在但目标字段已过期”。第四，若最后一个字段被删除，Hash 是否还存在以及后续清理逻辑要按实际业务语义设计，不能只依赖原先的整 key TTL。

旧 Redis 不支持字段级 TTL 时，最稳妥的回退不是模拟一半命令，而是保留独立 key：让每个独立生命周期的数据继续使用 SET ... EX 或 SET ... PX。如果必须兼容多种版本，可以在应用启动时记录能力开关，把 Hash 字段方案与独立 key 方案封装在同一个缓存接口后面。

迁移建议：按生命周期选择三种布局

可以把缓存对象分成三类。第一类是“每项独立”：字段之间的过期时间不同，适合 Hash 加字段级 TTL。第二类是“整体共享”：所有字段一起失效，继续使用一个 key 和 EXPIRE 更易读。第三类是“冷热混合”：稳定字段留在 Hash，特别短命或访问量完全不同的数据拆到独立 key，避免一个 Hash 变成什么都往里塞的杂物箱。

一个最小的字段级 TTL 例子如下。命令中的注释说明每一步的意图，实际项目还应把返回数组与业务字段一一对应：

# 把同一用户对象的稳定资料和临时会话放进一个 Hash
redis-cli HSET user:42 name Alice plan pro session-token abc

# 只让临时会话字段保留 60 秒，不改变 name 和 plan
redis-cli HEXPIRE user:42 60 FIELDS 1 session-token

# 分别读取稳定字段和临时字段的剩余 TTL
redis-cli HTTL user:42 FIELDS 2 name session-token

这里的预期语义是：name 没有字段 TTL，返回值为 -1；session-token 返回一个接近 60 的剩余秒数，并会随时间减少。若目标字段不存在，官方命令返回信息中会以负值区分不存在字段，而不是把它当成成功设置。

最小验证：确认字段失效没有误伤整个对象

迁移时不需要先改完整业务，只要准备一个包含稳定字段和临时字段的测试对象，观察四件事：设置 TTL 的返回数组、字段剩余 TTL、字段过期后的 HGET 结果，以及其他字段是否仍能读取。

# 给临时字段设置短 TTL，用于观察字段级删除
redis-cli HSET cache:demo profile "stable" token "temporary"
redis-cli HEXPIRE cache:demo 5 FIELDS 1 token

# 检查 profile 与 token 的 TTL，-1 表示 profile 没有字段 TTL
redis-cli HTTL cache:demo FIELDS 2 profile token

# 等待 TTL 到期后，确认只有 token 消失，profile 仍然存在
redis-cli HGET cache:demo token
redis-cli HGET cache:demo profile

速查时可以这样理解：HGET token 为空并不等于 cache:demo 整个 key 失效；HGET profile 仍能读到值，才说明字段级生命周期与对象级生命周期确实分开了。需要毫秒精度时，把 HEXPIRE 换成 HPEXPIRE，把 HTTL 换成 HPTTL。

相关问题

Hash 字段过期后，其他字段会一起删除吗？ 不会。字段级过期针对指定字段，其他字段仍按自己的状态保留；如果业务要求整体失效，应继续使用整 key TTL。

HEXPIRE 和 HPEXPIRE 怎么选？ 只需要秒级缓存策略时用 HEXPIRE；需要毫秒级 TTL 时用 HPEXPIRE，读取则分别配合 HTTL 或 HPTTL。

客户端不支持字段过期命令怎么办？ 先确认 Redis 服务端和客户端版本，再选择升级客户端、透传原生命令或回退到独立 key；不要仅凭一个未执行的封装方法名判断兼容。

是不是所有缓存都应该改成 Hash？ 不是。字段生命周期一致、对象整体失效或访问路径很简单时，原有整 key 设计通常更容易维护。字段级 TTL 适合解决生命周期确实不同的问题。

Redis 哈希字段过期的价值在于把“对象组织方式”和“字段失效时间”拆开。迁移前先画出每个字段的生命周期，再决定使用整 key、字段级 TTL 还是混合布局；这样新增能力才会减少键设计的耦合，而不是把过期逻辑藏得更深。