题干与适用场景
系统希望在同一个 Redis hash 中保存多个字段，但每个字段的有效期不同。请说明如何使用 HEXPIRE、如何处理续期条件、读取过期状态、内存回收、旧版本兼容和恢复。不要只写命令语法。
面试官考察点
- 是否理解 Redis 7.4 的过期粒度从 key 扩展到 hash field。
- 是否能正确使用 NX、XX、GT、LT 条件并解释返回值。
- 是否考虑过期删除时机、读写竞态、通知、持久化和内存预算。
- 是否能设计版本探测、降级、监控和数据恢复方案。
回答前需要澄清的问题
- 字段是否允许独立过期，还是必须整体原子地更新多个字段？
- TTL 是相对业务事件计算，还是固定到期时间？重复写入能否延长有效期？
- 过期后业务要返回缺失、默认值，还是触发重新计算？是否需要过期事件？
- Redis 版本、集群模式、持久化方式和旧客户端是否支持字段级 TTL？
30 秒回答框架
我会先确认字段独立生命周期是否值得保留在同一个 hash 中，再为每个字段定义 TTL、续期条件和缺失语义。HEXPIRE 可按字段设置相对秒数，并用 NX、XX、GT、LT 防止无意缩短或延长期限；命令返回值要纳入监控。上线前验证读取、重写、过期通知、故障恢复和旧版本降级，不能把字段过期误解为定时精确删除。
分步骤深入解答
1. 建模字段生命周期
为每个字段定义数据来源、最大新鲜度、续期事件和过期后的替代值。需要整体原子更新的字段仍可放在同一 hash，但 TTL 设定和业务写入必须在一个可重试的协议中协调。
2. 选择续期条件
首次设置可用 NX，只在已有过期时间时更新可用 XX；GT 只接受更长 TTL，LT 只接受更短 TTL。对每个字段记录设置命令的返回码，区分字段不存在、条件不满足、成功更新和立即删除。
3. 处理过期与通知
字段过期不等于应用线程在精确时刻收到事件。读取时必须接受字段缺失，写入时避免把旧快照重新写回；需要驱动重算时，结合 keyspace notification 或业务队列，并设计重复事件与丢失事件的补偿。
4. 兼容、监控与恢复
启动时探测 Redis 版本和客户端能力；不支持字段 TTL 时可降级为独立 key，但要明确内存和原子性变化。监控剩余 TTL、条件失败、过期事件、命中率和内存；从 RDB/AOF 恢复后重新核对关键字段的有效期与重算任务。
高质量示范回答
我会先把每个字段的生命周期、续期来源和过期后行为写成协议，再判断是否需要 hash 的共享读取与原子更新。使用 HEXPIRE 设置字段 TTL，首次写入用 NX，只在已有 TTL 时更新用 XX，防止缩短或延长则分别考虑 GT 与 LT，并记录返回值。读取路径把过期字段视为缺失，不能依赖精确时刻的删除通知；若要触发重算，用通知加业务队列和幂等补偿。上线前探测版本、验证故障恢复、监控 TTL/命中率/内存，并准备独立 key 降级方案。
常见错误
- 把
HEXPIRE当成整个 hash 的EXPIRE别名。 - 不理解 NX、XX、GT、LT，重复写入时无意修改 TTL。
- 假设字段会在指定秒数精确时刻被删除并收到唯一事件。
- 忽略旧版本、客户端和集群兼容性。
- 没有定义字段缺失、重算、重复通知和恢复语义。
- 只看命中率，不监控 TTL、条件失败和内存回收。
追问及应对
什么时候仍应拆成多个 key？
当字段必须跨服务独立原子更新、客户端不支持字段 TTL，或过期与访问模式更适合整 key 时，拆 key 更简单。要把额外 key 数量、内存开销和一致性成本量化。
GT 为什么适合推荐特征？
推荐特征通常只能在新鲜度更高时延长有效期；GT 可拒绝更短 TTL，避免晚到的旧事件把新数据提前过期。
如何处理过期通知丢失？
通知只做加速，不做唯一事实来源。读取未命中、定期扫描剩余 TTL、业务水位和幂等重算队列应共同覆盖丢失或重复事件。