先讲一个我遇到过的事。有次做活动秒杀下单接口被瞬时流量打得直告警数据库连接池瞬间被占满。当时没有条件上Kafka这类重型中间件我就用Redis的List做了一条轻量消息队列订单请求先LPUSH进队列后端服务用BRPOP慢慢消费把高峰期的压力削平了。这个方案上线后非常稳甚至在那之后很长一段时间里团队内部凡是遇到“需要一个简单可靠的队列”的场景第一反应就是拿List顶上去。也是从那次开始我发现Redis的List在五种基础数据类型里属于“存在感很低但特别能打”的那种。它不像String那样简单直接也不像ZSet那样天生带排序光环程序员平时写业务用到List的机会其实不少但很多人对它的理解停留在“能存一组数据”这个层面。底层结构怎么演进、命令的复杂度边界在哪、什么场景该用什么命令、实际运行中会踩哪些坑——这些细节才是真正决定你能不能在生产环境里放心用它。这篇文章我会把这些东西完整过一遍从List的定位开始到底层结构演进到常用命令逐条拆解再到真实场景的代码写法和调优参数最后聊聊我在生产环境里因为List翻过的几次车。无论你是刚开始学Redis的初学者还是已经用Redis写过不少业务代码的开发者这篇应该都能给你一些以前没注意到的视角。1. List的定位一个可以被两端读写、还能阻塞的有序队列1.1 和其他五种数据类型放在一起看Redis官方把List描述为“linked list of strings”也就是一个字符串组成的链表。但如果你只记住“链表”两个字很容易把它和C语言里的单链表混在一起。实际上Redis里的List更多像是一个“复合体”它既能当队列用也能当栈用还能当数组用。从API设计上看List支持在头部Left和尾部Right两个方向做写入和弹出所以“L”开头的命令操作头部“R”开头的命令操作尾部。这就带来了一个非常独特的特性同一个List左边压入右边弹出就是FIFO队列左边压入左边弹出就是LIFO栈。切换成本为零只是命令组合不同而已。把五种数据类型放在一张表里对照会更清楚List的位置类型底层结构关键特性典型场景StringSDS动态字符串可存任意二进制原子自增自减缓存、计数器、分布式锁Hashlistpack / hashtable适合存取对象字段用户信息、商品详情Listquicklist有序、可重复、双端操作、阻塞读取队列、时间线、最新列表Setintset / hashtable无序、自动去重、集合运算标签、关注关系、抽奖ZSetlistpack / skiplist带分值的有序集合排行榜、延迟队列、滑动窗口注意一个关键点List的元素是有序且允许重复的。这个“有序”指的是插入顺序不是ZSet那种按分值大小排序。如果你需要元素按某个权重排序List做不到如果你需要去掉重复元素List也做不到——那是Set的活。很多人把List当成万能容器什么数据都往里塞这是第一个容易出问题的地方。1.2 List常被误用的两个地方我见过不少团队在两种场景里错误地选了List。第一个是拿List当Set用。运营后台要展示一个去重后的用户ID列表有人图省事直接LPUSH每次先LRANGE全量读出来再在业务代码里去重。如果数据量小还好数据一旦上到十万百万级每次全量读取LRANGE都是O(N)加上序列化开销接口响应时间直接涨一个量级。这种场景应该用SADD SMEMBERS或者干脆用ZSet按时间倒序。第二个是拿List做延迟队列。List的每个元素只是一个字符串没有“时间戳”这种元数据。你想做延迟任务只能在业务代码里把执行时间拼进字符串比如task_123_1699999999然后消费者自己解析、比对时间、决定是否重新放回队列。这中间每一步都可能出bug而且轮询空转还浪费CPU。延迟队列的正确选择是ZSetscore存执行时间戳用ZRANGEBYSCORE把到期的任务捞出来。这一点我在后面的翻车复盘里还会细讲。所以理解List的定位重点不是“它有什么用”而是“它不该用来干什么”。一个数据结构只有在合适的场景里才能发挥价值List也是一样。2. 结构演进quicklist和listpack到底在优化什么2.1 前3.2时代两个极端结构的取舍面试里经常被问到“Redis List的底层结构是什么”很多背过八股的人会脱口而出“quicklist”。但如果你把时间轴拉回Redis 3.2之前答案其实不是唯一的。早期List根据元素数量和单个元素大小会在两种编码之间切换linkedlist和ziplist。linkedlist就是标准的双向链表每个节点包含prev指针、next指针、value指针。插入删除都是O(1)但内存开销大——一个节点的指针开销甚至可能比实际存储的字符串还要大。当一个List里塞了上百万个小整数时光指针就占掉一大片内存。ziplist正好相反它是一段连续内存把所有元素按紧凑格式排列在一起省去了指针开销。但它有两个致命问题一是因为内存连续插入或删除元素时可能触发连锁更新导致整个ziplist在内存里反复搬迁最坏情况下时间复杂度退化成O(N²)二是当列表很长、元素很大时一次读取需要遍历整个内存块CPU缓存命中率急剧下降。当时的Redis只能二选一要么用linkedlist换性能要么用ziplist省内存。直到Redis 3.2引入了quicklist才把这两条路线合到了一起。2.2 quicklist的折中方案quicklist的设计思路非常朴素既然是双向链表的指针开销大那我就把多个元素打包成一个节点节点之间用双向指针串起来。这样每个节点内部是一份紧凑的ziplist节点之间是链表结构。翻译成人话就是——每个“车厢”不再是只装一件货物而是一个装的满满的集装箱再用链条把集装箱连起来。这个设计的好处是两头兼顾从整体看它保留了双向链表在头部和尾部O(1)插入删除的特性从局部看每个quicklistNode内部的ziplist压缩了多个元素指针开销被摊薄到多个元素头上。而且Redis还允许你对中间节点做LZF压缩进一步降低内存占用这就是后面要讲的list-compress-depth参数。quicklist节点的大小不是固定的它由list-max-ziplist-size这个配置控制。你可以配置每个节点最多装多少个元素也可以配置每个节点的ziplist最大占用多少字节。这个参数直接决定了一个大List在内存里是一个“大集装箱”还是很多个“小集装箱”对性能和内存的影响非常直接。2.3 Redis 7.0的listpack替换到了Redis 7.0ziplist被正式移除quicklist内部的编码换成了listpack。很多人会疑惑ziplist和listpack不是差不多吗其实差别很大。ziplist存在一个老问题是“连锁更新”因为它的每个entry都保存了前一个entry的长度信息prevlen。如果前一个entry的长度发生变化后面的entry的prevlen字段就需要跟着调整可能引发级联反应。listpack把prevlen从每个entry里去掉改成了每个entry只管自己的长度从根上消灭了连锁更新的可能性。对使用者来说这个变化是透明的——你的LPUSH、LRANGE命令写法完全不用变但Redis内部处理极端情况时更稳定了。从ziplist到listpack本质上是Redis在“极简存储格式”这条路上做得更彻底了。如果你在用Redis 7.0以上版本可以把list-max-ziplist-size这个参数名改成list-max-listpack-size来用了。理解这层演进不只是为了应付面试。它直接影响你调优时的判断当你看到内存增长异常、某个List操作延迟突然飙升你至少知道问题可能出在quicklist的节点拆分、压缩深度、或者元素大小分布上而不是一头雾水地瞎调。3. 命令全景17个命令里最常用的9个怎么用List一共提供了17个命令。我按用途把它们拆成四组写入、读取、修改、阻塞。逐组拆开看每一个命令的语义和边界条件都值得说清楚。3.1 写入类LPUSH与RPUSH的语义差别LPUSH key value [value ...] RPUSH key value [value ...] LPUSHX key value # key必须存在才生效 RPUSHX key valueLPUSH是往头部插入RPUSH是往尾部插入。但这里有个非常容易忽略的细节当一次插入多个值的时候LPUSH的插入顺序是“逆序”的。举个例子LPUSH mylist A B C LRANGE mylist 0 -1 # 结果是 C B A不是 A B C为什么因为每次LPUSH都是往头部插插完A之后头部是A再插B的时候B跑到A前面去了再插CC又排在B前面。最终顺序就是C、B、A。很多人在初始化列表数据时想按顺序插入却发现输出顺序是反的就是这个原因。如果你希望插入后保持自然顺序请用RPUSH。LPUSHX和RPUSHX则是带条件的写入只有key已经存在时才会生效。它们适合用来维护“只在已有列表里追加”的逻辑比如往一个已经存在的活动名单里添人但不会因为误操作自动创建一个空列表。这种边界语义在实际业务里能帮你省掉一次“先查询再写入”的交互。3.2 读取类LRANGE的分页陷阱LRANGE key start stop LINDEX key index LLEN key LPOP key [count] RPOP key [count]LRANGE大概是List里最常用的读取命令了分页查询基本靠它。用法是左闭右闭区间LRANGE mylist 0 9返回下标0到9一共10个元素。这个命令有两个坑。第一个坑是它的一次性时间复杂度是O(SN)其中S是start偏移量。这意味着如果你用LRANGE 0 -1去读一个几十万元素的ListRedis要一次性遍历这个List的前面所有节点再返回全部数据延迟和内存都会暴涨。很多大Key查询卡死就是这么来的。第二个坑是分页深翻页的性能问题。List没有像数据库那样的“索引跳跃”能力你翻到第100页就需要从头走到第100页的起始位置每次翻页都是O(N)。如果分页深度很大性能衰减非常明显。建议的做法是要么限制List的总长度配合LTRIM要么用ZSet按时间戳排序后分页不要让List承载深分页这种它不擅长的读需求。LPOP和RPOP在Redis 6.2之后支持了count参数LPOP mylist 5会一次性弹出前5个元素返回一个数组。注意区分count弹出后元素是真正被删掉的LRANGE只是“看”不会删除任何元素。这两个语义在调试时最容易混淆。3.3 阻塞队列BLPOP/BRPOP的使用边界如果说LPUSH和RPUSH让List具备了队列能力那么BLPOP和BRPOP让这个队列真正具备生产环境可用的可靠性。它们专门干一件事当队列为空时阻塞等待指定时间直到有数据进来或者超时。BLPOP queue timeouttimeout单位是秒传0表示无限期阻塞。这个特性让消费者程序不需要搞sleep轮询Redis会在队列有数据时立刻唤醒阻塞的客户端响应延迟低到毫秒级别。但阻塞命令有三个使用边界必须清楚多个key参数是轮询模式BLPOP支持传多个key比如BLPOP queue1 queue2 0它会按顺序检查每个key一旦发现非空就弹出一个元素并返回[key, value]这样的数组。如果前面的key里有元素后面的key永远不会被消费不要再把这种模式理解成“多路复用”。阻塞时间不是“最长等待”那么简单如果你设了timeout为5秒Redis会在5秒内持续等待一旦有新元素写入立刻返回。如果你的客户端TCP连接在阻塞期间断开了这个元素会被Redis丢弃因为没有消费者可投递之后另一个消费者重新连接时拿不到这个元素需要业务层自己兜底。消息不可达问题BRPOP读走了元素但消费端还没处理完就崩溃了这条消息就永远丢失了。解决办法是使用RPOPLPUSH系列命令在执行弹出操作的同时把元素备份到另一个List中确认处理成功后再从备份List中删除这就是下一小节要说的可靠队列模型。3.4 可靠队列RPOPLPUSH / BRPOPLPUSHRPOPLPUSH source destination BRPOPLPUSH source destination timeout这个命令做的事一句话概括从source的尾部弹出一个元素再把它压入destination的头部。整个操作是原子的不会出现“弹出之后、压入之前”的中间状态。可靠队列的标准玩法是这样的消费者从队列Q尾部BRPOPLPUSH元素到“处理中队列”P的头部然后执行业务逻辑。处理成功之后从P里用LREM把这条消息删掉如果处理失败或消费者崩溃消息还留在P里可以由其他程序定时扫描P把滞留超时的消息重新投回Q实现重试机制。这套双队列模型虽然简单却解决了List做消息队列最关键的可靠性问题。Kafka这类专业消息队列提供的ack、重试、死信机制在List上你都能用这种“备份列表定时扫描”的方式手动模拟出来。对于流量规模不大、对顺序性要求不苛刻的业务完全够用而且不用引入额外的基础设施。3.5 修改类LSET、LINSERT、LREM、LTRIM最后四个修改类命令值得专门提一下因为它们各自有一个坑。LSET key index value # 按下标改元素index越界会报错 LINSERT key BEFORE|AFTER pivot value # 在某个元素前/后插入 LREM key count value # 按值删除count决定删除方向 LTRIM key start stop # 截断列表只保留区间内的元素LSET按下标改值时间复杂度O(N)因为要找到第N个元素。它的坑在于下标如果是负数且越界Redis直接抛错错误消息是ERR index out of range业务代码里如果不捕获这个异常很容易把整个请求搞挂。LREM的count参数有三种正数从头部开始删最多count个负数从尾部开始删0删掉所有匹配的元素。注意它是“按值删除”不是按下标删除。如果List里有大量重复值LREM 0 value会把它们全部删掉这可能不是你想要的。LTRIM看名字容易误会成“修剪”实际效果是“只保留选中区间其余全部删除”是控制List长度的利器。我维护用户最近N条记录时基本都是LPUSH LTRIM组合先插入再只保留前N个相当于把List变成一个固定长度的滑动窗口。这个操作一定要小心负数下标LTRIM key 0 -1表示保留全部元素不会删掉任何东西很多人在测试环境里用它截断列表发现数据一条没少就是这个原因。4. 场景落地消息队列、Timeline和固定长度列表的写法4.1 轻量消息队列削峰填谷的最佳配角List做消息队列的核心命令组合非常简单生产者LPUSH消费者BRPOP。下面用Python示例演示一下基本的代码写法。生产端import redis r redis.Redis(host127.0.0.1, port6379, decode_responsesTrue) def send_task(task_id, payload): message f{task_id}:{payload} r.lpush(task_queue, message)消费端import redis r redis.Redis(host127.0.0.1, port6379, decode_responsesTrue) while True: # 阻塞等待任务超时时间设为 0表示一直等待 result r.brpop(task_queue, timeout0) if result is None: continue _, message result task_id, payload message.split(:, 1) process_task(task_id, payload)生产端的LPUSH把消息塞进队列头部消费端的BRPOP从尾部弹出等价于FIFO。用Redis建立连接池的注意点在这里同样适用不要每次调用都新建一个连接高并发下连接会被打爆。这个方案的优点是显而易见的部署Redis成本低命令简单消费端天然支持多个实例并发BRPOP同一个队列。但缺点也必须心里有数一是消息不一定能绝对不丢除非配合BRPOPLPUSH做备份和重试二是没有消费进度持久化如果整个Redis挂了积压的消息只能靠AOF/RDB恢复恢复精度取决于持久化策略。所以这个方案适合对可靠性要求中等的业务如果要求“一条都不能丢”还是要上专业MQ。4.2 时间线Timeline用LRANGE做第一版Feed流社交产品里最常见的“用户发布内容、好友按时间倒序看到动态”这个场景用List实现特别自然。发动态时def publish_post(user_id, post_id): # 每次发帖把post_id推到自己粉丝的feed列表头部 for follower in get_followers(user_id): r.lpush(ffeed:{follower}, post_id)拉取动态时def get_feed(user_id, page1, page_size10): start (page - 1) * page_size end start page_size - 1 post_ids r.lrange(ffeed:{user_id}, start, end) return fetch_posts(post_ids)这套代码的优点是直观、读扩散。缺点上文也提过深翻页性能差。所以生产环境里很多团队会对每个feed List做长度上限控制比如只维护最近1000条动态再配合LRANGE做前几页的读取。如果业务量很大通常还会在手写时间线之外引入其他存储但List做第一版验证重不过。4.3 固定长度列表用户浏览记录与LTRIM用户最近浏览的商品、最近搜索的关键词这些数据有一个共同特征只关心最近N条。List的“左侧插入 右侧截断”是这类需求的标准解法。def add_recent_view(user_id, product_id, max_records50): key frecent_views:{user_id} pipe r.pipeline(transactionTrue) pipe.lpush(key, product_id) pipe.ltrim(key, 0, max_records - 1) pipe.execute()Pipeline保证LPUSH和LTRIM原子执行避免“插入还没截断”的中间状态。LTRIM把列表打到固定长度相当于内存管理上的自动清理。如果列表里已经有了同一个商品ID还可以先用LREM把旧的那条删掉再LPUSH实现“最近浏览不重复”的效果。这种写法的好处是List长度有天花板内存增长可控读取前N条永远O(N)且N很小。它把List当作一个纯天然的固定容量容器在用很多“只需最近N条”的数据都很适合。4.4 一个不适合List的场景分布式锁与延迟队列热词里经常能看到“Redis分布式锁”和“Redis延迟队列”这两个场景常常被初学者误以为也能用List实现我们在这里一并说清楚。分布式锁的主流做法是String类型的SET NX EX核心是利用单命令的原子性保证“同一时刻只有一个客户端能设置成功”。List能实现类似的互斥效果吗理论上可以多个客户端同时BRPOP一个锁队列抢到元素的就算拿到锁用完之后再LPUSH回去。但这样做完全没有必要因为SET NX天生就是干这个的而且List方案在锁超时、误删、重入这些边界问题上几乎每个都要踩一遍。如果你在代码评审里看到有人用List实现分布式锁建议直接用SET NX重构。延迟队列同样是ZSet的地盘。你要实现“5分钟后执行任务”用ZADD把任务塞进ZSetscore设为当前时间戳5分钟另起一个线程用ZRANGEBYSCORE把score小于当前时间戳的任务捞出来执行。List做不到这种精确的时间维度排序硬做只会给自己埋坑。5. 参数调优list-max-listpack-size和压缩深度的取舍5.1 节点大小一个决定内存和性能平衡的参数Redis 7.0以前这个参数叫list-max-ziplist-size7.0之后改名为list-max-listpack-size。它决定每个quicklist节点允许容纳多少元素或多少字节的数据。参数可以是正数或负数正数每个节点最多包含这么多entry例如设置为8表示每个listpack最多放8个元素。这样列表整体会被拆成很多个小节点读取时定位更快但内存开销也会因更多节点而上升。负数表示每个节点允许占用的内存上限-1到-5分别对应4KB、8KB、16KB、32KB、64KB。默认值是-2也就是每个listpack节点最多8KB。怎么选我的建议是如果List很小、访问频繁且对延迟敏感可以适当减少节点大小让头部和尾部的操作不跨越太多节点如果List巨大且主要访问头部和尾部队列场景节点大小可以放宽到-3或-4减少链表节点数量节省指针开销。绝不要在生产环境里直接改全局配置然后期待它万能。你可以先创建一两个测试List往里面写入和你业务规模相当的数据然后观察Redis的used_memory变化和命令延迟再决定参数取值。5.2 压缩深度中间节点省内存的代价list-compress-depth参数用来控制“从两端开始有多少个节点不被压缩”。0表示完全不压缩默认配置1表示最外层的1个节点不压缩其余节点压缩2表示外层两个节点不压缩以此类推。List的典型访问模式是哪两端队列场景里永远是头部入、尾部出两端的节点经常被访问中间节点很久才碰到一次。把这些中间节点用LZF压缩可以省下一大截内存尤其是元素本身很大或者重复度很高的时候。压缩不是没有代价的。访问被压缩的节点时Redis需要先解压再读取这会带来CPU开销。所以压缩深度也不要无脑调大一般1到2就够了。如果业务平均每个消费者只访问最近几条数据那么压缩深度调成1让头尾各一个节点保持未压缩状态兼顾性能和内存。5.3 如何监控和定位大Key配置调完之后怎么知道效果两个方法。一是看INFO命令里的内存信息redis-cli INFO memory关注used_memory、used_memory_human、mem_fragmentation_ratio这几个指标。如果碎片率长期大于1.5说明内存分配存在问题可能和大量小对象、频繁增删有关。二是用--bigkeys做全量扫描redis-cli --bigkeys这个命令会扫描所有key按数据类型统计最大的几个。如果你发现List类型里有几十万个元素的key就是典型的大Key。大Key的危害是单次操作耗时高、阻塞其他客户端请求、切换持久化时内存开销大。定位到之后通常的做法是能业务拆分就拆分比如按用户ID分片不能拆分就限流LTRIM把长度砍到业务可接受的最小值。6. 生产环境里的四次翻车与事后复盘6.1 大Key引发的全链路阻塞前年我们有个活动系统每天凌晨定时任务往同一个List里LPUSH几万条投放记录。刚开始没觉得有什么问题直到某天线上Redis的延迟从0.5ms飙到200ms所有业务都跟着慢了才知道出事了。排查过程是先跑了一次redis-cli --bigkeys发现那个List已经膨胀到上百万个元素单个key占用了近300MB内存。因为quicklist节点数量越来越多LRANGE一个稍微大点的范围就要遍历多个节点加上压缩节点解压的CPU开销直接把Redis的单线程事件循环卡住了。事后我们做了三件事一是对这个List按日期维度拆分成多个key比如list:20240501、list:20240502二是给定时任务加上检查和报警写入前先LLEN如果超过阈值就不继续写三是把所有针对这个List的查询都改成只取头部和尾部附近的数据禁止无脑LRANGE 0 -1。从那以后这个业务的Redis延迟再也没出过问题。6.2 多消费者竞争BRPOP之后的重复消费另一个项目里我们部署了三个消费者实例并发BRPOP同一个任务队列。本来以为BRPOP的原子性可以保证每条消息只被一个消费者拿到的结果上线后发现有部分任务被重复执行了。根因不是BRPOP本身的问题而是出在处理流程上消费者A用BRPOP把消息M弹出了但还没来得及执行任务进程就被重启了消费者B重新BRPOP时拿到的是下一条消息M1而消息M已经离开了队列。看起来M是丢了但实际上我们自己的守护进程“兜底”扫描了备份列表发现M还在里面于是又把它投递了一次导致重复执行。这个问题的本质是BRPOP保证了“弹出”这一步是原子的但它管不了“弹出之后业务逻辑是否成功”。解决重复消费有两种常用思路一是使用BRPOPLPUSH把元素先放进处理中队列处理成功后再移除失败则重投二是在消息内容里加唯一ID消费者执行前先去Set查一下这个ID是不是处理过也就是幂等控制。线上系统不要只依赖其中一个两个一起上更稳妥。6.3 延迟队列选了List一个让我后悔的决策有一版需求要做“用户下单30分钟后未支付自动取消”。当时为了赶进度没有仔细调研直接用了List每天凌晨扫一遍所有订单List把超过30分钟的去执行取消。这版实现的问题很快就暴出来了一是List只能按插入顺序扫描订单如果很多每次全量扫描成本极高二是“30分钟”是时间维度List存储的顺序和这个维度毫无关系我们只能靠业务字段里的时间戳来过滤等于每次都要把所有元素都读一遍再在内存里判断要不要处理三是无法精确控制“每分钟只处理到期订单”空转查询浪费了大量CPU。后来我把它改成ZSetmember存订单号score存下单时间戳用一个循环脚本ZRANGEBYSCORE min max把score小于当前时间的时间戳对应的订单全捞出来再执行取消。代码量下降了三分之一性能提升了不止一个量级。这个经历让我形成了一个条件反射凡是和时间、优先级、权重挂钩的数据结构先想ZSet别拿List硬刚。6.4 LTRIM负下标的边界错觉最后一次翻车不算严重但特别有代表性。测试环境里同事执行了LTRIM user_list 0 -1本意是想把列表裁剪到只剩第0个元素结果发现列表里的数据一条没少。他在群里问是不是Redis有bug。真实原因很简单LTRIM保留的是start到stop之间的元素而stop-1表示最后一个元素。0 -1的含义就是“从下标0到最后一个元素”相当于保留全部。如果只想保留第一个元素应该用LTRIM user_list 0 0。如果只想保留最后10个元素正确的写法是LTRIM user_list -10 -1。这类负下标的边界问题之所以容易踩是因为列表的下标语义和大多数编程语言里数组的slice不同Redis的负数下标必须先“从尾部算起”然后才执行保留逻辑中间不要做任何多余的“偏移想象”。遇到类似命令先拿一个小的测试key验证永远比你盯着语法猜测来得快。Redis的List就是这样一个结构看起来简单用起来顺手但一旦用错方向坑也很深。你不需要记住它的每一个命令但至少要清楚它的能力边界、它的底层原理、它在不同参数下的行为差异。下次面试官再问“Redis List的底层是什么”你能说出quicklist的设计动机、listpack和ziplist的区别、以及真实场景里怎么调优这比背出任何标准答案都更让人信服。
