RedisList限制队列长度技巧

Redis的List结构无法通过简单的LPUSH+LPOP组合实现可靠队列长度限制，因为LPOP删除队首而新元素插入队尾，会导致列表持续膨胀；真正安全、原子的限长方案是LPUSH（或RPUSH）后立即执行LTRIM进行服务端截断，或更优地——使用Lua脚本将推入与裁剪封装为不可分割的原子操作，从而彻底规避高并发下的竞态超限风险；同时需注意LTRIM的索引语义（如- N -1保留最新N条）、边界安全性及类型一致性，避免因误用数据类型引发全局失败。

为什么不能靠LPUSH+LPOP自动限长

很多人以为只要每次 LPUSH 后紧跟 LPOP 就能维持固定长度，其实这是错的——LPOP 删除的是队首元素，而新元素在队尾，中间会不断堆积，实际长度持续增长。真正要截断旧数据，必须主动清理尾部或头部冗余项。

LTRIM 是唯一可靠的限长手段

LTRIM 直接在服务端裁剪列表，只保留指定索引范围内的元素，其余立即释放内存。它不是“删除后再插入”，而是原子性截断，不存在竞态导致超长的问题。

• 保留最新 N 条：用 LTRIM key -N -1（负索引从尾部计数）
• 保留最老 N 条：用 LTRIM key 0 N-1
• 执行顺序必须是 LPUSH 或 RPUSH 之后立刻 LTRIM，否则窗口期可能超限
• Redis 7.0+ 支持 LPUSH key value LIMIT N 语法，但仅限于单元素 push 场景，不通用

用 Lua 脚本保证原子性（生产环境必需）

单独发 LPUSH 和 LTRIM 两条命令，在高并发下仍有极小概率被其他客户端插队，导致临时超长。必须封装为 Lua 脚本执行：

eval "redis.call('LPUSH', KEYS[1], ARGV[1]); redis.call('LTRIM', KEYS[1], 0, tonumber(ARGV[2])-1); return 1" 1 mylist new_item 100

上面脚本把「推入 + 截老」打包成一个原子操作，ARGV[2] 是目标最大长度，0 到 N-1 精确保留最老的 N 条；若想留最新的 N 条，把 0 换成 -ARGV[2] 即可。

注意 LTRIM 的边界行为和性能影响

LTRIM 时间复杂度是 O(N)，N 是被删除的元素个数，不是总长度。所以日常维护时尽量控制单次裁剪量——比如每 push 一次就 trim 一次，比攒够 1000 次再 trim 一次更平稳。

• 索引越界不会报错：LTRIM key 100 200 对空列表或长度不足的列表是安全的
• 当列表长度小于指定范围时，LTRIM 不做任何事，也不会失败
• 如果用负索引（如 -10 -1），而列表实际只有 3 个元素，结果就是保留全部 3 个
• 频繁 LTRIM 不会导致内存碎片，Redis 内部会直接调整底层链表指针

真正容易被忽略的是：Lua 脚本里调用 redis.call 失败会中断整个脚本，但 LTRIM 几乎不会失败，除非 key 类型错误——所以务必确保目标 key 始终是 List 类型，混用 SET 或 HASH 会导致后续所有操作报 WRONGTYPE 错误。

以上就是《RedisList限制队列长度技巧》的详细内容，更多关于的资料请关注golang学习网公众号！