【Redis进阶】Redis数据结构

不念不忘少年蓝@ 2024-03-24 13:20 69阅读 0赞

#### 文章目录 ####

*  1. 前言
 *  2. SDS
 *  2. 链表
 *  3. 压缩链表
 *  4. 哈希表
 *  5. 整数集合
 *  6. 跳表
 *  7. quicklist
 *  8. listpack

## 1. 前言 ##

Redis常用的数据结构为String，List，Hash，Set，Sorted Set。但这只是我们在用的时候键值对的表现形式，他们底层真正使用的数据结构为简单动态字符串，双向链表，压缩列表，哈希表，跳表和整数数组

![image-20230401155036229][]

Redis 数据类型的底层数据结构随着版本的更新也有所不同，比如：

*  在 Redis 3.0 版本中 List 对象的底层数据结构由「双向链表」或「压缩表列表」实现，但是在 3.2 版本之后，List 数据类型底层数据结构是由 quicklist 实现的；
 *  在最新的 Redis 代码（还未发布正式版本）中，压缩列表数据结构已经废弃了，交由 listpack 数据结构来实现了。

![image-20230401155053396][]

--------------------

## 2. SDS ##

SDS（Simple Dynamic String）是Redis中的一种动态字符串实现，它的结构设计如下图所示：

![img][]

结构中的每个成员变量分别介绍下：

*  **len，记录了字符串长度**。这样获取字符串长度的时候，只需要返回这个成员变量值就行，时间复杂度只需要 O（1）。
 *  **alloc，分配给字符数组的空间长度**。这样在修改字符串的时候，可以通过 `alloc - len` 计算出剩余的空间大小，可以用来判断空间是否满足修改需求，如果不满足的话，就会自动将 SDS 的空间扩展至执行修改所需的大小，然后才执行实际的修改操作，所以使用 SDS 既不需要手动修改 SDS 的空间大小，也不会出现前面所说的缓冲区溢出的问题。
 *  **flags，用来表示不同类型的 SDS**。一共设计了 5 种类型，分别是 sdshdr5、sdshdr8、sdshdr16、sdshdr32 和 sdshdr64，后面在说明区别之处。
 *  **buf\[\]，字符数组，用来保存实际数据**。不仅可以保存字符串，也可以保存二进制数据。

> ***那么使用，C语言的char数组会有什么缺陷呢？***

**相对于SDS，C语言字符串存在以下缺点：**

1.  **不支持动态增长**：C语言中的字符串必须在定义时就指定其最大长度，如果需要存储更多的字符，则必须重新分配内存。这样会导致一些额外的开销，比如需要频繁调用realloc函数来重新分配内存。
2.  **容易出错**：**C语言中的字符串没有内置的长度信息**，因此在进行字符串操作时经常会导致内存越界等错误。例如，如果访问了字符串末尾之外的内存，程序就会崩溃或者产生未知的结果。
3.  **无法处理二进制数据**：C语言中的字符串是以`\0`终止的，因此不能用于存储任意的二进制数据。这意味着，如果想要在字符串中保存二进制数据，可能需要手动转换数据类型或使用其他方式来解决。
4.  **性能问题**：由于C语言中的字符串是以`\0`终止的，因此在获取字符串长度时需要遍历整个字符串。这种操作很耗费时间，因此在处理大量字符串时可能会影响性能（时间复杂度为O(N)）。
5.  **难以维护**：由于C语言中的字符串操作需要手动管理内存，因此代码会变得更加复杂和难以维护。而且，当程序员忘记释放内存时，可能会导致内存泄漏等问题。

**SDS相对于C语言中的字符串，它有以下优点**

