Redis超时是连接被硬杀而非报错，客户端需捕获网络层异常；续传须拆分任务、原子更新偏移量并确保集群slot一致。
超时不是报错，而是连接被硬杀
Redis 超时后不会返回 ERR 或任何响应，而是直接关闭 socket 连接。客户端看到的是 ConnectionResetError（Python）、ECONNRESET（Node.js）或类似“broken pipe”的底层异常。这不是脚本没执行完，是 Redis 主动掐断了连接——所以你不能靠捕获 redis.call() 的错误来处理超时。
常见误判：在 Lua 里用 pcall(redis.call(...)) 包裹操作，以为能兜住超时；实际上超时发生在 Redis 线程内，Lua 解释器已被终止，pcall 根本没机会执行。
- 服务端日志会写
Script attempted to execute a command that would exceed the configured timeout（需 loglevel ≥ notice） - 客户端必须监听网络层异常，而非命令级错误
- 重试前需确认脚本幂等性——比如用
SET key val NX EX 60替代无条件SET
用 redis.call() “续命”不等于安全续传
每次调用 redis.call() 或 redis.pcall() 都会重置 lua-time-limit 计时器，但这只是让脚本“活下来”，不是真正的断点续传。它掩盖了设计缺陷：把本该拆分的长任务塞进单个脚本里。
例如遍历 10 万个 key 做处理，插 100 次 redis.call("PING") 确实能避免超时，但整个脚本仍占用主线程数十秒，阻塞其他请求。
- 真正可续传的方案是：把大任务拆成多个小脚本，每个只处理固定数量（如 100 个）key，用唯一 token 标记进度
- 用
INCR或HINCRBY记录已处理 offset，失败后从下一个 offset 继续 - 避免在脚本里做纯计算循环，必须循环时加
redis.call("PING")仅作保底，不作为主逻辑
断点续传状态必须存 Redis，且结构要支持原子更新
续传依赖外部状态存储，这个状态本身不能成为瓶颈或单点故障。用 Redis 存，但别用 GET/SET 两步更新——竞态下会丢进度。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
推荐组合：HSET 存任务元信息 + INCR 更新偏移量 + EXPIRE 设过期时间。例如：
HMSET task:abc status "running" total 100000 started_at 1720851600 INCR task:abc:offset
关键点：
- 用
HSETNX初始化任务，避免重复提交 - 用
WATCH+MULTI包裹状态变更（如果业务强一致性要求高） - 所有 key 命名带唯一 task ID，防止不同任务互相污染
- 客户端每次执行前先
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）。
- 不要在续传脚本里动态拼接 key 名而不校验 slot，否则首次成功、续传失败
- 用
EVALSHA而非EVAL，避免传输大脚本增加网络延迟 - 脚本中所有
KEYS必须显式传入，不能靠字符串拼接生成，否则 Cluster 模式下解析失败
真正难的不是让脚本跑完，而是让中断后的状态可识别、可恢复、不依赖 Redis 单点内存。超时只是信号，背后暴露的是任务粒度、状态持久化和集群约束三重问题——任何一个没对齐，续传就变成玄学。
