Redis如何使用Lua封装HGET配合TTL刷新

不能直接用HGET+EXPIRE组合刷新TTL，因存在竞态条件：HGET后key可能立即过期导致EXPIRE失败，且并发时多个客户端执行EXPIRE仅首个成功；lua脚本能原子执行“查+刷”，用HEXISTS和EXPIREAT确保安全续命。

为什么不能直接用 HGET + EXPIRE 组合刷新 TTL

因为并发读时，多个客户端可能同时发现 key 过期、同时执行 EXPIRE，但只有第一个成功；更糟的是，HGET 和 EXPIRE 之间存在竞态窗口——key 可能在 HGET 后立刻过期，导致后续 EXPIRE 失败，TTL 没刷上。

Lua 脚本在 redis 中原子执行，能确保“查 + 刷”一步到位。核心思路是：先 HGET，若字段存在且 key 未过期（或刚过期但需续命），再用 EXPIREAT 设定新过期时间。

• 必须用 EXPIREAT 而非 EXPIRE，避免因 Redis 时间漂移或脚本执行延迟导致误判
• 不要依赖 TTL 返回值判断是否过期——返回 -2 表示 key 不存在，-1 表示无过期时间，0 才是已过期；但 key 存在且无 TTL 时，HGET 仍可能成功，需结合两者判断
• 脚本里别用 redis.call("TTL", KEYS[1]) 做前置判断，它和后续操作不构成原子条件，意义不大

EVAL 脚本怎么写才安全可靠

以下是最小可用脚本，接收 KEYS[1]（hash key）、ARGV[1]（field）、ARGV[2]（新 TTL 秒数）：

if redis.call("HEXISTS", KEYS[1], ARGV[1]) == 1 then   local ttl = redis.call("TTL", KEYS[1])   if ttl == -1 or ttl > 0 then     redis.call("EXPIREAT", KEYS[1], tonumber(ARGV[2]) + tonumber(redis.call("TIME")[1]))   end   return redis.call("HGET", KEYS[1], ARGV[1]) else   return nil end

注意点：

• HEXISTS 比 HGET 更轻量，先确认字段存在再取值，避免无谓的字符串分配
• 用 redis.call("TIME") 获取服务端当前秒级时间，保证 EXPIREAT 时间戳绝对可靠，不受客户端时钟影响
• 不处理 ttl == 0（刚过期）的情况——此时 key 逻辑上已删除，HEXISTS 会返回 0，脚本直接返回 nil，符合预期
• 如果业务要求“即使字段不存在也要刷新 TTL”，那就去掉 HEXISTS 判断，但需明确这是覆盖语义，不是读取语义

客户端调用时参数和错误要盯紧哪几个

以 Python 的 redis-py 为例，调用方式是：

r.eval(lua_script, 1, "myhash", "field_name", str(int(time.time()) + 3600))

关键约束：

• KEYS 数量必须传对（这里是 1），否则 Redis 报错 ERR Error running script (call to f_...): @user_script:1: WRONGTYPE Operation against a key holding the wrong kind of value
• ARGV[2] 必须是绝对时间戳（秒），不是相对秒数——脚本里没做转换，传错会导致 key 立刻过期或几百年后才过期
• 如果 hash key 本身不是 HASH 类型，HEXISTS 抛 WRONGTYPE，整个脚本中断，返回 Python 异常 redis.exceptions.ResponseError
• 别把 field 名拼错进 KEYS ——Lua 里 KEYS 只能是 key 名，field 必须走 ARGV

性能和边界情况比想象中敏感

这个脚本看似简单，但在高并发下有几个隐形瓶颈：

• 每次调用都触发两次 redis.call（HEXISTS + HGET），实际是三次（还有 TTL 或 TIME），比单次 HGET 多出 2–3 倍开销；QPS 上万时得压测看毛刺
• 如果 hash key 极大（几十万 field），HEXISTS 仍是 O(1)，但底层哈希表 rehash 可能引发短暂停顿，Redis 日志里会出现 Hash table resize 提示
• 脚本里没做空值保护：当 ARGV[1] 是空字符串或 nil，HEXISTS 返回 0，脚本返回 nil——这没问题；但如果业务允许空字段名，就得提前校验
• 集群模式下，key 必须落在同一 slot，所以 KEYS[1] 要确保是标准 hash key（不含 {...} 标签也行，但多个 key 就不行）

真正麻烦的不是写法，而是想清楚：你到底要“读取时顺带续命”，还是“只要访问就无条件续命”。前者得检查字段存在性，后者连 HEXISTS 都可以砍掉——但多数人没想清这点，就直接抄了带判断的版本。