1.  **O（1）复杂度获取字符串长度**，而 Redis 的 SDS 结构因为加入了 len 成员变量，那么**获取字符串长度的时候，直接返回这个成员变量的值就行，所以复杂度只有 O（1）**。
2.  **二进制安全**， SDS 不需要用 “\\0” 字符来标识字符串结尾了，而是**有个专门的 len 成员变量来记录长度，所以可存储包含 “\\0” 的数据**。但是 SDS 为了兼容部分 C 语言标准库的函数， SDS 字符串结尾还是会加上 “\\0” 字符。 **SDS 的 API 都是以处理二进制的方式来处理 SDS 存放在 buf\[\] 里的数据**，使得 Redis 不仅可以保存文本数据，也可以保存任意格式的二进制数据。
3.  **不会发生缓冲区溢出**，Redis 的 SDS 结构里引入了 alloc 和 len 成员变量，这样 SDS API 通过 `alloc - len` 计算，可以算出剩余可用的空间大小，这样在对字符串做修改操作的时候，就可以由程序内部判断缓冲区大小是否足够用。**当判断出缓冲区大小不够用时，Redis 会自动将扩大 SDS 的空间大小**，以满足修改所需的大小。因此，使用 SDS 即不需要手动修改 SDS 的空间大小，也不会出现缓冲区溢出的问题。
    
     *  如果所需的 sds 长度**小于 1 MB**，那么最后的扩容是按照**翻倍扩容**来执行的，即 2 倍的newlen
     *  如果所需的 sds 长度**超过 1 MB**，那么最后的扩容长度应该是 newlen **+ 1MB**。
     *  如果 SDS 空间够的话，API 就会直接使用「未使用空间」，而无须执行内存分配，**有效的减少内存分配次数**。
     *      hisds hi_sdsMakeRoomFor(hisds s, size_t addlen)
            {
                ... ...
                // s目前的剩余空间已足够，无需扩展，直接返回
                if (avail >= addlen)
                    return s;
                //获取目前s的长度
                len = hi_sdslen(s);
                sh = (char *)s - hi_sdsHdrSize(oldtype);
                //扩展之后 s 至少需要的长度
                newlen = (len + addlen);
                //根据新长度，为s分配新空间所需要的大小
                if (newlen < HI_SDS_MAX_PREALLOC)
                    //新长度<HI_SDS_MAX_PREALLOC 则分配所需空间*2的空间
                    newlen *= 2;
                else
                    //否则，分配长度为目前长度+1MB
                    newlen += HI_SDS_MAX_PREALLOC;
                   ...
            }
4.  **节省内存**，SDS 结构中有个 flags 成员变量，表示的是 SDS 类型。Redis 一共设计了 5 种类型，分别是 sdshdr5、sdshdr8、sdshdr16、sdshdr32 和 sdshdr64。这 5 种类型的主要**区别就在于，它们数据结构中的 len 和 alloc 成员变量的数据类型不同**。
    
    1.  **之所以 SDS 设计不同类型的结构体，是为了能灵活保存不同大小的字符串，从而有效节省内存空间**。比如，在保存小字符串时，结构头占用空间也比较少。

--------------------

## 2. 链表 ##

Redis中使用的链表是双向链表，每个节点由三个指针组成，**分别指向前驱节点、后继节点和存储数据的值**。Redis的链表实现定义在adlist.h文件中，其中定义了list结构体和listNode结构体。

typedef struct list {
        
        //链表头节点
        listNode *head;
        //链表尾节点
        listNode *tail;
        //节点值复制函数
        void *(*dup)(void *ptr);
        //节点值释放函数
        void (*free)(void *ptr);
        //节点值比较函数
        int (*match)(void *ptr, void *key);
        //链表节点数量
        unsigned long len;
    } list;

![image-20230401202707691][]

**Redis使用链表作为实现数据结构的一种方式，其优点如下：**

1.  **快速插入和删除**：链表结构在插入和删除操作上具有很好的优势。Redis将键值对存储在链表中，可以方便地进行插入和删除操作，而不需要像数组那样进行元素移动，因此在这些操作上比较快。
2.  **灵活性**：链表结构非常灵活，并且可以轻松地扩展。这意味着可以根据需要增加节点或缩减节点，以及在链表中重新排序元素等。
3.  **节省内存**：当需要存储大量元素时，链表结构比数组结构更加节省内存。因为链表只是存储每个节点的地址，而不是整个元素本身。因此，对于包含许多小元素的情况，链表可能比数组更适合。
4.  listNode 链表节点的结构里带有 prev 和 next 指针，**获取某个节点的前置节点或后置节点的时间复杂度只需O(1)，而且这两个指针都可以指向 NULL，所以链表是无环链表**；
5.  list 结构因为提供了链表节点数量 len，所以**获取链表中的节点数量的时间复杂度只需O(1)**；
6.  listNode 链表节使用 void\* 指针保存节点值，并且可以通过 list 结构的 dup、free、match 函数指针为节点设置该节点类型特定的函数，因此**链表节点可以保存各种不同类型的值**；

**链表的缺陷也是有的：**

1.  链表每个节点之间的内存都是不连续的，意味着**无法很好利用 CPU 缓存**。能很好利用 CPU 缓存的数据结构就是数组，因为数组的内存是连续的，这样就可以充分利用 CPU 缓存来加速访问。
2.  还有一点，保存一个链表节点的值都需要一个链表节点结构头的分配，**内存开销较大**。

--------------------

## 3. 压缩链表 ##

Redis中的压缩链表（ziplist）是一种特殊的数据结构，它是一种紧凑存储多个元素的方式，**通常用于实现列表、哈希表等数据类型**。与普通链表不同，压缩链表把所有节点都存储在一段连续的内存区域中，**这样可以提高随机访问的速度，并且减少了节点指针的开销。**

