首页 > 数据库 > Redis

Redis Lua 脚本为什么会阻塞请求：慢脚本定位、超时边界与恢复验证

来源：17golang原创

时间：2026-08-24 18:07:02 370浏览收藏

线上接口的 P99 突然从几十毫秒抬到数秒，应用日志却没有明显的连接错误，这时要先想到一个容易被忽略的点：Redis 的 Lua 脚本在服务端执行期间会占住主线程，后续提交的命令只能排队等待。排查重点不是一上来就把客户端超时调大，而是找出哪段脚本正在占用执行窗口，再确认终止它会不会破坏业务原子性。

Redis Lua 脚本运行时会全程独占服务端主线程，不支持其他命令插队打断，后续所有进入 Redis 的请求都得排队等当前脚本执行完毕，这就是慢脚本能拖垮大量无关请求的核心原因。

要点速览

用 SLOWLOG 和 LATENCY 先确认是服务端耗时异常，别把客户端重试当成根因。
脚本执行过程中没法靠普通查询插队打断；停止操作要结合业务是否已经写入数据来判断影响。
恢复后要同时复查脚本耗时、排队延迟和业务结果，三项都正常才算彻底处理完成。

先把“请求变慢”拆成三个证据

同样是接口变慢，诱因可能是网络抖动、连接池耗尽，也可能是 Redis 服务端正在处理一段长时间运行的脚本。先在问题发生的时间窗口里留存取证数据，别一上来就清空日志或者直接重启实例，把唯一的排查线索一起抹掉。

redis-cli SLOWLOG GET 20
redis-cli CONFIG GET slowlog-log-slower-than
redis-cli LATENCY LATEST
redis-cli INFO commandstats

SLOWLOG GET 能看到最近记录的命令、耗时和参数摘要；LATENCY LATEST 则帮助判断是否出现了 command、fork 或 fast-command 等延迟事件。两者都没有异常时，继续看应用侧连接等待和网络往返，不要强行把锅扣到 Lua 上。

Redis Lua 慢脚本排查路径：SLOWLOG 与 LATENCY 证据指向脚本耗时和请求排队

从慢脚本记录判断阻塞来源

脚本常以 EVALSHA 出现在慢日志里。重点看它的耗时是否明显高于平时，以及同一时间点后面是否跟着一串普通 GET、SET 或队列命令。如果脚本耗时只有 20 毫秒，应用却等待 3 秒，应该转查连接池或网络；如果脚本耗时本身接近秒级，才进入脚本边界排查。

观察结果	更可能的结论	下一步
EVALSHA 耗时持续升高	脚本循环逻辑或者批量输入规模膨胀	核对 KEYS/ARGV 数量和循环上界设置
脚本耗时正常，连接等待升高	客户端连接池满溢或者网络拥塞	核对连接数、超时配置和重试发生的时间线
脚本结束后普通命令集中变慢	主线程排队效应被放大	关联脚本结束时间与请求 P99 上涨的时间点

这里别只盯着脚本本身的代码内容。记录调用方传入的 key 数量、批次大小和业务请求 ID，通常比把整段脚本复制到工单里更有排查价值。生产环境还应确认脚本是否会访问用户可控的 key，避免一次异常输入把循环次数推到不可接受的范围。

超时发生时，停止边界要先问清楚

客户端超时只代表调用方不再等待，不代表 Redis 已经停止执行。脚本仍在运行时，其他命令不会绕过它。可以在受控窗口用 CLIENT LIST、监控指标和慢日志确认现场；确需停止时，再评估业务是否允许中断，以及脚本是否已经完成部分外部副作用。

redis-cli CLIENT LIST
redis-cli SLOWLOG GET 10
redis-cli LATENCY DOCTOR

如果脚本只操作 Redis 内部数据并且支持重放校验，停止后可以按业务补偿流程恢复；如果脚本和外部消息、库存或账务状态存在联动，不能把“停止脚本成功”等同于“业务已经回滚成功”。先冻结重复请求，再通过业务流水逐条核对写入结果。

修复脚本时优先收紧输入和工作量

最小修复通常不是立刻替换掉 Lua 实现，而是给单次调用的工作量加上硬上限：限制 KEYS 数量，禁止在脚本里扫描无界集合，把大批量任务拆成多个小批次，同时在调用方记录实际传入的批次大小。脚本需要继续保留原子性时，可以把单次处理量压到可预期的安全范围内，再用队列逐批推进。

-- 伪代码：让每次调用只处理有限成员
local limit = tonumber(ARGV[1])
if limit == nil or limit  200 then
  return {err = "invalid batch limit"}
end
-- 后续只在 limit 范围内读取和更新

Redis 脚本不适合做大范围数据整理，也不适合把未知数量的集合遍历塞进一次请求。针对固定 key 的短事务逻辑，可以保留脚本实现；针对持续增长的数据处理场景，改成小批次任务拆分的方式往往更稳定。

恢复后用三次复查确认没有假恢复

复查脚本耗时：同样输入规模下，SLOWLOG 不再出现异常长耗时。
复查排队延迟：接口 P99、Redis command latency 和连接等待时长都回到日常基线附近。
复查业务结果：抽样核对幂等键、状态变更和补偿记录，确认没有重复写入或者漏处理的情况。

只看到接口恢复正常却没做业务核对，最多只能说明阻塞已经消失；只有三组验证证据都通过，才能把这次事故标记为已恢复。把脚本版本、输入规模、耗时和最终结果写入复盘记录，下一次出现相同趋势时可以直接做对比排查。

收口清单

遇到 Redis Lua 阻塞请求的问题，先留存 SLOWLOG、LATENCY 和应用请求时间线数据；再确认脚本的输入规模、执行状态和已经产生的业务副作用；修复完成后同时复查服务端延迟、客户端 P99 与业务流水。这样处理，既不会被一次客户端超时的表象误导，也不会在没有完成结果核对的情况下贸然重放请求。