Redis 哈希字段过期通知的订阅设计

Redis 哈希字段过期通知的设计关键，不是只订阅一个频道，而是先确认你要的是“哪个哈希键发生了字段过期”，还是“具体哪个字段过期”。Redis 7.4 引入 HEXPIRE 后，字段可以独立设置 TTL；标准 keyevent 通知会产生 hexpired 事件，但消息通常只带键名。Redis 8.8+ 的 subkey notifications 才能把字段名一起带给消费者。

官方地址：https://redis.io/docs/latest/

先确认字段过期能力与通知粒度

先把版本边界写进设计文档。HEXPIRE、HPEXPIRE、HEXPIREAT 等字段级过期命令从 Redis 7.4 开始提供；它们只删除到期字段，不会因为一个字段过期就自动删除仍有内容的整个哈希。HTTL 可用于读取剩余 TTL。

通知粒度要单独判断：标准 keyspace/keyevent 机制能告诉消费者 profile:100 发生了 hexpired，但不能可靠地把过期字段名放进消息；Redis 8.8+ 的 subkey 通知才面向字段名传递。若运行环境低于 8.8，应让消费者收到键名后按业务规则读取或补偿扫描，而不是假设消息里存在字段。

配置 hexpired 事件并订阅哈希键事件

兼容方案可以先从 keyevent 开始。E 表示 keyevent 通道，h 表示哈希命令事件；两者组合后，订阅者监听 hexpired。生产环境不要盲目覆盖已有配置，应该先读取当前值，再把需要的标志合并进去。

# 读取现有通知配置，避免覆盖其他业务正在使用的事件类型
redis-cli CONFIG GET notify-keyspace-events

# 示例：开启哈希 keyevent；生产环境请把 Eh 合并到已有配置
redis-cli CONFIG SET notify-keyspace-events Eh

# 订阅数据库 0 的哈希字段过期事件，消息体通常是哈希键名
redis-cli --csv PSUBSCRIBE '__keyevent@0__:hexpired'

这里的订阅进程只负责接收事件和投递内部任务。不要在回调里执行很慢的业务逻辑，否则会拖住后续消息；更稳妥的做法是把键名转成幂等任务，再由工作线程处理。

用 HEXPIRE 建立可追踪的字段生命周期

设置字段 TTL 时，业务标识应该和哈希结构保持稳定。例如一个用户资料哈希里，plan 是短期权益字段，nickname 则不应因为同一哈希的其他字段过期而被误处理。

# 写入两个字段，并只给短期权益字段设置 30 秒 TTL
redis-cli HSET profile:100 plan trial nickname codex
redis-cli HEXPIRE profile:100 30 FIELDS 1 plan

# 读取字段剩余时间；-2 表示字段不存在或已经被删除
redis-cli HTTL profile:100 FIELDS 2 plan nickname

收到标准 hexpired 后，不要把“收到通知”直接等同于“业务补偿完成”。消费者可以根据键名前缀找到处理器，再读取当前哈希状态；如果状态已经被重建，处理器应按版本号或业务时间戳判断是否需要刷新。

Redis 8.8+ 改用 subkey notifications

如果服务端和客户端都能确认支持 Redis 8.8+，可以开启 subkeyevent 通道。它把哈希键名与字段名放进消息负载，消费者不必为了判断是哪一个字段而扫描整个哈希。

# 开启 subkeyevent 与哈希事件；S/T 是 subkeyspace/subkeyevent
redis-cli CONFIG SET notify-keyspace-events STh

# 只订阅字段过期事件，消息可包含键名和字段名
redis-cli --csv PSUBSCRIBE '__subkeyevent@0__:hexpired'

不同客户端对长度前缀负载的解析方式可能不同，接入时要按客户端文档处理，而不是简单用逗号切割字段名。字段名可能包含分隔符，长度前缀正是为了保持二进制安全。若系统不能升级，继续采用标准 keyevent 加补偿扫描会更稳。

补齐断线、集群与重复处理边界

Redis 官方明确说明 Pub/Sub 是 fire-and-forget：消费者断线期间的消息不会在重连后补发。因此，通知适合触发刷新和轻量副作用，不适合单独承担账务、库存或必须不丢的状态转移。

• 断线恢复：重连后记录恢复时间，按时间窗口扫描可能受影响的哈希，扫描任务必须可重复执行。
• 幂等消费：用“哈希键 + 字段 + 业务版本”作为去重依据，重复收到 hexpired 时只保留一次有效处理。
• 集群订阅：keyspace 事件是节点本地的；要覆盖整个集群，消费者需要订阅每个节点，而不是只连一个随机节点。
• 保底校准：高价值数据增加周期性 HTTL 或业务状态扫描，把通知当作低延迟提示，把扫描当作最终校准。

常见问题

为什么订阅到了 hexpired，却不知道哪个字段过期？

这是标准 keyevent 的粒度限制。升级到 Redis 8.8+ 并使用 subkey notifications，或者按键名做定向补偿扫描。

HEXPIRE 设置成功就一定会准时收到通知吗？

不一定。过期事件在 Redis 实际删除字段时产生，可能受惰性删除和后台清理时机影响；同时 Pub/Sub 断线会丢消息。

可以用一个全局订阅覆盖 Redis Cluster 吗？

不能把单节点订阅当作全量覆盖。官方文档说明事件通知是节点级的，需要逐节点订阅并在消费端做幂等合并。