1. 从高频面试题开始为什么Zset拥有两种底层实现如果你在搜索引擎里翻Redis相关的热词会发现“redis面试题”几乎是常年霸榜的存在而Zset的底层数据结构这道题在面试中的出场率绝对排得上前三。我第一次认真研究这个问题是在一次线上排行榜功能遇到性能瓶颈之后。那会儿我的第一反应是“Zset不就是个有序集合吗底层用跳表”结果一翻源码才发现事情远没有这么简单——Zset在数据量小的时候底层根本不是跳表而是一个叫做ziplist的精巧结构。只有数据规模涨上去之后它才会“切换”到跳表加哈希表的组合。这就引出了一个很有意思的问题Redis为什么要在Zset内部搞两套实现答案其实就藏在标题那八个字里——“ziplist与跳跃表双剑合璧”。简单说Redis在Zset的数据量较小、元素较短时使用ziplist来节省内存当数据量变大或者单个元素变长时再平滑地升级为skiplist加dict的组合兼顾查询效率和范围操作。这个设计既照顾了小数据场景下内存的极度敏感又保证了大流量场景下读写性能的稳定。这篇文章不打算只停留在“背结论”的层面。我会从数据结构的内存布局讲起把ziplist为什么省内存、跳表为什么快、dict又是来干什么的一层一层拆开讲清楚最后穿插一些我在实际业务里遇到过的坑和调优经验。无论你是准备面试、正在排查线上Redis内存告警还是单纯想把这几个经典数据结构彻底弄懂这篇内容应该都能帮上忙。注意文章中讨论的Redis行为基于主流的3.x到7.x版本。不同版本的阈值细节默认配置、命令差异等略有出入但核心设计思路是一脉相承的。2. ziplist小数据量下的内存极致压缩2.1 ziplist的内存布局没那么神秘很多人一听“ziplist”就觉得是个很高深的技巧实际上它的设计哲学特别朴素能用一块连续内存搞定的事就不要用指针跳来跳去。回想一下C语言里普通链表的结构每个节点都要存prev指针、next指针数据本身还得单独分配内存块光额外开销就能吃掉几十个字节。而ziplist把整个有序集合的所有元素塞进同一块连续内存里每个节点之间通过记录“前一个节点的长度”来替代指针通过“编码字段”来标识当前节点数据的类型和长度。从宏观看ziplist的内存布局可以简化为几个部分头部的zlbytes记录整个列表占用的总字节数、zltail偏移量用于快速定位到表尾、zllen节点数量超过65535后用遍历统计紧接着是若干个entry节点最后是一个zez结束标记。每个entry中有一个关键设计prevlen字段。它存储的是前一个entry的长度而它自身占用多大空间则取决于前一个entry的长度是否超过254字节。这个机制让你可以“从尾到头”反向遍历同时又不至于像传统双向链表那样每个节点都留下两个指针级的开销。2.2 为什么Zset选择ziplist存储有序数据Zset本质上是“有序的集合”而ziplist本身只是一张连续的entry表它怎么体现“有序”呢答案很简单插入的时候按score排好序直接插入到对应的位置。ziplist内部没有哈希索引、没有树它只保证了“在内存里节点就是有序排列的”这一件事。因为节点的物理顺序就是score的逻辑顺序所以做范围查询、按排名取元素这类操作只需要从头部或尾部线性扫描即可。这在数据量极小时是完美方案比如Zset里只有几十个元素每个member很短从头扫一遍也就几十次内存访问耗时可以忽略不计但内存占用却能达到传统链表结构的零头。我可以给个直观对比——一个存普通短字符串的Zset在ziplist模式下每个元素的额外开销甚至能控制在几个字节以内而如果用跳表加哈希表光每个高层节点的指针开销可能就要几十字节起步。所以内存敏感型业务里这个小结构的存在价值怎么强调都不为过。2.3 线性扫描的最大痛查询复杂度是O(N)ziplist不是没有代价的。它最致命的问题就是查找复杂度是O(N)。你要找到一个具体member对应的score只能从头开始一个节点一个节点比对member字符串你要插入一个新元素最坏情况下可能要把后面所有节点都往后挪动一段内存。内存紧凑是一把双刃剑它省空间但每次插入删除引发的内存搬运操作反而是它的软肋。随着Zset里元素数量增长这种线性开销会越来越肉眼可见。几十个元素没事几百个元素可能开始有感觉到几千个元素时每次插入都可能涉及后面几千个节点的顺移这时候不仅CPU时间涨上去了频繁的内存分配与释放也会加剧碎片化甚至影响Redis主线程的响应延迟。正因为这个原因Redis才必须设置一条“切换线”——数据量小时用ziplist享受内存红利数据量大了再切到跳表保住写入和查询的性能。3. 跳跃表与dict大数据量下的性能双保险3.1 查了源码才发现跳表其实是一种“多级链表”Zset在数据量超过阈值后会升级到我们更熟悉的结构skiplist跳跃表 dict哈希表。第一次看跳表源码时我的直观感受是这不就是好几层链表叠在一起吗这话对但只说对了一半。跳表本质上确实是多级链表但每一层都是有概率构建的索引层。最底层是包含所有节点的完整有序链表往上每一层的节点数都会按概率减少查询时从最高层开始“跳跃式”前进快速缩小搜索范围。为什么Redis选择跳表而不是红黑树或者B树等真正把源码看进去你就会明白跳表实现起来简单得多不需要复杂的旋转和变色调整而且它在范围查询上的天然优势非常大。Zset最核心的操作之一是“给我分数在[80, 90]之间的人”跳表只需要定位到下界节点然后沿着底层链表往后走就行这一天然支持区间的能力让它比哈希表、比树结构都更适合Zset的定位。3.2 dict在Zset里到底负责什么很多人容易忽略一个细节Zset升级后的结构里不只有跳表还有一个dict。这个dict的作用是维护member到score的映射关系。从Zset本身的定位来看我们需要两种查询能力一是按分数范围查询成员二是按成员查它的分数。跳表擅长前者但你在跳表里找一个具体的member还是得从头扫描虽然跳表查找可以加速但score相等的节点是排在一起的你要找的member不一定在哪。这时候配套的哈希表就派上用场了它就是一本“通讯录”输入member名直接O(1)找到对应score。这就形成了一种很经典的组合设计跳表维护顺序dict维护索引两者各自发挥长处共同支撑Zset的完整语义。如果你在源码里看zsetAdd函数会发现在插入新数据时它是同时往dict里放一条映射、往跳表里放一个节点的并且两个更新操作都在一个循环里完成一个失败整体回滚这就是原子性的底层保证。3.3 跳表的跨度计算与排名奥秘跳表里有个字段叫span翻译过来是“跨度”指的是当前节点在某一层到下一个节点的距离。它不直接存排名而是通过累加span可以获得一个元素的rank排名。Zset的ZRANK、ZREVRANK等命令能那么快返回排名就是因为在跳表查询时顺便把沿途的span加起来了。我还记得第一次看zslGetRank源码时就感叹一个“extra字段”能省下多少遍历成本。跳表的层数不是固定的每个新节点插入时会用“抛硬币”的方式随机决定它的层高上限是32层老的源码里是32有的版本配置成64。随机层高让跳表在概率意义上保持查询复杂度为O(log N)但实现上不需要像平衡树那样做严格的自平衡。理解这点之后你再看跳表的查询流程就会觉得非常自然从最高层出发如果下一个节点的score比目标小就向右移动否则向下移动反复如此直到最底层。4. 源码级别的关键逻辑zsetAdd如何抉择4.1 阈值切换的开关藏在哪里Zset在“用什么结构存储”这件事情上判断逻辑其实不复杂。在配置层面相关参数就两个zset-max-ziplist-entries默认128和zset-max-ziplist-value默认64。当Zset同时满足“元素数量少于等于128”和“所有元素的member长度都小于等于64字节”时用ziplist一旦任何一个条件被打破立刻整体升级为skiplistdict。这两个默认值是Redis团队在大量实际负载下打磨出来的平衡点128个以内的元素ziplist线性扫描的开销尚可接受64字节以内的member单个节点的长度适中内存紧凑优势最大。假如你的业务场景里member普遍很长那么哪怕你的Zset里只有10个元素只要有一个member超过64字节Redis就会直接切换到跳表。这一点很多人会记错以为“只要元素少就一定用ziplist”实际并非如此。4.2 zzlInsert与zslInsert的分工在源码里zsetAdd函数是整个Zset写入的第一道关卡。它先要根据编码方式判断当前Zset处于什么状态。如果当前是ziplist编码它会走zzlInsert分支在ziplist里查找member是否已存在如果存在则更新score如果不存在则找到合适的插入点再把新entry“塞”进去。同时它会随时检查ziplist的长度、新插入的member长度是否超过了阈值条件一旦超了就对整个Zset执行ziplist到skiplist的“结构升级”。升级过程本身是阻塞式的但Redis在为单个key做这种转换时耗时通常极短——毕竟数据量刚超过阈值时也不会太大。真正让我觉得设计巧妙的地方是这个转换方向是不可逆的。一旦ziplist升级成skiplist即使你后来删掉很多元素、让条件重新满足“元素少于128个”Redis也不会自动降级回ziplist。这个保守策略很好理解避免频繁转换带来的性能抖动。4.3 更新场景下的双重写与事务性再往深处看zsetAdd在维护dict和跳表时并不是先用跳表找到位置再更新dict这么简单。它其实会先借助dict快速判断key是否存在然后根据“存在/不存在”分别走两条路径一条是只更新score的路径另一条是新建节点的路径。不管是哪条路径最终都必须保证跳表和dict里的信息完全一致。我最开始看这个逻辑时有种“同时在两棵树上攀爬”的错觉但实际上代码把两件事分得非常清晰dict负责回答“你在不在”跳表负责回答“你在哪个位置”。在实际编码里更新score时redis需要先用dict获取旧score因为跳表是依据score排序的如果你直接改score而不先把旧节点删掉、再插入一次就会破坏跳表的有序性。所以源码中更新score的实际做法是先删除旧节点再按新score重新插入整个过程被精心排列以确保即使中间出错也不会留下脏数据。5. 业务实战从Redis内存分析到排行榜踩坑5.1 我如何判断线上某个Zset用了什么编码知道底层是两种结构之后在实际运维里最有用的操作就变成了一件小事检查一个key的编码方式。Redis提供了一个命令叫做OBJECT ENCODING key。我在排查线上内存问题时第一个动作就是这个。如果返回结果是ziplist说明这个有序集合还在“经济模式”如果返回结果是skiplist说明它已经切换到了“性能模式”。这个命令看起来不起眼但在监控Redis内存增长的定位中价值极高。有一次线上一个排行榜key膨胀得特别快我用OBJECT ENCODING一查早就已经是skiplist了。说明它的元素数量早就越过了128或者member长度超过了64字节。这背后往往对应着业务侧没有做数据清理或过期策略不合理。很多公司的Redis集群内存告警时都是从这种“大key”开始的而大key分析工具比如redis-rdb-tools也会直接读取Zset的编码信息帮助你定位哪些key占用了大头。5.2 redis.conf里调整阈值前的三个提醒如果你在redis.conf里搜zset-max-ziplist-entries和zset-max-ziplist-value会发现它们默认就摆在配置文件中。但我不建议你随意调大这两个阈值。原因有三点第一你把entries从128调到1000确实能让更多Zset停留在ziplist模式但ziplist的插入复杂度是O(N)当单个Zset涨到上千个元素时每次写入都可能是耗时的内存搬运这在主线程模型下会拉高整体延迟第二你把value从64调到128能多存一些较长的member但ziplist中单个节点内存变大之后链式更新的尾部开销也会上升内存碎片风险提高第三线上是long-running服务不建议用CONFIG SET动态调这两个参数来碰运气除非你有充分的压测数据。所以我的建议是先把业务侧的Zset规模梳理清楚再决定要不要调整阈值。大多数业务场景里128个元素不满足需求时直接升级到跳表反而是更优选择因为跳表的写入复杂度是O(log N)稳定性好得多。5.3 排行榜热key更新的真实案例之前接过一个需求运营要做“实时积分榜”每个用户分数变动时都要对Zset执行ZADD操作。最开始数据量不大一切都很快。等用户量涨到几十万榜单里热门的key开始频繁更新我注意到Redis的CPU使用率出现明显毛刺。用INFO COMMANDSTATS看了眼ZADD耗时涨幅最高。通过OBJECT ENCODING确认榜单key早就切到skiplist了那问题就成了“为什么skiplist也会慢”。后来排查发现罪魁祸首是大批量ZADD携带了多个member的批量写入而且member都是比较长的用户标识字符串超过64字节每次写入都要比较字符串、调整跳表指针加上同一时间大量并发ZADD主线程繁忙度飙升。我的优化方案之一是把某些非核心的积分变动做成异步合并批量写入方案之二是在业务层面拆分榜单把“全量榜”改成“日榜”“周榜”减少单个key的写入频率。最终CPU毛刺稳了下去。这个案例给我们的教训是底层数据结构是性能基础但业务侧的写入模型往往才是压垮主线程的最后一根稻草。6. 高频面试追问背后的设计哲学6.1 为什么阈值偏偏是128和64字节面试官喜欢追问“为什么是128”这个问题。说实话这个数字不是靠算法推导出来的而是权衡出来的经验值。Redis作者antirez在很早的版本中选择了这个配置组合目的是在“内存占用”和“CPU查询开销”之间取平衡。128个元素的线性扫描代价可能在微秒级别而跳表在128个节点规模下也体现不出太大优势。64字节的member上限则保证了单个节点整体长度可控内存碎片概率低。如果你去翻发布历史会发现早期版本里这两个参数也经历过调整最终稳定在这个默认值。理解这个演进过程比记住具体数字重要得多。面试官真正想考察的是你是否理解“不同数据结构在不同数据规模下各有优劣”这一工程设计思想。ziplist牺牲查询速度换取极致内存skiplist牺牲部分内存换取稳定性能两套结构切换的触发条件本质上就是存储引擎里常见的“阈值驱动的结构转换”模式。6.2 为什么Redis不直接用红黑树实现Zset这个问题也是面试常客。最常见的答案是因为跳表实现更简单但这只是表面。深一层看跳表在“范围查询”上天然比红黑树好用因为红黑树的中序遍历虽然也能有序输出但实现起来远不如跳表沿着底层链表“一路向右”来得直接。另外跳表支持O(log N)复杂度下的排名查询通过span累加红黑树要做到类似效果每个节点还得额外维护子树大小难度和复杂度都会显著上升。从并发角度讲Redis是单线程模型它不需要考虑多线程对同一跳表结构的加锁问题这让跳表的无锁化实现优势不那么明显。但即便如此跳表的局部性访问、缓存友好度也优于树结构因为查询路径上一层层的节点大多是顺序访问的。Redis团队实际选择了“跳表版本”并在生产环境里经历了多年的验证这个选择足以说明一切。6.3 两个容易在面试中翻车的细节第一个翻车点把Zset和Sorted Set并发的唯一索引混为一谈。Redis的Zset允许score相同也允许member重复插入时覆盖原值它不是唯一约束。跳表里score可以相同真正唯一的是member这是dict在维护的唯一性。如果面试时能把这个细节讲清楚会加分不少。第二个翻车点不知道Zset的zrangebyscore底层是“先定位下界再顺序扫描”。很多人以为范围查询也像单点查询一样层层跳跃但范围查询其实利用了底层链表的连续性一旦找到起点后面的遍历就是纯顺序操作。这也是跳表做排行榜最舒服的原因——你不用反复从根节点出发找范围起点直接从定位点“平推”即可。7. 我自己在源码阅读中的一点体会最后分享一点私人体会。我在读t_zset.c的过程中印象最深的不是那些复杂的指针操作而是Redis团队对“模块化”的坚持。ziplist和skiplist分别维护了一套独立的增删改查接口而zsetAdd这些业务层函数就像中间层负责判断当前状态、分派请求、协调两边逻辑。这种分层思想非常实用你在写自己的中间件或者业务代码时也可以参考把可替换的数据结构封装在策略层背后让上层逻辑只关心“有序集合”这个抽象概念而不是关心“现在底层是ziplist还是跳表”。另外多看看OBJECT ENCODING、MEMORY USAGE这些命令在真实key上的输出会让你对数据结构的内存开销有非常直观的感觉。我习惯了每次上线前都用小流量key先验证一遍自己的内存估算。技术文章读十遍不如自己亲手对线上key执行一次MEMORY USAGE来得真实。如果你最近在研究Redis源码建议顺着这条链子读下去先看ziplist的插入函数再看跳表的zslInsert然后回头读zsetAdd的入口逻辑最后把所有命令串起来。读完你会对“数据结构选型”这件事建立一种近乎本能的直觉。下次再有人问你Zset底层是什么你大概会像我一样先反问一句“你说的是哪种数据规模下的Zset”