![image-20230401205514710][]

***压缩列表在表头有三个字段：***

*  ***zlbytes***，记录整个压缩列表占用对内存字节数；
 *  ***zltail***，记录压缩列表「尾部」节点距离起始地址由多少字节，也就是列表尾的偏移量；
 *  ***zllen***，记录压缩列表包含的节点数量；
 *  ***zlend***，标记压缩列表的结束点，固定值 0xFF（十进制255）。

在压缩列表中，如果我们要查找定位第一个元素和最后一个元素，可以通过表头三个字段（zllen）的长度直接定位，复杂度是 O(1)。而**查找其他元素时，就没有这么高效了，只能逐个查找，此时的复杂度就是 O(N) 了，因此压缩列表不适合保存过多的元素**

![image-20230401205633180][]

压缩列表节点包含三部分内容：

*  ***prevlen***，记录了「前一个节点」的长度，目的是为了实现从后向前遍历；
 *  ***encoding***，记录了当前节点实际数据的「类型和长度」，类型主要有两种：字符串和整数。
 *  ***data***，记录了当前节点的实际数据，类型和长度都由 `encoding` 决定；

当往压缩列表中插入数据时，压缩列表就会根据数据类型是字符串还是整数，以及数据的大小，会使用不同空间大小的 prevlen 和 encoding 这两个元素里保存的信息，**这种根据数据大小和类型进行不同的空间大小分配的设计思想，正是 Redis 为了节省内存而采用的**。

> 如果**前一个节点的长度小于 254 字节**，那么 prevlen 属性需要用 **1 字节的空间**来保存这个长度值；
> 
> 如果**前一个节点的长度大于等于 254 字节**，那么 prevlen 属性需要用 **5 字节的空间**来保存这个长度值；

*  如果**当前节点的数据是整数**，则 encoding 会使用 **1 字节的空间**进行编码，也就是 encoding 长度为 1 字节。通过 encoding 确认了整数类型，就可以确认整数数据的实际大小了，比如如果 encoding 编码确认了数据是 int16 整数，那么 data 的长度就是 int16 的大小。
 *  如果**当前节点的数据是字符串，根据字符串的长度大小**，encoding 会使用 **1 字节/2字节/5字节的空间**进行编码，encoding 编码的前两个 bit 表示数据的类型，后续的其他 bit 标识字符串数据的实际长度，即 data 的长度。

**在对压缩链表进行操作时，有时需要对多个元素进行同时修改，这就需要使用到连锁更新。**

所谓连锁更新，就是当压缩列表新增某个元素或修改某个元素时，**如果空间不不够，压缩列表占用的内存空间就需要重新分配。而当新插入的元素较大时，可能会导致后续元素的 prevlen 占用空间都发生变化，从而引起「连锁更新」问题**，导致每个元素的空间都要重新分配，造成访问压缩列表性能的下降。

***压缩列表具有以下优点：***

1.  **存储效率高**：由于将多个相邻的小元素合并为一个较大的元素，因此压缩列表可以大幅减小存储空间，在存储大量小元素时尤其突出。
2.  **数据连续性好**：由于多个小元素被合并为一个较大的元素，因此在物理上也使得相邻的元素更有可能被存储在相邻的内存位置上，这对于 CPU 缓存命中率等方面都有一定的优势。

***同时，压缩列表也有以下缺点：***

1.  **虽然压缩列表紧凑型的内存布局能节省内存开销，但是如果保存的元素数量增加或者删除了，或是元素变大了，会导致内存重新分配，最糟糕的是会有「连锁更新」的问题**。
2.  **压缩列表只会用于保存的节点数量不多的场景**，只要节点数量足够小，即使发生连锁更新，也是能接受的。

--------------------

## 4. 哈希表 ##

Redis的哈希表是一种常用的数据结构，**用于存储键值对**。在Redis中，哈希表可以用于实现类似字典或者对象的数据结构。

Redis的哈希表由一个数组和若干个键值对组成。**其中，数组用于存储哈希表的桶(bucket)**，每个桶可以存储多个键值对。键值对则由一个key和一个value组成，并被存储在桶中。具体来说，**Redis使用链式哈希表实现，即每个桶是一个单向链表，其中每个节点包含一个键值对。**

Redis 的哈希表结构如下：

typedef struct dictht {
        
        //哈希表数组
        dictEntry **table;
        //哈希表大小
        unsigned long size;  
        //哈希表大小掩码，用于计算索引值
        unsigned long sizemask;
        //该哈希表已有的节点数量
        unsigned long used;
    } dictht;

![image-20230401212752381][]

在实际使用哈希表时，Redis 定义一个 dict 结构体，这个结构体里定义了**两个哈希表（ht\[2\]）**。

