直接用 set+expire 会因网络延迟或主从异步导致状态不一致，必须用 lua 脚本原子执行读取、判断、更新和续期；evalsha 需配合 script load 使用并处理 noscript 降级；需添加 ttl 校验、扫描清理和读取 fallback 等多重兜底。
为什么直接用 SET + EXPIRE 会出问题
因为网络延迟或 Redis 主从异步复制，SET 和 EXPIRE 是两个独立命令，中间若发生故障（如客户端断连、主节点宕机），就会出现“写入成功但过期没设上”或“设了过期但数据没更新”的状态不一致。更麻烦的是，多个服务实例并发刷新同一 session 时，还可能覆盖彼此的状态字段（比如 last_access_time 被旧值覆盖）。
根本原因在于：Redis 默认不提供跨 key 或带条件的多操作原子性。必须把“读当前值 → 判断是否需要更新 → 写新状态 + 重设过期”这整条逻辑压进一个 Lua 脚本里执行。
EVAL 脚本里怎么安全地刷新 session 并续期
核心是用 redis.call("HGETALL", KEYS[1]) 先取全量 session 数据，再判断是否允许刷新（比如检查 status 字段是否为 "active"），最后用 HSET + EXPIRE 一次性提交。注意：Lua 脚本内不能用 SETEX 或 HSETEX 这类不存在的命令，必须拆成 HSET 和 EXPIRE 两步，且 EXPIRE 必须在 HSET 之后立即调用。
示例脚本片段：
local session = redis.call("HGETALL", KEYS[1])
if #session == 0 then
return 0
end
local status = redis.call("HGET", KEYS[1], "status")
if status ~= "active" then
return -1
end
redis.call("HSET", KEYS[1], "last_access_time", ARGV[1])
redis.call("EXPIRE", KEYS[1], tonumber(ARGV[2]))
return 1
调用方式：EVAL "...script..." 1 session:abc123 1717023456 1800（最后一个参数是新的 TTL 秒数）
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
用 SCRIPT LOAD + EVALSHA 提升性能和可维护性
每次 EVAL 都要传输完整脚本，浪费带宽且无法复用。上线前先用 SCRIPT LOAD 缓存脚本并拿到 SHA1 值，后续全部走 EVALSHA。这样既避免重复解析，又能让脚本变更可控（改脚本必须重新 LOAD，否则旧 SHA 仍执行老逻辑）。
容易踩的坑：
- 脚本加载后，如果 Redis 重启，SHA 值会丢失，需在应用启动时自动重载
-
EVALSHA返回"NOSCRIPT"错误时，必须 fallback 到EVAL并重试一次，不能直接报错 - 不要在脚本里用
redis.replicate_commands()—— 它对EXPIRE这类命令无效，主从过期时间仍可能不同步
过期时间同步失败时如何降级兜底
哪怕用了 Lua，EXPIRE 仍可能失败（比如 key 已被删除、集群 slot 迁移中）。不能假设它一定生效。建议在应用层加双重保障：
- 每次刷新后，用
TTL主动查一次剩余时间，若返回-2（key 不存在）或-1（无过期），立刻记录告警并触发紧急重建 session 流程 - 后台起一个低频扫描任务（比如每分钟一次），用
SCAN找出last_access_time超过阈值但未过期的 key，人工干预或自动清理 - 所有 session 读取都应带 fallback：若
HGETALL返回空，不直接报 401，而是尝试从 DB 或 JWT 中恢复上下文（取决于你的认证架构）
真正难的不是写对脚本，而是让整个链路——从 Lua 执行、TTL 校验、到业务层兜底——形成闭环。漏掉任意一环，分布式会话就可能在高并发下静默失效。
