Redis List队列长度限制详解：LTRIM命令实现高效固定长度缓存
为什么LPUSH+LPOP组合无法实现自动长度限制
许多开发者误以为通过LPUSH后立即执行LPOP就能自动维持队列的固定长度，这种理解存在根本性缺陷。核心问题在于操作方向的不匹配：LPUSH将新元素插入列表头部，而LPOP移除的却是列表尾部的元素。这种头尾错位的操作逻辑导致中间元素永远无法被自动清理，队列长度会持续累积，旧数据不断堆积形成内存泄漏风险。要实现真正的长度控制，必须采用主动裁剪机制，精确移除超出设定范围的多余元素。
LTRIM命令：实现Redis List长度限制的唯一可靠方案
Redis提供的LTRIM命令是解决队列长度限制问题的标准答案。该命令能够在服务器端直接对列表进行精准截断，仅保留指定索引范围内的元素，超出的部分会被立即删除并释放内存。这一操作具有原子性特性，避免了"先删除后插入"可能引发的竞态条件问题，确保队列长度始终处于可控状态。
- 保留最新N条记录：使用
LTRIM key -N -1命令（负索引表示从列表末尾开始计算）。 - 保留最旧N条记录：使用
LTRIM key 0 N-1命令。 - 关键执行顺序：必须在
LPUSH或RPUSH操作完成后立即执行LTRIM命令，防止两条命令执行间隙出现长度超标。 - Redis 7.0+新特性：Redis 7.0及以上版本提供了
LPUSH key value LIMIT N简化语法，但该语法仅适用于单元素推送场景，通用性相对有限。
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
该脚本将"插入新元素"与"截断保留最旧N条"两个操作打包为不可分割的原子操作。其中ARGV[2]参数指定目标最大长度，索引范围0到N-1确保只保留最旧的N条记录。如需保留最新N条，只需将起始索引参数修改为-ARGV[2]即可。
LTRIM命令的边界行为特性与性能优化策略
使用LTRIM命令时需要注意其特有的边界处理机制和性能特征。该命令的时间复杂度为O(N)，其中N代表被删除的元素数量而非列表总长度。因此推荐采用"频繁小批量裁剪"策略：每次push操作后立即执行trim，这比累积大量变更后一次性大规模裁剪对服务性能的影响更小、更平稳。
- 索引越界安全性：对空列表或长度不足的列表执行如
LTRIM key 100 200的命令不会引发错误，只会返回空列表或保留全部现有元素。 - 宽容的范围处理机制：当指定的索引范围超出列表实际长度时，
LTRIM不会执行任何操作，也不会返回失败状态。 - 负索引智能匹配：例如执行
LTRIM key -10 -1时，如果列表实际只有3个元素，则这3个元素会被全部保留。 - 高效内存管理：频繁调用
LTRIM不会导致严重的内存碎片问题，因为Redis内部通过调整底层链表指针直接实现元素裁剪。
最后需要特别注意一个易忽略的陷阱：在Lua脚本执行过程中，如果redis.call调用失败，整个脚本将立即中止。虽然LTRIM本身极少失败（除非键类型错误），但这提醒我们必须确保操作的目标键始终为List类型。如果将SET或HASH类型的键误当作List执行LTRIM操作，会触发WRONGTYPE错误并导致后续逻辑中断。在混合使用多种数据结构的复杂业务场景中，这一细节需要格外关注。