typedef struct dict {
        
        …
        //两个Hash表，交替使用，用于rehash操作
        dictht ht[2]; 
        …
    } dict;

![image-20230401213320913][]

哈希表节点的结构如下：

typedef struct dictEntry {
        
        //键值对中的键
        void *key;
      
        //键值对中的值
        union {
        
            void *val;
            uint64_t u64;
            int64_t s64;
            double d;
        } v;
        //指向下一个哈希表节点，形成链表
        struct dictEntry *next;
    } dictEntry;

dictEntry 结构里不仅包含指向键和值的指针，还包含了指向下一个哈希表节点的指针，这个指针可以将多个哈希值相同的键值对链接起来，以此来解决哈希冲突的问题，这就是链式哈希。

dictEntry 结构里键值对中的值是一个「联合体 v」定义的，因此，键值对中的值可以是一个指向实际值的指针，或者是一个无符号的 64 位整数或有符号的 64 位整数或double 类的值。这么做的好处是可以节省内存空间，因为当「值」是整数或浮点数时，就可以将值的数据内嵌在 dictEntry 结构里，无需再用一个指针指向实际的值，从而节省了内存空间

***redis 解决哈希冲突的方式是 链式哈希，依次用指针链接***

![image-20230401212947692][]

链式哈希局限性也很明显，随着链表长度的增加，在查询这一位置上的数据的耗时就会增加，毕竟链表的查询的时间复杂度是 O(n)。

***要想解决这一问题，就需要进行 rehash，也就是对哈希表的大小进行扩展。***

在正常服务请求阶段，插入的数据，都会写入到「哈希表 1」，此时的「哈希表 2 」 并没有被分配空间。

随着数据逐步增多，触发了 rehash 操作，这个过程分为三步：

*  给「哈希表 2」 分配空间，一般会比「哈希表 1」 大 2 倍；
 *  将「哈希表 1 」的数据迁移到「哈希表 2」 中；
 *  迁移完成后，「哈希表 1 」的空间会被释放，并把「哈希表 2」 设置为「哈希表 1」，然后在「哈希表 2」 新创建一个空白的哈希表，为下次 rehash 做准备。

![image-20230401213354498][]

**但是如果「哈希表 1 」的数据量非常大，那么在迁移至「哈希表 2 」的时候，因为会涉及大量的数据拷贝，此时可能会对 Redis 造成阻塞，无法服务其他请求**。

为了避免 rehash 在数据迁移过程中，因拷贝数据的耗时，影响 Redis 性能的情况，所以 Redis 采用了**渐进式 rehash**，也就是将数据的迁移的工作不再是一次性迁移完成，而是分多次迁移。

渐进式 rehash 步骤如下：

*  给「哈希表 2」 分配空间；
 *  **在 rehash 进行期间，每次哈希表元素进行新增、删除、查找或者更新操作时，Redis 除了会执行对应的操作之外，还会顺序将「哈希表 1 」中索引位置上的所有 key-value 迁移到「哈希表 2」 上**；
 *  随着处理客户端发起的哈希表操作请求数量越多，最终在某个时间点会把「哈希表 1 」的所有 key-value 迁移到「哈希表 2」，从而完成 rehash 操作。

这样就巧妙地把一次性大量数据迁移工作的开销，分摊到了多次处理请求的过程中，避免了一次性 rehash 的耗时操作。

在进行渐进式 rehash 的过程中，会有两个哈希表，**所以在渐进式 rehash 进行期间，哈希表元素的删除、查找、更新等操作都会在这两个哈希表进行。**

比如，查找一个 key 的值的话，先会在「哈希表 1」 里面进行查找，如果没找到，就会继续到哈希表 2 里面进行找到。

另外，在渐进式 rehash 进行期间，新增一个 key-value 时，会被保存到「哈希表 2 」里面，而「哈希表 1」 则不再进行任何添加操作，这样保证了「哈希表 1 」的 key-value 数量只会减少，随着 rehash 操作的完成，最终「哈希表 1 」就会变成空表。

> ***那么，rehash什么时候触发呢？***
> 
> rehash 的触发条件跟\*\*负载因子（load factor）\*\*有关系。
> 
> 负载因子可以通过下面这个公式计算：
> 
> ![img][img 1]
> 
> 触发 rehash 操作的条件，主要有两个：
> 
>  *  **当负载因子大于等于 1 ，并且 Redis 没有在执行 bgsave 命令或者 bgrewiteaof 命令，也就是没有执行 RDB 快照或没有进行 AOF 重写的时候，就会进行 rehash 操作。**
>  *  **当负载因子大于等于 5 时，此时说明哈希冲突非常严重了，不管有没有有在执行 RDB 快照或 AOF 重写，都会强制进行 rehash 操作。**

