Redis Lua脚本执行超时后如何进行优雅的断点续传？

Redis超时是连接被硬杀而非报错，客户端需捕获网络层异常；续传须拆分任务、原子更新偏移量并确保集群slot一致。

超时不是报错，而是连接被硬杀

Redis 超时后不会返回 ERR 或任何响应，而是直接关闭 socket 连接。客户端看到的是 ConnectionResetError（Python）、ECONNRESET（Node.js）或类似“broken pipe”的底层异常。这不是脚本没执行完，是 Redis 主动掐断了连接——所以你不能靠捕获 redis.call() 的错误来处理超时。

常见误判：在 Lua 里用 pcall(redis.call(...)) 包裹操作，以为能兜住超时；实际上超时发生在 Redis 线程内，Lua 解释器已被终止，pcall 根本没机会执行。

1. 服务端日志会写 Script attempted to execute a command that would exceed the configured timeout（需 loglevel ≥ notice）
2. 客户端必须监听网络层异常，而非命令级错误
3. 重试前需确认脚本幂等性——比如用 SET key val NX EX 60 替代无条件 SET

用 redis.call() “续命”不等于安全续传

每次调用 redis.call() 或 redis.pcall() 都会重置 lua-time-limit 计时器，但这只是让脚本“活下来”，不是真正的断点续传。它掩盖了设计缺陷：把本该拆分的长任务塞进单个脚本里。

例如遍历 10 万个 key 做处理，插 100 次 redis.call("PING") 确实能避免超时，但整个脚本仍占用主线程数十秒，阻塞其他请求。

1. 真正可续传的方案是：把大任务拆成多个小脚本，每个只处理固定数量（如 100 个）key，用唯一 token 标记进度
2. 用 INCR 或 HINCRBY 记录已处理 offset，失败后从下一个 offset 继续
3. 避免在脚本里做纯计算循环，必须循环时加 redis.call("PING") 仅作保底，不作为主逻辑

断点续传状态必须存 Redis，且结构要支持原子更新

续传依赖外部状态存储，这个状态本身不能成为瓶颈或单点故障。用 Redis 存，但别用 GET/SET 两步更新——竞态下会丢进度。

推荐组合：HSET 存任务元信息 + INCR 更新偏移量 + EXPIRE 设过期时间。例如：

HMSET task:abc status "running" total 100000 started_at 1720851600INCR task:abc:offset

关键点：

1. 用 HSETNX 初始化任务，避免重复提交
2. 用 WATCH+MULTI 包裹状态变更（如果业务强一致性要求高）
3. 所有 key 命名带唯一 task ID，防止不同任务互相污染
4. 客户端每次执行前先 GET task:abc:offset，再决定从哪开始，而不是靠脚本内自增

集群环境下续传要严格限定 slot

Redis Cluster 不允许跨 slot 执行 Lua 脚本。如果你的任务涉及多个 key，又想续传，必须确保所有相关 key 都落在同一个 hash slot 上——否则脚本根本发不出去，更别说超时续传了。

验证方式：CLUSTER KEYSLOT key_name 查每个 key 的 slot，用 {} 标记强制哈希（如 user:{123}:profile 和 user:{123}:settings 会落到同 slot）。

1. 不要在续传脚本里动态拼接 key 名而不校验 slot，否则首次成功、续传失败
2. 用 EVALSHA 而非 EVAL，避免传输大脚本增加网络延迟
3. 脚本中所有 KEYS 必须显式传入，不能靠字符串拼接生成，否则 Cluster 模式下解析失败

真正难的不是让脚本跑完，而是让中断后的状态可识别、可恢复、不依赖 Redis 单点内存。超时只是信号，背后暴露的是任务粒度、状态持久化和集群约束三重问题——任何一个没对齐，续传就变成玄学。