Redis Hash 字段级过期与整 key 过期的选择

如果一个 Redis Hash 里的所有字段应当同时失效，继续给整个 key 设置 EXPIRE 最简单；如果字段有不同生命周期，并且服务端至少是 Redis 7.4，则可以用 HEXPIRE 给指定字段单独设置 TTL。真正的选择标准不是“哪个命令更新”，而是数据的清理边界是否一致。

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

我第一次准备把会话属性、一次性验证码和用户偏好塞进同一个 Hash 时，直觉是“有了字段级过期，就都改成 HEXPIRE”。真正列完边界后却发现：生命周期一致的数据继续用整 key 过期更清楚，只有少数字段独立失效时，字段 TTL 才能减少拆 key 的成本。

Redis 7.4 带来的变化是什么

Redis 7.4 开始支持 Hash 字段级过期。HEXPIRE 和 HPEXPIRE 分别设置秒级、毫秒级 TTL，HTTL 与 HPTTL 查询剩余时间，HPERSIST 可以移除字段 TTL。到了 Redis 8.0，HSETEX 又把“写入字段”和“设置字段过期”组合到一个命令里。

这项变化解决的是 Hash 内部生命周期不一致的问题。以前常见的做法是把短命字段拆成单独 key，或者由业务代码维护额外时间戳并在读取时判断；现在可以让 Redis 直接管理某些字段的到期删除。

两种过期方式真正不同的地方

整 key TTL 绑定的是 Hash 这个键。到期后，字段和值一起消失。字段 TTL 绑定的是被点名的字段，其他没有到期的字段仍可继续读取。前者的模型简单，后者的粒度更细，但也要求客户端、监控与排障工具理解新的命令和返回值。

官方命令说明还给出了一个容易被忽略的差异：修改 Hash 内某个字段不会清除整 key 的 TTL；但使用 HSET 覆盖某个带字段 TTL 的字段时，该字段自己的过期会被清除。也就是说，更新后是否仍会过期，要看 TTL 挂在 key 上还是字段上。

用一个会话 Hash 看出选择差异

假设 session:42 同时存放用户偏好和一次性令牌。偏好可以保留 24 小时，令牌只应存在 5 分钟。Redis 7.4 及以上可以给两者分别设置字段 TTL：

# 写入同一个 Hash 中生命周期不同的字段
HSET session:42 profile '{"theme":"dark"}' otp '839201'

# profile 保留 24 小时，otp 只保留 5 分钟
HEXPIRE session:42 86400 FIELDS 1 profile
HEXPIRE session:42 300 FIELDS 1 otp

# 分别查询字段剩余秒数，返回值与字段顺序一一对应
HTTL session:42 FIELDS 2 profile otp

HEXPIRE 对每个字段返回一个状态：设置成功返回 1；条件不满足返回 0；字段或 key 不存在返回 -2。它还支持 NX、XX、GT、LT，用于只在没有 TTL、已有 TTL、新 TTL 更长或更短时更新。批量指定 N 个字段时，命令复杂度为 O(N)。

如果这个 Hash 中的字段本来就应该一起清理，整 key 过期更直观：

# 整个会话 Hash 统一保留 30 分钟
HSET session:43 profile '{"theme":"light"}' otp '472901'
EXPIRE session:43 1800

# TTL 查询的是整个 key 的剩余秒数
TTL session:43

EXPIRE 是 O(1)，老版本和客户端支持也更广。它不是“功能较少就一定落后”，而是明确表达“这一组字段属于同一个生命周期”。

旧代码最容易踩到的覆盖规则

字段级 TTL 上线后，最需要检查的不是读取，而是写入路径。下面这个覆盖会让 otp 重新变成持久字段：

# 先给 otp 设置 5 分钟字段 TTL
HSET session:42 otp '839201'
HEXPIRE session:42 300 FIELDS 1 otp

# HSET 覆盖字段内容时会清除这个字段自己的 TTL
HSET session:42 otp '118233'

# 返回 -1 表示字段存在但没有过期时间，需要重新设置 TTL
HTTL session:42 FIELDS 1 otp

相反，如果 TTL 设置在整个 session:42 上，HSET session:42 otp ... 这种修改 Hash 字段的操作不会清除 key 的过期。迁移时若只把 EXPIRE 改成 HEXPIRE，却没有调整覆盖字段的代码，就可能产生比预期更长寿的数据。

在 Redis 8.0 上，适合用 HSETEX 将写入和字段过期放在同一条命令里；使用 Redis 7.4 时，则应把 HSET 与 HEXPIRE 放入受控的写入封装，并处理第二条命令失败的情况。不要假设所有客户端库已经暴露同名 API，部署前应确认服务端与客户端两侧都支持。

我现在会怎样做选择

我的判断顺序会落在四个约束上：

• 生命周期是否一致：一致就优先 EXPIRE；只有字段真的独立失效，才引入 HEXPIRE。
• 版本是否满足：服务端低于 7.4 时，字段级命令不可用；混合版本集群更应先完成兼容检查。
• 写入是否要求原子：Redis 8.0 可考虑 HSETEX；7.4 需要封装两条命令或重新评估拆 key。
• 运维是否看得见：监控、清理统计、客户端 SDK 和排障手册都要能区分 TTL 与 HTTL。

有时两种 TTL 可以同时存在：字段 TTL 负责局部新鲜度，整 key TTL 作为整个对象的最长保留上限。此时 key 一旦到期，所有字段都会一起消失，所以整 key TTL 必须按“最晚允许存在多久”设置，不能比业务需要更短。

迁移时只做最小范围验证

先在测试 key 上确认版本和返回语义，再改业务数据。下面的命令只验证字段 TTL 能否设置、覆盖字段后是否被清除，以及整 key TTL 是否仍然存在：

# 确认服务端版本，字段级过期要求 Redis 7.4 或更高
INFO server

# 创建测试 Hash，并设置字段 TTL 与整 key 上限
HSET ttl:probe stable 'A' volatile 'B'
HEXPIRE ttl:probe 60 FIELDS 1 volatile
EXPIRE ttl:probe 600

# 同时检查字段 TTL 和整 key TTL
HTTL ttl:probe FIELDS 2 stable volatile
TTL ttl:probe

# 覆盖 volatile 后再次确认其字段 TTL 已被清除
HSET ttl:probe volatile 'C'
HTTL ttl:probe FIELDS 1 volatile

# 清理测试数据，避免把探针 key 留在实例中
DEL ttl:probe

上线前再核对三点：客户端是否能发送这些命令，写入封装是否在覆盖字段后重设 TTL，监控是否同时采集 key 和字段级过期结果。满足这些条件后，字段 TTL 才是可维护的能力，而不只是一个新命令。

常见问题

HEXPIRE 会让整个 Hash 消失吗？

它只针对列出的字段设置 TTL，不会让其他未过期字段一起删除。若要让整个 Hash 同时失效，应使用 EXPIRE。

已经设置 HEXPIRE，再执行 HSET 会怎样？

如果 HSET 覆盖的是同一个字段，该字段原有 TTL 会被清除；更新其他字段不会影响这个字段的 TTL。写入路径要显式决定是否重设。

字段 TTL 与整 key TTL 能一起用吗？

可以，但整 key 到期会删除整个 Hash，因此它相当于所有字段共同的最长生存上限。两层策略应有清楚的业务含义。

为什么不总是把字段拆成多个 key？

拆 key 的兼容性更好，也便于按 key 观察 TTL；字段级过期则减少了命名和聚合读取成本。应按访问模式、版本要求和运维能力选择，而不是只看 key 数量。