--------------------

## 5. 整数集合 ##

Redis的整数集合（intset）是一种特殊的数据结构，用于存储整数值。它被设计成非常紧凑和高效，可以在占用很少空间的情况下处理大量整数。

typedef struct intset {
        
        //编码方式
        uint32_t encoding;
        //集合包含的元素数量
        uint32_t length;
        //保存元素的数组
        int8_t contents[];
    } intset;

可以看到，保存元素的容器是一个 contents 数组，虽然 contents 被声明为 int8\_t 类型的数组，**但是实际上 contents 数组并不保存任何 int8\_t 类型的元素，contents 数组的真正类型取决于 intset 结构体里的 encoding 属性的值**。

*  如果 encoding 属性值为 INTSET\_ENC\_INT16，那么 contents 就是一个 int16\_t 类型的数组，数组中每一个元素的类型都是 int16\_t；
 *  如果 encoding 属性值为 INTSET\_ENC\_INT32，那么 contents 就是一个 int32\_t 类型的数组，数组中每一个元素的类型都是 int32\_t；
 *  如果 encoding 属性值为 INTSET\_ENC\_INT64，那么 contents 就是一个 int64\_t 类型的数组，数组中每一个元素的类型都是 int64\_t；

整数集合会有一个升级规则，就是当我们将一个新元素加入到整数集合里面，**如果新元素的类型（int32\_t）比整数集合现有所有元素的类型（int16\_t）都要长时，整数集合需要先进行升级，也就是按新元素的类型（int32\_t）扩展 contents 数组的空间大小，然后才能将新元素加入到整数集合里**，当然升级的过程中，也要维持整数集合的有序性。

整数集合升级的过程不会重新分配一个新类型的数组，而是在原本的数组上扩展空间，然后在将每个元素按间隔类型大小分割，如果 encoding 属性值为 INTSET\_ENC\_INT16，则每个元素的间隔就是 16 位。

![image-20230401222206707][]

> 整数集合升级有什么好处呢？

如果要让一个数组同时保存 int16\_t、int32\_t、int64\_t 类型的元素，最简单做法就是直接使用 int64\_t 类型的数组。不过这样的话，当如果元素都是 int16\_t 类型的，就会造成内存浪费的情况。

整数集合升级就能避免这种情况，如果一直向整数集合添加 int16\_t 类型的元素，那么整数集合的底层实现就一直是用 int16\_t 类型的数组，只有在我们要将 int32\_t 类型或 int64\_t 类型的元素添加到集合时，才会对数组进行升级操作。

因此，整数集合升级的好处是**节省内存资源**。

> 整数集合支持降级操作吗？

**不支持降级操作**，一旦对数组进行了升级，就会一直保持升级后的状态。比如前面的升级操作的例子，如果删除了 65535 元素，整数集合的数组还是 int32\_t 类型的，并不会因此降级为 int16\_t 类型。

--------------------

## 6. 跳表 ##

**Redis的跳表是一种有序数据结构，用于实现有序集合（Sorted Set）**。它可以提供快速的插入、删除和查找操作，而不需要像红黑树或平衡二叉树那样复杂。

跳表的基本思想是在链表的基础上增加多级索引，通过索引快速定位元素。每个节点都有多个指针，其中一些指向下一层的节点，另一些指向同一层的其他节点。这种结构类似于一张地图中的高速公路系统，每个交叉口都有多条道路，使得车辆可以通过多条不同的路径到达目的地。

**Redis的跳表是一种随机化数据结构，它使用随机函数来决定节点层数，从而确保插入、删除和查找操作的时间复杂度均为O(log n)**。此外，跳表还具有良好的局部性，因为跨度较长的节点只有在查询非常靠近结束时才需要被扫描，从而减少了访问内存的次数。

typedef struct zset {
        
        dict *dict;
        zskiplist *zsl;
    } zset;

Zset 对象在使用跳表作为数据结构的时候，是使用由「哈希表+跳表」组成的 struct zset，但是我们讨论的时候，都会说跳表是 Zset 对象的底层数据结构，而不会提及哈希表，是因为 struct zset 中的哈希表只是用于以常数复杂度获取元素权重，大部分操作都是跳表实现的。

链表在查找元素的时候，因为需要逐一查找，所以查询效率非常低，时间复杂度是O(N)，于是就出现了跳表。**跳表是在链表基础上改进过来的，实现了一种「多层」的有序链表**，这样的好处是能快读定位数据。

![image-20230401224758750][]

图中头节点有 L0~L2 三个头指针，分别指向了不同层级的节点，然后每个层级的节点都通过指针连接起来：

