Redis用Lua处理大列表不阻塞

Redis处理大列表时，直接使用LPOP或LRANGE等命令极易引发严重阻塞，因其O(N)时间复杂度在单线程模型下会独占CPU、拖垮整体性能，导致请求排队、超时及连接池耗尽；而通过Lua脚本将“安全读取+原子裁剪”封装为一次执行，既能严格控制数据量（如限定LRANGE范围）、避免全量加载，又能消除网络往返与中间状态风险，配合EVALSHA优化调用开销、妥善处理空key等边界情况，才是真正兼顾性能、可靠与可维护的大列表治理方案——稍不谨慎的一行命令，就可能是压垮Redis的定时炸弹。

为什么直接用 LPOP 或 LRANGE 处理大列表会阻塞？

Redis 是单线程执行命令的，LPOP、LRANGE 这类命令在列表长度达几十万甚至百万时，会占用大量 CPU 时间，导致后续请求排队等待。尤其当客户端频繁轮询或批量消费时，很容易触发 redis-cli 的超时或应用层连接池耗尽。

典型现象包括：ERR BUSY Redis is busy running a script（脚本执行过久）、监控显示 used_cpu_sys 突增、慢日志里反复出现 LRANGE 0 -1。

• 列表越长，LRANGE 0 -1 时间复杂度越接近 O(N)，不是常量操作
• LTRIM 虽能删旧数据，但若要保留中间段（比如只取第 10000–10100 条），必须先 LRANGE 再 LTRIM，两次 O(N) 操作叠加更危险
• 客户端分页拉取 + 服务端逐条 LPOP，网络往返和锁持有时间翻倍

用 Lua 脚本原子读取并裁剪大列表：一个安全模式

核心思路是把「读一批 + 删这批」合并为一个 Lua 脚本，由 Redis 原子执行，避免中间状态暴露，也省去多次网络往返。关键点在于不依赖 LRANGE 全量加载，而是用 lindex 或分段 lrange 控制数据量。

例如，安全消费前 100 条并删除：

local items = redis.call('LRANGE', KEYS[1], 0, 99)
redis.call('LTRIM', KEYS[1], 100, -1)
return items

• 这个脚本只做两件事：一次 LRANGE（限定长度）、一次 LTRIM（O(1) 截断头部）
• 务必用 0, 99 而非 0, -1，否则仍可能阻塞
• 如果列表实际不足 100 条，LRANGE 返回全部，LTRIM 100 -1 会清空列表（Redis 行为，无需额外判断）
• 脚本返回值就是你要的数据，客户端无需再发 GET 请求

EVAL 和 EVALSHA 性能差异在哪？

每次用 EVAL 提交脚本，Redis 都要解析、编译、缓存 SHA1，对高频调用场景有明显开销。生产环境应优先用 EVALSHA。

• 首次用 EVAL 注册脚本，拿到返回的 SHA1（如 "4e251b7a876c17b4f1a773818e843d2a2a9c8d9e"）
• 后续全部改用 EVALSHA 1 list_key，跳过编译，执行更快更稳
• 若 Redis 重启后 SHA 缓存丢失，EVALSHA 会返回 NULL，此时需 fallback 到 EVAL 重载
• 别把脚本硬编码在业务代码里拼接字符串，用配置中心或启动时预加载更可靠

真正容易被忽略的边界：列表为空或 key 不存在时的行为

很多人测试只用非空列表，上线后遇到空 key 就出错。Lua 脚本里 redis.call('LRANGE', 'missing_key', 0, 99) 返回空表 {}，不是 nil —— 这没问题；但若脚本里写了 if #items == 0 then redis.call('DEL', KEYS[1]) end，就可能误删刚创建的 key。

• LRANGE 对不存在的 key 返回空数组，不会报错
• LTRIM 对不存在的 key 也不报错，等效于 noop
• 但 LLEN 对不存在 key 返回 0，可用于提前判断是否值得执行整段逻辑
• 如果业务要求“空列表自动清理”，应在脚本开头加 if redis.call('EXISTS', KEYS[1]) == 0 then return {} end 显式控制

大列表处理真正的难点不在语法，而在对 Redis 单线程模型的敬畏——哪怕一行 LRANGE，没限长就是定时炸弹。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于数据库的相关知识，也可关注golang学习网公众号。