第一站的观点是，基础数据类型。Redis 的“五官”

Redis 为什么快？怎么说呢，因为它不把数据当字节看。而是当数据结构看。这五种基础类型，就像你的五官，各司其职：

至于主线伏笔。

ZSET 是最复杂的，既要去重又要排序。为了同时满足这两点，Redis 在底层搞出了“两套班子”。也是我们今天的重头戏，怎么说呢，

👉 使用者痛点："在排行榜上频繁插入/删除导致延迟飙升怎么办？"

至于第二站，ZSET 的进化——“人少坐板凳。人多建高架”

如果你来实现 ZSET，你面临一个矛盾：

• 用数组排序快，但插入慢；说起来，用链表插入快，但查找慢。
• 如何兼顾两者？答案是动态切换战术，
• 说到使用者痛点。"一次性批量写入大量分数后查询变慢".
• 从方法来看，根据元素数量自动切换结构。
• **人少** 用 “listpack” 模式——长板凳；**人多** 用 “跳表 + 字典” 模式——立交桥 + GPS。不过，
• 主要是 **渐进式升级**。不需要停机，

人少时的 Listpack 长板凳模式

大家紧挨着坐在一条长板凳上，按分数从小到大排好。虽然新增一个人需要挪动后面的人，但反正人少，挪动代价极低。关键是这张“长板凳”极度节省内存，没有任何指针开销。

+--------+--------+--------+--------+--------+
| 总分數 | 元素数 | "小明" | "小红" | END |
| | | + | + |
+--------+--------+--------+--------+--------+
每个小块只记录自己的长度。互不影响

为什么现在的 Redis 用 listpack，而不用以前的 ziplist？

• #1 Ziplist 像“多米诺骨牌”。中间插一个人，后面的骨牌全得动。#1.

  
  `
  

  `

  • #2 Listpack 改成了 “各自独立”。改自己不影响邻居，彻底消除了这个隐患。按理说，#2. ` `
    🔑 **使用者痛点**：“在大规模排行中频繁插入导致整体性能下降”。解决办法是让 ZSET 自动切换到 **跳表 + 字典** 模式。# 小结：ZSET 的双模式让你既能享受低内存使用，又能保持 O 查询速度。按理说，💡 对业务而言，只需关心业务逻辑，不必担心内部实现细节。💬 **面对面试官提问：“ZSET 为什么会出现性能瓶颈？至于”时可以回答，`ZSET 在元素很少时使用 listpack 极度压缩内存；当元素超过阈值后它会无缝升级为跳表 + 字典组合，以保证查询和插入均保持对数级别性能。`

    从第三站来看，跳表的秘密——抽奖抽出来的“高速电梯”

    *什么是跳表？* 想象一条普通地铁线，每隔一定比例随机给站点加装直达电梯，从而加速乘客到达目的地。差不多，跳表在百万级数据下保持几乎秒级查询时间的根本原因。 L0→L1→L2→L3←NULL L0 → → → ← NULL L1 ← → ← NULL L2 ← ← NULL L3 ← NULL

    • *优点*: 随机提高减少平均搜索步数；实现简单，无锁并行友好。
    - *缺点*: 随机性导致 worst-case O，但概率极低。`