*  L0 层级共有 5 个节点，分别是节点1、2、3、4、5；
 *  L1 层级共有 3 个节点，分别是节点 2、3、5；
 *  L2 层级只有 1 个节点，也就是节点 3 。

如果我们要在链表中查找节点 4 这个元素，只能从头开始遍历链表，需要查找 4 次，而使用了跳表后，只需要查找 2 次就能定位到节点 4，因为可以在头节点直接从 L2 层级跳到节点 3，然后再往前遍历找到节点 4。

可以看到，这个查找过程就是在多个层级上跳来跳去，最后定位到元素。当数据量很大时，跳表的查找复杂度就是 O(logN)。

***「跳表节点」的数据结构了，如下：***

typedef struct zskiplistNode {
        
        //Zset 对象的元素值
        sds ele;
        //元素权重值
        double score;
        //后向指针
        struct zskiplistNode *backward;
      
        //节点的level数组，保存每层上的前向指针和跨度
        struct zskiplistLevel {
        
            struct zskiplistNode *forward;
            unsigned long span;
        } level[];
    } zskiplistNode;

\*\*Zset 对象要同时保存「元素」和「元素的权重」，对应到跳表节点结构里就是 sds 类型的 ele 变量和 double 类型的 score 变量。\*\*每个跳表节点都有一个后向指针（struct zskiplistNode \*backward），指向前一个节点，目的是为了方便从跳表的尾节点开始访问节点，这样倒序查找时很方便。

跳表是一个带有层级关系的链表，而且每一层级可以包含多个节点，每一个节点通过指针连接起来，实现这一特性就是靠跳表节点结构体中的**zskiplistLevel 结构体类型的 level 数组**。

level 数组中的每一个元素代表跳表的一层，也就是由 zskiplistLevel 结构体表示，比如 leve\[0\] 就表示第一层，leve\[1\] 就表示第二层。**zskiplistLevel 结构体里定义了「指向下一个跳表节点的指针」和「跨度」**，**跨度是用来记录两个节点之间的距离。**

![image-20230402114902669][]

**跨度实际上是为了计算这个节点在跳表中的排位**。具体怎么做的呢？因为跳表中的节点都是按序排列的，那么计算某个节点排位的时候，从头节点点到该结点的查询路径上，将沿途访问过的所有层的跨度累加起来，得到的结果就是目标节点在跳表中的排位。

举个例子，查找图中节点 3 在跳表中的排位，从头节点开始查找节点 3，查找的过程只经过了一个层（L2），并且层的跨度是 3，所以节点 3 在跳表中的排位是 3。

另外，图中的头节点其实也是 zskiplistNode 跳表节点，只不过头节点的后向指针、权重、元素值都没有用到，所以图中省略了这部分。

问题来了，由谁定义哪个跳表节点是头节点呢？这就介绍「跳表」结构体了，如下所示

typedef struct zskiplist {
        
        struct zskiplistNode *header, *tail;
        unsigned long length;
        int level;
    } zskiplist;

跳表结构里包含了：

*  跳表的头尾节点，便于在O(1)时间复杂度内访问跳表的头节点和尾节点；
 *  跳表的长度，便于在O(1)时间复杂度获取跳表节点的数量；
 *  跳表的最大层数，便于在O(1)时间复杂度获取跳表中层高最大的那个节点的层数量；

> ***那么，跳表节点查询的过程是怎么个流程呢？***

查找一个跳表节点的过程时，跳表会从头节点的最高层开始，逐一遍历每一层。在遍历某一层的跳表节点时，**会用跳表节点中的 SDS 类型的元素和元素的权重来进行判断**，共有两个判断条件：

*  如果当前节点的权重\*\*「小于」\*\*要查找的权重时，跳表就会访问该层上的下一个节点。
 *  如果当前节点的权重\*\*「等于」\*\*要查找的权重时，并且当前节点的 SDS 类型数据「小于」要查找的数据时，跳表就会访问该层上的下一个节点。

如果上面两个条件都不满足，或者下一个节点为空时，跳表就会使用目前遍历到的节点的 level 数组里的下一层指针，然后沿着下一层指针继续查找，这就相当于跳到了下一层接着查找。

![image-20230402115721993][]

如果要查找「元素：abcd，权重：4」的节点，查找的过程是这样的：

