Redis 哈希字段过期怎么设计：单字段 TTL 的替代方案与清理任务

Redis 的 HASH 很适合把一组小字段放在一个 key 里，但“每个字段各自过期”正好踩到它的边界：EXPIRE 只能让整个 key 到期，不能直接让 profile:42 里的某一个 field 单独失效。实际项目里不要把这个需求硬塞进一个命令，而应先决定过期时间属于数据本身、访问结构，还是一条独立记录。

先确认：EXPIRE 过期的是 key，不是 field

下面这组命令只能让整个 user:42 消失：

HSET user:42 nickname "小林" login_token "token-value"
EXPIRE user:42 3600

昵称可能希望长期保留，登录令牌却只想存 30 分钟。Redis 不会因为 HASH 中某个 field 先到时间，就自动删除这个 field。把 EXPIRE user:42 1800 再执行一次，也只是修改整个 key 的倒计时。

因此，设计前先写出三个问题：字段是否必须原子地一起读取？不同字段的数量是否稳定？过期后允许多长时间才被清掉？这三个答案比“选哪个命令”更能决定数据结构。

三种建模方式各自解决什么问题

拆成独立 key：最接近 Redis 原生 TTL

如果临时状态和长期资料没有强绑定，拆 key 是最直观的方案：

HSET user:42:nickname value "小林"
SETEX user:42:login-token 1800 "token-value"
EXPIRE user:42:nickname 2592000

每个 key 都能使用原生 TTL，读取时也不会把已过期的令牌误当成用户资料。代价是 key 数量增加，批量读取需要 MGET、HMGET 或由应用层拼装；如果业务要求“资料和临时状态一起更新”，还要额外考虑事务边界。

在 HASH 中保存时间戳：读取路径最简单

字段数量少、读取必然经过应用层时，可以把值和过期时间放在同一个 HASH：

HSET user:42 login_token "token-value" login_token_expire_at 1787670000

读取令牌时同时取两个 field，先比较当前 Unix 时间；过期就返回未命中，并在需要时用 HDEL user:42 login_token login_token_expire_at 做惰性清理。这种方式没有额外索引，写入简单，但“没被访问的过期字段”会继续占内存，必须接受惰性清理或补一个扫描任务。

ZSET 到期索引：把清理任务变成可观测队列

当 HASH 需要保留统一的业务结构，又不能让过期字段长期堆积，可以增加一个 ZSET：

HSET user:42 login_token "token-value"
ZADD user:field-expire 1787670000 "user:42|login_token"

ZSET 的 score 是过期时间戳，member 指向具体的 HASH key 和 field。定时任务用 ZRANGEBYSCORE user:field-expire -inf now LIMIT 0 100 取一小批到期项，再确认字段确实到期后执行 HDEL，最后移除索引 member。它多了一份索引数据，但清理延迟、每轮数量和失败重试都可以记录。

用 ZSET 清理时，顺序比命令数量更重要

一个可靠的清理循环至少要处理重复任务、业务续期和中途失败。不要直接把查到的 member 全部删除，因为任务读出后，应用可能刚刚把同一个字段续期了。

now := time.Now().Unix()
items, err := rdb.ZRangeByScore(ctx, "user:field-expire", &redis.ZRangeBy{
    Min: "-inf", Max: strconv.FormatInt(now, 10), Offset: 0, Count: 100,
}).Result()
if err != nil {
    return err
}

for _, item := range items {
    key, field := splitMember(item)
    expireAt, err := rdb.HGet(ctx, key, field+":expire_at").Int64()
    if err != nil || expireAt > now {
        continue
    }
    _, _ = rdb.HDel(ctx, key, field, field+":expire_at").Result()
    _, _ = rdb.ZRem(ctx, "user:field-expire", item).Result()
}

示例里的“先复核再删除”是关键。生产代码还应把删除和索引移除放进 Lua 或事务策略中，至少让失败重试不会把索引提前删掉。若索引 member 只保存 key|field，字段名中包含分隔符时要改用可逆编码或 JSON 结构，不能靠字符串截断碰运气。

读取、续期和清理要使用同一套语义

最容易出现的 bug 不是清理慢，而是三个路径对“过期”的判断不一致：

• 读取：发现 expire_at 就视为未命中，并尝试惰性删除。
• 续期：先写新值，再更新 HASH 中的时间戳和 ZSET score；续期失败不能只留下半套数据。
• 清理：按 score 取候选，重新读取当前时间戳，确认没有续期后再删除。

如果使用拆 key 方案，则由 Redis 原生 TTL 负责最终删除，应用只需要处理不存在 key。若使用 HASH + ZSET，建议把字段名、过期时间和索引 member 的生成封装成一个函数，避免不同服务拼出两种格式。

如何验收：看结果，也看清理边界

测试不要只验证“睡一秒后查不到”。至少覆盖这四种情况：一个字段到期而同 HASH 的另一个字段仍可读；清理任务重复执行不会误删新值；字段在被清理前续期不会被旧任务删除；ZSET 有孤儿 member 时任务可以继续处理下一条。

线上可以记录三项指标：到期索引最早 score 与当前时间的差值、每轮取出的数量与删除成功数、HASH 中时间戳字段与 ZSET member 的不一致数。清理延迟突然变大时，先看任务是否被大批量读取拖慢，再看 Redis 慢日志，不要一上来把单轮数量调到几万。

常见问题

能不能给 HASH 的 field 直接执行 EXPIRE？

不能。原生 TTL 绑定的是 key；想要独立生命周期，需要拆 key，或在应用层保存时间戳并负责清理。

字段很少时，是否一定要上 ZSET？

不一定。访问频繁且数量有限时，时间戳字段加惰性删除更省结构；只有当过期字段可能长期不被访问、又需要控制内存时，ZSET 清理索引才更有价值。

清理任务多久跑一次合适？

按允许的过期延迟决定。先用小批量高频运行，观察最早到期项的延迟和 Redis CPU，再调整批量大小；不要用固定的大批量扫描掩盖数据模型问题。

最后的选择

能拆 key 就让 Redis 原生 TTL 处理；不能拆时，先用时间戳把“是否有效”定义清楚；当内存回收和清理延迟成为明确需求，再增加 ZSET 到期索引。三种方式没有绝对优劣，真正要避免的是只保存一个 HASH，却期待 Redis 自动理解每个 field 的生命周期。