直接用lpop或lrange处理大列表会阻塞，因其时间复杂度为o(n)，在单线程redis中长时间占用cpu，导致后续请求排队、超时及连接池耗尽。
为什么直接用 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 条并删除：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
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 <sha> 1 list_key</sha>，跳过编译，执行更快更稳 - 若 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，没限长就是定时炸弹。