*  先从头节点的最高层开始，L2 指向了「元素：abc，权重：3」节点，这个节点的权重比要查找节点的小，所以要访问该层上的下一个节点；
 *  但是该层的下一个节点是空节点（ leve\[2\]指向的是空节点），于是就会跳到「元素：abc，权重：3」节点的下一层去找，也就是 leve\[1\];
 *  「元素：abc，权重：3」节点的 leve\[1\] 的下一个指针指向了「元素：abcde，权重：4」的节点，然后将其和要查找的节点比较。虽然「元素：abcde，权重：4」的节点的权重和要查找的权重相同，但是当前节点的 SDS 类型数据「大于」要查找的数据，所以会继续跳到「元素：abc，权重：3」节点的下一层去找，也就是 leve\[0\]；
 *  「元素：abc，权重：3」节点的 leve\[0\] 的下一个指针指向了「元素：abcd，权重：4」的节点，该节点正是要查找的节点，查询结束。

> ***通过上面的例子，可以知道跳表的相邻两层的节点数量的比例会影响跳表的查询性能。***
> 
> ***那么，跳表层数该如何设计呢？***

**跳表的相邻两层的节点数量最理想的比例是 2:1，查找复杂度可以降低到 O(logN)**。

下图的跳表就是，相邻两层的节点数量的比例是 2 : 1。

![image-20230402122243078][]

> ***那怎样才能维持相邻两层的节点数量的比例为 2 : 1 呢？***

如果采用新增节点或者删除节点时，来调整跳表节点以维持比例的方法的话，会带来额外的开销。

Redis 则采用一种巧妙的方法是，**跳表在创建节点的时候，随机生成每个节点的层数**，并没有严格维持相邻两层的节点数量比例为 2 : 1 的情况。

具体的做法是，**跳表在创建节点时候，会生成范围为\[0-1\]的一个随机数，如果这个随机数小于 0.25（相当于概率 25%），那么层数就增加 1 层，然后继续生成下一个随机数，直到随机数的结果大于 0.25 结束，最终确定该节点的层数**。

这样的做法，相当于每增加一层的概率不超过 25%，层数越高，概率越低，层高最大限制是 64。

图中的跳表的「头节点」都是 3 层高，但是其实**如果层高最大限制是 64，那么在创建跳表「头节点」的时候，就会直接创建 64 层高的头节点**。

如下代码，创建跳表时，头节点的 level 数组有 ZSKIPLIST\_MAXLEVEL个元素（层），节点不存储任何 member 和 score 值，level 数组元素的 forward 都指向NULL， span值都为0。

/* Create a new skiplist. */
    zskiplist *zslCreate(void) {
        
        int j;
        zskiplist *zsl;
    
        zsl = zmalloc(sizeof(*zsl));
        zsl->level = 1;
        zsl->length = 0;
        zsl->header = zslCreateNode(ZSKIPLIST_MAXLEVEL,0,NULL);
        for (j = 0; j < ZSKIPLIST_MAXLEVEL; j++) {
        
            zsl->header->level[j].forward = NULL;
            zsl->header->level[j].span = 0;
        }
        zsl->header->backward = NULL;
        zsl->tail = NULL;
        return zsl;
    }

其中，ZSKIPLIST\_MAXLEVEL 定义的是最高的层数，Redis 7.0 定义为 32，Redis 5.0 定义为 64，Redis 3.0 定义为 32。

> **那么，为什么用跳表而不用平衡树呢？**

从内存占用、对范围查找的支持、实现难易程度这三方面：

*  **从内存占用上来比较，跳表比平衡树更灵活一些**。平衡树每个节点包含 2 个指针（分别指向左右子树），而跳表每个节点包含的指针数目平均为 1/(1-p)，具体取决于参数 p 的大小。如果像 Redis里的实现一样，取 p=1/4，那么平均每个节点包含 1.33 个指针，比平衡树更有优势。
 *  **在做范围查找的时候，跳表比平衡树操作要简单**。在平衡树上，我们找到指定范围的小值之后，还需要以中序遍历的顺序继续寻找其它不超过大值的节点。如果不对平衡树进行一定的改造，这里的中序遍历并不容易实现。而在跳表上进行范围查找就非常简单，只需要在找到小值之后，对第 1 层链表进行若干步的遍历就可以实现。
 *  **从算法实现难度上来比较，跳表比平衡树要简单得多**。平衡树的插入和删除操作可能引发子树的调整，逻辑复杂，而跳表的插入和删除只需要修改相邻节点的指针，操作简单又快速。

--------------------

## 7. quicklist ##

Quicklist是Redis中一种特殊的数据结构，它既具有链表的灵活性，又具有数组的高效性，**是一种将链表和数组结合起来的数据结构**。

在 Redis 3.0 之前，List 对象的底层数据结构是双向链表或者压缩列表。然后在 Redis 3.2 的时候，List 对象的底层改由 quicklist 数据结构实现。**quicklist 通过控制每个链表节点中的压缩列表的大小或者元素个数，来规避连锁更新的问题。因为压缩列表元素越少或越小，连锁更新带来的影响就越小，从而提供了更好的访问性能。**

