Redis 6.0+ 的 lua-time-limit 控制 Lua 脚本在单次 redis.call 中的连续执行超时，默认5000ms；超时后直接断连而非返回ERR，需客户端捕获连接异常并重试；每次 redis.call 重置计时器，纯计算循环易触发超时。
Redis 6.0+ 的 lua-time-limit 配置决定超时行为
Redis 对 Lua 脚本的超时控制不是靠脚本自身中断，而是靠服务端强制终止。关键参数是 lua-time-limit（单位毫秒），默认 5000。它只限制脚本在单次调用中“在 Redis 线程里连续执行”的时间，不包括阻塞 I/O 或等待其他操作。
- 这个值设太小（比如 100），简单循环或遍历大集合就容易触发超时；设太大（比如 30000），可能拖垮整个实例的响应能力
- 修改后需
CONFIG REWRITE或重启才持久生效；运行时可用CONFIG SET lua-time-limit 8000临时调整 - 注意：该配置对
EVAL和EVALSHA都生效，但不影响SCRIPT LOAD
超时发生时，Redis 不会返回错误，而是直接断开连接
这是最容易误判的一点：客户端收不到 ERR 响应，而是遇到连接被重置（如 Python 的 ConnectionResetError、Node.js 的 ECONNRESET）。因为 Redis 在超时后直接 kill 掉当前 client socket，不走正常回复流程。
- 常见现象：脚本执行一半突然报 “Connection closed by server” 或 “broken pipe”，日志里却找不到对应错误
- Redis 服务端会在
redis.log中写入类似Script attempted to execute a command that would exceed the configured timeout的警告（需开启loglevel notice或更高） - 客户端不能依赖 try-catch 捕获
ERR类错误来处理超时，得监听连接异常并做幂等重试或降级
EVAL 中调用 redis.call() 会重置单次执行计时器
Redis 的超时计时器不是从脚本开头开始算总耗时，而是在每次进入 Redis 命令执行上下文时重置。也就是说，每个 redis.call() 或 redis.pcall() 调用都会重新开始 5000ms（或你设的值）倒计时。
- 这意味着一个含多次
redis.call("HGETALL", ...)的脚本，只要每次调用本身不超时，整体可以跑很久——但风险是累积延迟高、线程占满 - 反例：在 Lua 里用
for i=1,100000 do end纯计算，不调任何redis.call，就会卡死在单次计时器里，必然触发超时 - 调试技巧：在可疑循环里插一句
redis.call("PING")，可主动“续命”，但慎用——这会让脚本更难预测，且增加无谓开销
集群模式下，Lua 脚本超时逻辑不变，但影响范围更隐蔽
Redis Cluster 对 Lua 的要求没变：脚本必须只操作一个 slot 上的 key（否则报 CROSSSLOT 错误），而超时判断仍由具体负责该 slot 的 master 节点独立执行。
- 问题在于：超时只发生在某个分片节点上，其他节点不受影响，但客户端可能因连接中断误以为整个集群异常
- 如果脚本涉及多个 key 且恰好落在不同节点（哪怕用了
{}tag 强制路由），一旦其中某节点超时，整个请求失败，且不会回滚已执行的部分 - 监控建议：单独采集各分片节点的
rejected_connections和total_commands_processed差值突增，比单纯看慢日志更容易发现局部超时热点
lua-time-limit，而是当某个分片因脚本卡住导致连接池枯竭、健康检查失败、流量被踢出集群时，你根本没在日志第一屏看到那行 Script attempted to...。 