quicklist 的结构体跟链表的结构体类似，都包含了表头和表尾，区别在于 quicklist 的节点是 quicklistNode。

typedef struct quicklist {
        
        //quicklist的链表头
        quicklistNode *head;      //quicklist的链表头
        //quicklist的链表尾
        quicklistNode *tail; 
        //所有压缩列表中的总元素个数
        unsigned long count;
        //quicklistNodes的个数
        unsigned long len;       
        ...
    } quicklist;

quicklistNode 的结构定义：

typedef struct quicklistNode {
        
        //前一个quicklistNode
        struct quicklistNode *prev;     //前一个quicklistNode
        //下一个quicklistNode
        struct quicklistNode *next;     //后一个quicklistNode
        //quicklistNode指向的压缩列表
        unsigned char *zl;              
        //压缩列表的的字节大小
        unsigned int sz;                
        //压缩列表的元素个数
        unsigned int count : 16;        //ziplist中的元素个数 
        ....
    } quicklistNode;

quicklistNode 结构体里包含了前一个节点和下一个节点指针，这样每个 quicklistNode 形成了一个双向链表。但是链表节点的元素不再是单纯保存元素值，而是保存了一个压缩列表，所以 quicklistNode 结构体里有个指向压缩列表的指针 \*zl。

![image-20230402122954300][]

在向 quicklist 添加一个元素的时候，不会像普通的链表那样，直接新建一个链表节点。**而是会检查插入位置的压缩列表是否能容纳该元素，如果能容纳就直接保存到 quicklistNode 结构里的压缩列表**，如果不能容纳，才会新建一个新的 quicklistNode 结构。

**quicklist 会控制 quicklistNode 结构里的压缩列表的大小或者元素个数，来规避潜在的连锁更新的风险，但是这并没有完全解决连锁更新的问题。**

--------------------

## 8. listpack ##

listpack 采用了压缩列表的很多优秀的设计，比如还是用一块连续的内存空间来紧凑地保存数据，并且为了节省内存的开销，listpack 节点会采用不同的编码方式保存不同大小的数据。

listpack的结构如下

![image-20230402123258520][]

listpack 头包含两个属性，分别记录了 listpack 总字节数和元素数量，然后 listpack 末尾也有个结尾标识。图中的 listpack entry 就是 listpack 的节点了。

每个 listpack 节点结构如下：

![image-20230402123322961][]

主要包含三个方面内容：

*  encoding，定义该元素的编码类型，会对不同长度的整数和字符串进行编码；
 *  data，实际存放的数据；
 *  len，encoding+data的总长度；

可以看到，**listpack 没有压缩列表中记录前一个节点长度的字段了，listpack 只记录当前节点的长度，当我们向 listpack 加入一个新元素的时候，不会影响其他节点的长度字段的变化，从而避免了压缩列表的连锁更新问题**。

--------------------

> 原文：[Redis 数据结构-小林coding][Redis _-_coding]
> 
> 对原文进行整理，另外加了一点点内容。

[image-20230401155036229]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/c10db620f0f444cd89fc1289f3464f0f.png
[image-20230401155053396]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/6fce01d26c3e4816be86652c7179f2df.png
[img]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/9a6fb67491d44dc2be330a60a29dca6d.png
[image-20230401202707691]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/2de86057c5a0404cadfe2b5f4e26748d.png
[image-20230401205514710]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/a99663b809054b7896d7d870fe996d55.png
[image-20230401205633180]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/f05619e3adf2455ab797924e3e9a5c7b.png
[image-20230401212752381]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/09188b001312461da4d0f0c7565d53aa.png
[image-20230401213320913]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/ad3aeb2d2ddc40e1b364a68776f6e99d.png
[image-20230401212947692]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/99ebb95034154173a92bc395856cfa83.png
[image-20230401213354498]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/9da3e66a1c1b4dcc8cc8cf60d67850e6.png
[img 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/831eeeadd6694ed0b2590023d3caf619.png
[image-20230401222206707]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/830d92858be9454495a081487263f2d6.png
[image-20230401224758750]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/8f6e756f4e57480c8fb4a22e50aac72e.png
[image-20230402114902669]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/93723d3317da41519b151f34bee2b7f9.png
[image-20230402115721993]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/c677014b955d44469b5e294276a56d08.png
[image-20230402122243078]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/05950cbb99244d85b492eb898c53d662.png
[image-20230402122954300]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/ec8d670a0ece46b5be18ca28b3b30224.png
[image-20230402123258520]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/cb390c73648c424281ec91644bd65784.png
[image-20230402123322961]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/cbb3d82230034a75a91b44972b0092b1.png
[Redis _-_coding]: https://www.xiaolincoding.com/redis/data_struct/data_struct.html