Redis设计与实现-第一部分-数据结构与对象_不是。 v 个个。说 0 0xsds) 8 0 0008 00 吃,-CSDN博客

本文链接：https://blog.csdn.net/weixin_43987610/article/details/118253350

第一部分数据结构与对象

第2章简单动态字符串

Redis使用SDS来表示字符串值。

Eg:

$ src/redis-cli
127.0.0.1:6379> SET msg "hello world"
OK

Ps:创建了一个键值对，

键对象通过一个SDS实现，保存的内容为"msg"；

值对象通过一个SDS实现，保存的内容为"hello world"

SDS的定义

在这里插入图片描述

Ps:

free : 5 未使用的空间

len：字符串长度

buf：指向char类型数组，最后一个字节保留空字符\0

SDS与C字符串的区别

Redis将获取字符串长度所需的复杂度从O(N)降低到了O(1)
杜绝缓冲区溢出，C字符串不会记录自身长度，与C字符串不同，SDS空间分配策略杜绝了而发生缓冲溢出的可能性，在对SDS字符串修改前，会先计算剩余空间是否够用，不后用的话会首先分配空间
减少修改字符串时带来的内存重分配次数：
- 空间预分配
  
  主要用于优化SDS字符串增长的操作，程序为SDS分配修改所需要的的空间时，还会为SDS分配额外的未使用的空间。公式如下：
  
  如果SDS修改后未超过1M：分配同样到校的未使用的空间，例如分配"hello world"，则需要 11 + 11 + 1 = 23字节（额外一个字节用于保存空字符）
  
  如果SDS修改后超过1M：则会多分配1M的未使用空间，例如分配30M长度字符串，则实际长度为 30M + 1M + 1byte
- 惰性空间释放
  
  当SDS需要缩短SDS保存的字符串时，程序并不会立即使用内存重分配来回缩多出来的字节，而是使用free属性将这些字节的数量记录下来，并等待将来使用。当真正的需要释放空间时，在释放，不用担心惰性空间释放策略造成的内存浪费。
二进制安全

C 字符串中的字符必须符合某种编码（比如 ASCII），并且除了字符串的末尾之外，字符串里面不能包含空字符，否则最先被程序读入的空字符将被误认为是字符串结尾 —— 这些限制使得 C 字符串只能保存文本数据，而不能保存像图片、音频、视频、压缩文件这样的二进制数据。

在这里插入图片描述

Redis为了适用各种场景，而不是仅仅用来保存字符串，而是保存一系列二进制数据，SDS使用len属性的值而不是空字符来判断字符串的结束。

在这里插入图片描述

兼容部分C字符串函数

SDK API

函数	作用	时间复杂度
`sdsnew`	创建一个包含给定 C 字符串的 SDS 。	O(N) ， `N` 为给定 C 字符串的长度。
`sdsempty`	创建一个不包含任何内容的空 SDS 。	O(1)
`sdsfree`	释放给定的 SDS 。	O(1)
`sdslen`	返回 SDS 的已使用空间字节数。	这个值可以通过读取 SDS 的 `len` 属性来直接获得，复杂度为 O(1) 。
`sdsavail`	返回 SDS 的未使用空间字节数。	这个值可以通过读取 SDS 的 `free` 属性来直接获得，复杂度为 O(1) 。
`sdsdup`	创建一个给定 SDS 的副本（copy）。	O(N) ， `N` 为给定 SDS 的长度。
`sdsclear`	清空 SDS 保存的字符串内容。	因为惰性空间释放策略，复杂度为 O(1) 。
`sdscat`	将给定 C 字符串拼接到 SDS 字符串的末尾。	O(N) ， `N` 为被拼接 C 字符串的长度。
`sdscatsds`	将给定 SDS 字符串拼接到另一个 SDS 字符串的末尾。	O(N) ， `N` 为被拼接 SDS 字符串的长度。
`sdscpy`	将给定的 C 字符串复制到 SDS 里面，覆盖 SDS 原有的字符串。	O(N) ， `N` 为被复制 C 字符串的长度。
`sdsgrowzero`	用空字符将 SDS 扩展至给定长度。	O(N) ， `N` 为扩展新增的字节数。
`sdsrange`	保留 SDS 给定区间内的数据，不在区间内的数据会被覆盖或清除。	O(N) ， `N` 为被保留数据的字节数。
`sdstrim`	接受一个 SDS 和一个 C 字符串作为参数，从 SDS 左右两端分别移除所有在 C 字符串中出现过的字符。	O(M*N) ， `M` 为 SDS 的长度， `N` 为给定 C 字符串的长度。
`sdscmp`	对比两个 SDS 字符串是否相同。	O(N) ， `N` 为两个 SDS 中较短的那个 SDS 的长度。

第3章链表

链表和链表节点的实现

typedef struct listNode {

    // 前置节点
    struct listNode *prev;

    // 后置节点
    struct listNode *next;

    // 节点的值
    void *value;

} listNode;

多个 listNode 可以通过 prev 和 next 指针组成双端链表

在这里插入图片描述

typedef struct list {

    // 表头节点
    listNode *head;

    // 表尾节点
    listNode *tail;

    // 链表所包含的节点数量
    unsigned long len;

    // 节点值复制函数
    void *(*dup)(void *ptr);

    // 节点值释放函数
    void (*free)(void *ptr);

    // 节点值对比函数
    int (*match)(void *ptr, void *key);

} list;

list 结构为链表提供了表头指针 head 、表尾指针 tail ，以及链表长度计数器 len ，而 dup 、 free 和 match 成员则是用于实现多态链表所需的类型特定函数：

dup 函数用于复制链表节点所保存的值；
free 函数用于释放链表节点所保存的值；
match 函数则用于对比链表节点所保存的值和另一个输入值是否相等。

Eg:由一个 list 结构和三个 listNode 结构组成的链表

在这里插入图片描述

Redis 的链表实现的特性可以总结如下：

双端：链表节点带有 prev 和 next 指针，获取某个节点的前置节点和后置节点的复杂度都是 O(1) 。
无环：表头节点的 prev 指针和表尾节点的 next 指针都指向 NULL ，对链表的访问以 NULL 为终点。
带表头指针和表尾指针：通过 list 结构的 head 指针和 tail 指针，程序获取链表的表头节点和表尾节点的复杂度为 O(1) 。
带链表长度计数器：程序使用 list 结构的 len 属性来对 list 持有的链表节点进行计数，程序获取链表中节点数量的复杂度为 O(1) 。
多态：链表节点使用 void* 指针来保存节点值，并且可以通过 list 结构的 dup 、 free 、 match 三个属性为节点值设置类型特定函数，所以链表可以用于保存各种不同类型的值。

链表和链表节点的 API

函数	作用	时间复杂度
`listSetDupMethod`	将给定的函数设置为链表的节点值复制函数。	O(1) 。
`listGetDupMethod`	返回链表当前正在使用的节点值复制函数。	复制函数可以通过链表的 `dup` 属性直接获得， O(1)
`listSetFreeMethod`	将给定的函数设置为链表的节点值释放函数。	O(1) 。
`listGetFree`	返回链表当前正在使用的节点值释放函数。	释放函数可以通过链表的 `free` 属性直接获得， O(1)
`listSetMatchMethod`	将给定的函数设置为链表的节点值对比函数。	O(1)
`listGetMatchMethod`	返回链表当前正在使用的节点值对比函数。	对比函数可以通过链表的 `match` 属性直接获得， O(1)
`listLength`	返回链表的长度（包含了多少个节点）。	链表长度可以通过链表的 `len` 属性直接获得， O(1) 。
`listFirst`	返回链表的表头节点。	表头节点可以通过链表的 `head` 属性直接获得， O(1) 。
`listLast`	返回链表的表尾节点。	表尾节点可以通过链表的 `tail` 属性直接获得， O(1) 。
`listPrevNode`	返回给定节点的前置节点。	前置节点可以通过节点的 `prev` 属性直接获得， O(1) 。
`listNextNode`	返回给定节点的后置节点。	后置节点可以通过节点的 `next` 属性直接获得， O(1) 。
`listNodeValue`	返回给定节点目前正在保存的值。	节点值可以通过节点的 `value` 属性直接获得， O(1) 。
`listCreate`	创建一个不包含任何节点的新链表。	O(1)
`listAddNodeHead`	将一个包含给定值的新节点添加到给定链表的表头。	O(1)
`listAddNodeTail`	将一个包含给定值的新节点添加到给定链表的表尾。	O(1)
`listInsertNode`	将一个包含给定值的新节点添加到给定节点的之前或者之后。	O(1)
`listSearchKey`	查找并返回链表中包含给定值的节点。	O(N) ， `N` 为链表长度。
`listIndex`	返回链表在给定索引上的节点。	O(N) ， `N` 为链表长度。
`listDelNode`	从链表中删除给定节点。	O(1) 。
`listRotate`	将链表的表尾节点弹出，然后将被弹出的节点插入到链表的表头，成为新的表头节点。	O(1)
`listDup`	复制一个给定链表的副本。	O(N) ， `N` 为链表长度。
`listRelease`	释放给定链表，以及链表中的所有节点。	O(N) ， `N` 为链表长度。

第4章字典

字典的实现

Redis字典使用哈希表作为底层实现

哈希表

Redis 字典所使用的哈希表由 dict.h/dictht 结构定义：

typedef struct dictht {

    // 哈希表数组
    dictEntry **table;

    // 哈希表大小
    unsigned long size;

    // 哈希表大小掩码，用于计算索引值
    // 总是等于 size - 1
    unsigned long sizemask;

    // 该哈希表已有节点的数量
    unsigned long used;

} dictht;

table 属性是一个数组，数组中的每个元素都是一个指向 dict.h/dictEntry 结构的指针，每个 dictEntry 结构保存着一个键值对。

size 属性记录了哈希表的大小，也即是 table 数组的大小，而 used 属性则记录了哈希表目前已有节点（键值对）的数量。

sizemask 属性的值总是等于 size - 1 ，这个属性和哈希值一起决定一个键应该被放到 table 数组的哪个索引上面。

一个大小为 4 的空哈希表（没有包含任何键值对）

在这里插入图片描述

哈希表节点

哈希表节点使用 dictEntry 结构表示，每个 dictEntry 结构都保存着一个键值对：

typedef struct dictEntry {

    // 键
    void *key;

    // 值
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
    } v;

    // 指向下个哈希表节点，形成链表
    struct dictEntry *next;

} dictEntry;

key 属性保存着键值对中的键，而 v 属性则保存着键值对中的值，其中键值对的值可以是一个指针，或者是一个 uint64_t 整数，又或者是一个 int64_t 整数。

next 属性是指向另一个哈希表节点的指针，这个指针可以将多个哈希值相同的键值对连接在一次，以此来解决键冲突（collision）的问题。

如何通过 next 指针，将两个索引值相同的键 k1 和 k0 连接在一起
在这里插入图片描述

字典

Redis 中的字典由 dict.h/dict 结构表示：

typedef struct dict {

    // 类型特定函数
    dictType *type;

    // 私有数据
    void *privdata;

    // 哈希表
    dictht ht[2];

    // rehash 索引
    // 当 rehash 不在进行时，值为 -1
    int rehashidx; /* rehashing not in progress if rehashidx == -1 */

} dict;

type 属性和 privdata 属性是针对不同类型的键值对，为创建多态字典而设置的：

type 属性是一个指向 dictType 结构的指针，每个 dictType 结构保存了一簇用于操作特定类型键值对的函数， Redis 会为用途不同的字典设置不同的类型特定函数。
而 privdata 属性则保存了需要传给那些类型特定函数的可选参数。
ht 属性是一个包含两个项的数组，数组中的每个项都是一个 dictht 哈希表，一般情况下，字典只使用 ht[0] 哈希表， ht[1] 哈希表只会在对 ht[0] 哈希表进行 rehash 时使用。
rehashidx ：它记录了 rehash 目前的进度，如果目前没有在进行 rehash ，那么它的值为 -1 。

typedef struct dictType {

    // 计算哈希值的函数
    unsigned int (*hashFunction)(const void *key);

    // 复制键的函数
    void *(*keyDup)(void *privdata, const void *key);

    // 复制值的函数
    void *(*valDup)(void *privdata, const void *obj);

    // 对比键的函数
    int (*keyCompare)(void *privdata, const void *key1, const void *key2);

    // 销毁键的函数
    void (*keyDestructor)(void *privdata, void *key);

    // 销毁值的函数
    void (*valDestructor)(void *privdata, void *obj);

} dictType;

一个普通状态下（没有进行 rehash）的字典：

在这里插入图片描述

哈希算法

Redis使用MurmurHash2算法来计算键的哈希值

解决键冲突

当两个或以上数量的键被分配到哈希表数组的同一个索引上面时，就发生了冲突。

Redis的哈希表使用链地址法来解决键冲突，哈希表节点使用next指针构成一个单项链条。

Eg:一个包含k0和k1哈希表
在这里插入图片描述

当程序要将键值对 k2 和 v2 添加到的哈希表里面，并且计算得出 k2 的索引值为 2 ，那么键 k1 和 k2 将产生冲突，而解决冲突的办法就是使用 next 指针将键 k2 和 k1 所在的节点连接起来
在这里插入图片描述

rehash

随着不断插入和删除，为了让哈希表的负载因子维持在一个合理的范围，需要对哈希表的大小执行相应的扩展或搜索。

rehash步骤：

为字典的 ht[1] 哈希表分配空间，这个哈希表的空间大小取决于要执行的操作，以及 ht[0] 当前包含的键值对数量（也即是 ht[0].used 属性的值）：
- 如果执行的是扩展操作，那么 ht[1] 的大小为第一个大于等于 ht[0].used * 2 的 2^n （2 的 n 次方幂）；
- 如果执行的是收缩操作，那么 ht[1] 的大小为第一个大于等于 ht[0].used 的 2^n 。
将保存在 ht[0] 中的所有键值对 rehash 到 ht[1] 上面： rehash 指的是重新计算键的哈希值和索引值，然后将键值对放置到 ht[1] 哈希表的指定位置上。
当 ht[0] 包含的所有键值对都迁移到了 ht[1] 之后（ht[0] 变为空表），释放 ht[0] ，将 ht[1] 设置为 ht[0] ，并在 ht[1] 新创建一个空白哈希表，为下一次 rehash 做准备。

Eg：
在这里插入图片描述

执行rehash之前的字典

ht[0].used 当前的值为 4 ， 4 * 2 = 8 ，而 8 （2^3）恰好是第一个大于等于 4 的 2 的 n 次方，所以程序会将 ht[1] 哈希表的大小设置为 8 。图 4-9 展示了 ht[1] 在分配空间之后，字典的样子。
将 ht[0] 包含的四个键值对都 rehash 到 ht[1]
释放 ht[0] ，并将 ht[1] 设置为 ht[0] ，然后为 ht[1] 分配一个空白哈希表

哈希表的扩展与收缩

负载因子的计算

# 负载因子 = 哈希表已保存节点数量 / 哈希表大小
load_factor = ht[0].used / ht[0].size

当以下任意一个被满足时，程序会自动对哈希表执行扩展操作：

服务器目前没有在执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且哈希表的负载因子大于等于 1 ；
服务器目前正在执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且哈希表的负载因子大于等于 5 ；

当哈希表的负载因子小于 0.1 时，程序自动开始对哈希表执行收缩操作。

渐进式rehash

rehash的动作并不是一次性完成的，而是分多次、渐进式的完成的。

这样的原因在于不必一次性完成庞大的计算，不会造成服务器停止服务。

渐进式rehash过程：

为 ht[1] 分配空间，让字典同时持有 ht[0] 和 ht[1] 两个哈希表。
在字典中维持一个索引计数器变量 rehashidx ，并将它的值设置为 0 ，表示 rehash 工作正式开始。
在 rehash 进行期间，每次对字典执行添加、删除、查找或者更新操作时，程序除了执行指定的操作以外，还会顺带将 ht[0] 哈希表在 rehashidx 索引上的所有键值对 rehash 到 ht[1] ，当 rehash 工作完成之后，程序将 rehashidx 属性的值增一。
随着字典操作的不断执行，最终在某个时间点上， ht[0] 的所有键值对都会被 rehash 至 ht[1] ，这时程序将 rehashidx 属性的值设为 -1 ，表示 rehash 操作已完成。

因为在进行渐进式 rehash 的过程中，字典会同时使用 ht[0] 和 ht[1] 两个哈希表，所以在渐进式 rehash 进行期间，字典的删除（delete）、查找（find）、更新（update）等操作会在两个哈希表上进行：比如说，要在字典里面查找一个键的话，程序会先在 ht[0] 里面进行查找，如果没找到的话，就会继续到 ht[1] 里面进行查找，诸如此类。

另外，在渐进式 rehash 执行期间，新添加到字典的键值对一律会被保存到 ht[1] 里面，而 ht[0] 则不再进行任何添加操作：这一措施保证了 ht[0] 包含的键值对数量会只减不增，并随着 rehash 操作的执行而最终变成空表。

字典API

函数	作用	时间复杂度
`dictCreate`	创建一个新的字典。	O(1)
`dictAdd`	将给定的键值对添加到字典里面。	O(1)
`dictReplace`	将给定的键值对添加到字典里面，如果键已经存在于字典，那么用新值取代原有的值。	O(1)
`dictFetchValue`	返回给定键的值。	O(1)
`dictGetRandomKey`	从字典中随机返回一个键值对。	O(1)
`dictDelete`	从字典中删除给定键所对应的键值对。	O(1)
`dictRelease`	释放给定字典，以及字典中包含的所有键值对。	O(N) ， `N` 为字典包含的键值对数量。

第5章跳跃表

跳跃表是有序数据结构，跳跃表支持平均O(logN)、最坏O(N)复杂度的节点查找。

大部分情况下，跳跃表效率可媲美平衡树，并且跳跃表实现比平衡树要简单。

Redis使用跳跃表作为有序集合键的底层实质之一，Redis只有两个地方使用到了跳跃表，一个是实现有序集合键，另一个是集群节点中用作内部数据结构。

跳跃表的实现

在这里插入图片描述

header ：指向跳跃表的表头节点。
tail ：指向跳跃表的表尾节点。
level ：记录目前跳跃表内，层数最大的那个节点的层数（表头节点的层数不计算在内）。
length ：记录跳跃表的长度，也即是，跳跃表目前包含节点的数量（表头节点不计算在内）。

位于 zskiplist 结构右方的是四个 zskiplistNode 结构，该结构包含以下属性：

层（level）：节点中用 L1 、 L2 、 L3 等字样标记节点的各个层， L1 代表第一层， L2 代表第二层，以此类推。每个层都带有两个属性：前进指针和跨度。前进指针用于访问位于表尾方向的其他节点，而跨度则记录了前进指针所指向节点和当前节点的距离。在上面的图片中，连线上带有数字的箭头就代表前进指针，而那个数字就是跨度。当程序从表头向表尾进行遍历时，访问会沿着层的前进指针进行。
后退（backward）指针：节点中用 BW 字样标记节点的后退指针，它指向位于当前节点的前一个节点。后退指针在程序从表尾向表头遍历时使用。
分值（score）：各个节点中的 1.0 、 2.0 和 3.0 是节点所保存的分值。在跳跃表中，节点按各自所保存的分值从小到大排列。
成员对象（obj）：各个节点中的 o1 、 o2 和 o3 是节点所保存的成员对象。

跳跃表节点

跳跃表节点的实现由 redis.h/zskiplistNode 结构定义：

typedef struct zskiplistNode {

    // 后退指针
    struct zskiplistNode *backward;

    // 分值
    double score;

    // 成员对象
    robj *obj;

    // 层
    struct zskiplistLevel {

        // 前进指针
        struct zskiplistNode *forward;

        // 跨度
        unsigned int span;

    } level[];

} zskiplistNode;

层

跳跃表节点的 level 数组可以包含多个元素，每个元素都包含一个指向其他节点的指针，程序可以通过这些层来加快访问其他节点的速度，一般来说，层的数量越多，访问其他节点的速度就越快。

每次创建一个新跳跃表节点的时候，程序都根据幂次定律（power law，越大的数出现的概率越小）随机生成一个介于 1 和 32 之间的值作为 level 数组的大小，这个大小就是层的“高度”。

前进指针

每个层都有一个指向表尾方向的前进指针，用于从表头向表尾方向访问节点，以便遍历整个跳跃表。

跨度

层的跨度用于记录两个节点之间的距离：

两个节点之间的跨度越大，它们相距得就越远。
指向 NULL 的所有前进指针的跨度都为 0 ，因为它们没有连向任何节点。

跨度实际上是用来计算排位（rank）的：在查找某个节点的过程中，将沿途访问过的所有层的跨度累计起来，得到的结果就是目标节点在跳跃表中的排位。

Eg：
在这里插入图片描述

Ps：虚线标记了在跳跃表中查找分值为 3.0 、成员对象为 o3 的节点时，沿途经历的层：查找的过程只经过了一个层，并且层的跨度为 3 ，所以目标节点在跳跃表中的排位为 3

Eg：
在这里插入图片描述

Ps：虚线标记了在跳跃表中查找分值为 2.0 、成员对象为 o2 的节点时，沿途经历的层：在查找节点的过程中，程序经过了两个跨度为 1 的节点，因此可以计算出，目标节点在跳跃表中的排位为 2

后退指针

节点的后退指针用于从表尾向表头方向访问节点

分值和成员

节点的分值（score 属性）是一个 double 类型的浮点数，跳跃表中的所有节点都按分值从小到大来排序。

节点的成员对象（obj 属性）是一个指针，它指向一个字符串对象，而字符串对象则保存着一个 SDS 值。

在同一个跳跃表中，各个节点保存的成员对象必须是唯一的，但是多个节点保存的分值却可以是相同的：分值相同的节点将按照成员对象在字典序中的大小来进行排序，成员对象较小的节点会排在前面（靠近表头的方向），而成员对象较大的节点则会排在后面（靠近表尾的方向）。

跳跃表 API

函数	作用	时间复杂度
`zslCreate`	创建一个新的跳跃表。	O(1)
`zslFree`	释放给定跳跃表，以及表中包含的所有节点。	O(N) ， `N` 为跳跃表的长度。
`zslInsert`	将包含给定成员和分值的新节点添加到跳跃表中。	平均 O(\log N) ，最坏 O(N) ， `N` 为跳跃表长度。
`zslDelete`	删除跳跃表中包含给定成员和分值的节点。	平均 O(\log N) ，最坏 O(N) ， `N` 为跳跃表长度。
`zslGetRank`	返回包含给定成员和分值的节点在跳跃表中的排位。	平均 O(\log N) ，最坏 O(N) ， `N` 为跳跃表长度。
`zslGetElementByRank`	返回跳跃表在给定排位上的节点。	平均 O(\log N) ，最坏 O(N) ， `N` 为跳跃表长度。
`zslIsInRange`	给定一个分值范围（range），比如 `0` 到 `15` ， `20` 到 `28` ，诸如此类，如果给定的分值范围包含在跳跃表的分值范围之内，那么返回 `1` ，否则返回 `0` 。	通过跳跃表的表头节点和表尾节点，这个检测可以用 O(1) 复杂度完成。
`zslFirstInRange`	给定一个分值范围，返回跳跃表中第一个符合这个范围的节点。	平均 O(\log N) ，最坏 O(N) 。 `N` 为跳跃表长度。
`zslLastInRange`	给定一个分值范围，返回跳跃表中最后一个符合这个范围的节点。	平均 O(\log N) ，最坏 O(N) 。 `N` 为跳跃表长度。
`zslDeleteRangeByScore`	给定一个分值范围，删除跳跃表中所有在这个范围之内的节点。	O(N) ， `N` 为被删除节点数量。
`zslDeleteRangeByRank`	给定一个排位范围，删除跳跃表中所有在这个范围之内的节点。	O(N) ， `N` 为被删除节点数量。

第6章整数集合

整数集合是Redis用于保存整数值的集合抽象数据结构。

整数集合的实现

每个 intset.h/intset 结构表示一个整数集合：

typedef struct intset {

    // 编码方式
    uint32_t encoding;

    // 集合包含的元素数量
    uint32_t length;

    // 保存元素的数组
    int8_t contents[];

} intset;

contents 数组是整数集合的底层实现：整数集合的每个元素都是 contents 数组的一个数组项（item），各个项在数组中按值的大小从小到大有序地排列，并且数组中不包含任何重复项。

length 属性记录了整数集合包含的元素数量，也即是 contents 数组的长度。

虽然 intset 结构将 contents 属性声明为 int8_t 类型的数组，但实际上 contents 数组并不保存任何 int8_t 类型的值 —— contents 数组的真正类型取决于 encoding 属性的值：

如果 encoding 属性的值为 INTSET_ENC_INT16 ，那么 contents 就是一个 int16_t 类型的数组，数组里的每个项都是一个 int16_t 类型的整数值（最小值为 -32,768 ，最大值为 32,767 ）。
如果 encoding 属性的值为 INTSET_ENC_INT32 ，那么 contents 就是一个 int32_t 类型的数组，数组里的每个项都是一个 int32_t 类型的整数值（最小值为 -2,147,483,648 ，最大值为 2,147,483,647 ）。
如果 encoding 属性的值为 INTSET_ENC_INT64 ，那么 contents 就是一个 int64_t 类型的数组，数组里的每个项都是一个 int64_t 类型的整数值（最小值为 -9,223,372,036,854,775,808 ，最大值为 9,223,372,036,854,775,807 ）。

Eg:整数集合示例
在这里插入图片描述

升级

每当我们要将一个新元素添加到整数集合里面，并且新元素的类型比整数集合现有所有元素的类型都要长时，整数集合需要先进行升级（upgrade），然后才能将新元素添加到整数集合里面。

整数集合不支持降级操作，一旦对数组进行升级，编码就会保持升级后的状态。

升级整数集合并添加新元素共分为三步进行：

根据新元素的类型，扩展整数集合底层数组的空间大小，并为新元素分配空间。
将底层数组现有的所有元素都转换成与新元素相同的类型，并将类型转换后的元素放置到正确的位上，而且在放置元素的过程中，需要继续维持底层数组的有序性质不变。
将新元素添加到底层数组里面。

升级的好处

提升灵活性
节约内存

整数集合 API

函数	作用	时间复杂度
`intsetNew`	创建一个新的整数集合。	O(1)
`intsetAdd`	将给定元素添加到整数集合里面。	O(N)
`intsetRemove`	从整数集合中移除给定元素。	O(N)
`intsetFind`	检查给定值是否存在于集合。	因为底层数组有序，查找可以通过二分查找法来进行，所以复杂度为 O(\log N) 。
`intsetRandom`	从整数集合中随机返回一个元素。	O(1)
`intsetGet`	取出底层数组在给定索引上的元素。	O(1)
`intsetLen`	返回整数集合包含的元素个数。	O(1)
`intsetBlobLen`	返回整数集合占用的内存字节数。	O(1)

第7章压缩列表

压缩列表是列表键和哈希键的底层实现之一。当一个列表键只包含少量列表项，并且每个列表项要么就是小整数值，要么就是长度比较短的字符串，那么 Redis 就会使用压缩列表来做列表键的底层实现。

压缩列表的构造

压缩列表主要是为了能够节省内存而开发的，由一系列特殊编码的连续内存块组成的顺序型数据结构。
在这里插入图片描述

压缩列表各个组成部分

属性	类型	长度	用途
`zlbytes`	`uint32_t`	`4` 字节	记录整个压缩列表占用的内存字节数：在对压缩列表进行内存重分配，或者计算 `zlend` 的位置时使用。
`zltail`	`uint32_t`	`4` 字节	记录压缩列表表尾节点距离压缩列表的起始地址有多少字节：通过这个偏移量，程序无须遍历整个压缩列表就可以确定表尾节点的地址。
`zllen`	`uint16_t`	`2` 字节	记录了压缩列表包含的节点数量：当这个属性的值小于 `UINT16_MAX` （`65535`）时，这个属性的值就是压缩列表包含节点的数量；当这个值等于 `UINT16_MAX` 时，节点的真实数量需要遍历整个压缩列表才能计算得出。
`entryX`	列表节点	不定	压缩列表包含的各个节点，节点的长度由节点保存的内容决定。
`zlend`	`uint8_t`	`1` 字节	特殊值 `0xFF` （十进制 `255` ），用于标记压缩列表的末端。

压缩列表节点的构成

每个压缩列表节点可以保存一个字节数组或者一个整数值，其中，字节数组可以是以下三种长度的其中一种：

长度小于等于 63 （2^{6}-1）字节的字节数组；
长度小于等于 16383 （2^{14}-1）字节的字节数组；
长度小于等于 4294967295 （2^{32}-1）字节的字节数组；

而整数值则可以是以下六种长度的其中一种：

4 位长，介于 0 至 12 之间的无符号整数；
1 字节长的有符号整数；
3 字节长的有符号整数；
int16_t 类型整数；
int32_t 类型整数；
int64_t 类型整数。

每个压缩列表节点都由 previous_entry_length 、 encoding 、 content 三个部分组成，如下图所示：
在这里插入图片描述

previous_entry_length

节点的 previous_entry_length 属性以字节为单位，记录了压缩列表中前一个节点的长度。

previous_entry_length 属性的长度可以是 1 字节或者 5 字节：

如果前一节点的长度小于 254 字节，那么 previous_entry_length 属性的长度为 1 字节：前一节点的长度就保存在这一个字节里面。
如果前一节点的长度大于等于 254 字节，那么 previous_entry_length 属性的长度为 5 字节：其中属性的第一字节会被设置为 0xFE （十进制值 254），而之后的四个字节则用于保存前一节点的长度。

因为节点的 previous_entry_length 属性记录了前一个节点的长度，所以程序可以通过指针运算，根据当前节点的起始地址来计算出前一个节点的起始地址。

压缩列表的从表尾向表头遍历操作就是使用这一原理实现的：只要我们拥有了一个指向某个节点起始地址的指针，那么通过这个指针以及这个节点的 previous_entry_length 属性，程序就可以一直向前一个节点回溯，最终到达压缩列表的表头节点。

encoding

节点的 encoding 属性记录了节点的 content 属性所保存数据的类型以及长度：

一字节、两字节或者五字节长，值的最高位为 00 、 01 或者 10 的是字节数组编码：这种编码表示节点的 content 属性保存着字节数组，数组的长度由编码除去最高两位之后的其他位记录；
一字节长，值的最高位以 11 开头的是整数编码：这种编码表示节点的 content 属性保存着整数值，整数值的类型和长度由编码除去最高两位之后的其他位记录；

字节数组编码

编码	编码长度	`content` 属性保存的值
`00bbbbbb`	`1` 字节	长度小于等于 `63` 字节的字节数组。
`01bbbbbb xxxxxxxx`	`2` 字节	长度小于等于 `16383` 字节的字节数组。
`10______ aaaaaaaa bbbbbbbb cccccccc dddddddd`	`5` 字节	长度小于等于 `4294967295` 的字节数组。

整数编码

编码	编码长度	`content` 属性保存的值
`11000000`	`1` 字节	`int16_t` 类型的整数。
`11010000`	`1` 字节	`int32_t` 类型的整数。
`11100000`	`1` 字节	`int64_t` 类型的整数。
`11110000`	`1` 字节	`24` 位有符号整数。
`11111110`	`1` 字节	`8` 位有符号整数。
`1111xxxx`	`1` 字节	使用这一编码的节点没有相应的 `content` 属性，因为编码本身的 `xxxx` 四个位已经保存了一个介于 `0` 和 `12` 之间的值，所以它无须 `content` 属性。

content

节点的 content 属性负责保存节点的值，节点值可以是一个字节数组或者整数，值的类型和长度由节点的 encoding 属性决定。

Eg：
在这里插入图片描述
Ps:

编码的最高两位 00 表示节点保存的是一个字节数组；
编码的后六位 001011 记录了字节数组的长度 11 ；
content 属性保存着节点的值 "hello world" 。

Eg：
在这里插入图片描述

Ps:

编码 11000000 表示节点保存的是一个 int16_t 类型的整数值；
content 属性保存着节点的值 10086 。

连锁更新

在这里插入图片描述

现在，考虑这样一种情况：在一个压缩列表中，有多个连续的、长度介于 250 字节到 253 字节之间的节点 e1 至 eN。

因为 e1 至 eN 的所有节点的长度都小于 254 字节，所以记录这些节点的长度只需要 1 字节长的 previous_entry_length 属性，换句话说， e1 至 eN 的所有节点的 previous_entry_length 属性都是 1 字节长的。

这时，如果我们将一个长度大于等于 254 字节的新节点 new 设置为压缩列表的表头节点，那么 new 将成为 e1 的前置节点，如下图所示。
在这里插入图片描述

因为 e1 的 previous_entry_length 属性仅长 1 字节，它没办法保存新节点 new 的长度，所以程序将对压缩列表执行空间重分配操作，并将 e1 节点的 previous_entry_length 属性从原来的 1 字节长扩展为 5 字节长。

现在，麻烦的事情来了 —— e1 原本的长度介于 250 字节至 253 字节之间，在为 previous_entry_length 属性新增四个字节的空间之后， e1 的长度就变成了介于 254 字节至 257 字节之间，而这种长度使用 1 字节长的 previous_entry_length 属性是没办法保存的。

因此，为了让 e2 的 previous_entry_length 属性可以记录下 e1 的长度，程序需要再次对压缩列表执行空间重分配操作，并将 e2 节点的 previous_entry_length 属性从原来的 1 字节长扩展为 5 字节长。

正如扩展 e1 引发了对 e2 的扩展一样，扩展 e2 也会引发对 e3 的扩展，而扩展 e3 又会引发对 e4 的扩展……为了让每个节点的 previous_entry_length 属性都符合压缩列表对节点的要求，程序需要不断地对压缩列表执行空间重分配操作，直到 eN 为止。

Redis 将这种在特殊情况下产生的连续多次空间扩展操作称之为“连锁更新”（cascade update），下图展示了这一过程。
在这里插入图片描述

除了添加新节点可能会引发连锁更新之外，删除节点也可能会引发连锁更新。

因为连锁更新在最坏情况下需要对压缩列表执行 N 次空间重分配操作，而每次空间重分配的最坏复杂度为 O(N) ，所以连锁更新的最坏复杂度为 O(N^2) 。

要注意的是，尽管连锁更新的复杂度较高，但它真正造成性能问题的几率是很低的：

首先，压缩列表里要恰好有多个连续的、长度介于 250 字节至 253 字节之间的节点，连锁更新才有可能被引发，在实际中，这种情况并不多见；
其次，即使出现连锁更新，但只要被更新的节点数量不多，就不会对性能造成任何影响：比如说，对三五个节点进行连锁更新是绝对不会影响性能的；

因为以上原因， ziplistPush 等命令的平均复杂度仅为 O(N) ，在实际中，我们可以放心地使用这些函数，而不必担心连锁更新会影响压缩列表的性能。

压缩列表API

函数	作用	算法复杂度
`ziplistNew`	创建一个新的压缩列表。	O(1)
`ziplistPush`	创建一个包含给定值的新节点，并将这个新节点添加到压缩列表的表头或者表尾。	平均 O(N) ，最坏 O(N^2) 。
`ziplistInsert`	将包含给定值的新节点插入到给定节点之后。	平均 O(N) ，最坏 O(N^2) 。
`ziplistIndex`	返回压缩列表给定索引上的节点。	O(N)
`ziplistFind`	在压缩列表中查找并返回包含了给定值的节点。	因为节点的值可能是一个字节数组，所以检查节点值和给定值是否相同的复杂度为 O(N) ，而查找整个列表的复杂度则为 O(N^2) 。
`ziplistNext`	返回给定节点的下一个节点。	O(1)
`ziplistPrev`	返回给定节点的前一个节点。	O(1)
`ziplistGet`	获取给定节点所保存的值。	O(1)
`ziplistDelete`	从压缩列表中删除给定的节点。	平均 O(N) ，最坏 O(N^2) 。
`ziplistDeleteRange`	删除压缩列表在给定索引上的连续多个节点。	平均 O(N) ，最坏 O(N^2) 。
`ziplistBlobLen`	返回压缩列表目前占用的内存字节数。	O(1)
`ziplistLen`	返回压缩列表目前包含的节点数量。	节点数量小于 `65535` 时 O(1) ，大于 `65535` 时 O(N) 。

第8章对象

Redis并没有直接使用上面介绍的那些数据结构来实现键值对数据库，而是基于这些数据结构创造了一个对象系统，这个系统包含

字符串对象
列表对象
哈希对象
集合对象
有序集合对象

5种类型的对象，每种对象都用到了至少一种上面提到的数据结构。

对象的好处

可以通过对象类型判断一个对象是否可以执行给定的命令
不同的场景，对象可以设置不同的数据结构实现，从而优化对象在不同场景下的使用效率

Redis 中的每个对象都由一个 redisObject 结构表示，该结构中和保存数据有关的三个属性分别是 type 属性、 encoding 属性和 ptr 属性：

typedef struct redisObject {

    // 类型
    unsigned type:4;

    // 编码
    unsigned encoding:4;

    // 指向底层实现数据结构的指针
    void *ptr;

    // ...

} robj;

对象的类型与编码

Redis使用对象来标识数据库中间键和值，每次创建一个键值对时，都是创建两个对象。

类型

Redis中，键总是一个字符串对象，值对象可以是

类型常量	对象的名称
`REDIS_STRING`	字符串对象
`REDIS_LIST`	列表对象
`REDIS_HASH`	哈希对象
`REDIS_SET`	集合对象
`REDIS_ZSET`	有序集合对象

查看类型

编码和底层实现

对象的 ptr 指针指向对象的底层实现数据结构，而这些数据结构由对象的 encoding 属性决定。

表：对象的编码

编码常量	编码所对应的底层数据结构
`REDIS_ENCODING_INT`	`long` 类型的整数
`REDIS_ENCODING_EMBSTR`	`embstr` 编码的简单动态字符串
`REDIS_ENCODING_RAW`	简单动态字符串
`REDIS_ENCODING_HT`	字典
`REDIS_ENCODING_LINKEDLIST`	双端链表
`REDIS_ENCODING_ZIPLIST`	压缩列表
`REDIS_ENCODING_INTSET`	整数集合
`REDIS_ENCODING_SKIPLIST`	跳跃表和字典

每种类型的对象都至少使用了两种不同的编码

表：不同类型和编码的对象

类型	编码	对象
`REDIS_STRING`	`REDIS_ENCODING_INT`	使用整数值实现的字符串对象。
`REDIS_STRING`	`REDIS_ENCODING_EMBSTR`	使用 `embstr` 编码的简单动态字符串实现的字符串对象。
`REDIS_STRING`	`REDIS_ENCODING_RAW`	使用简单动态字符串实现的字符串对象。
`REDIS_LIST`	`REDIS_ENCODING_ZIPLIST`	使用压缩列表实现的列表对象。
`REDIS_LIST`	`REDIS_ENCODING_LINKEDLIST`	使用双端链表实现的列表对象。
`REDIS_HASH`	`REDIS_ENCODING_ZIPLIST`	使用压缩列表实现的哈希对象。
`REDIS_HASH`	`REDIS_ENCODING_HT`	使用字典实现的哈希对象。
`REDIS_SET`	`REDIS_ENCODING_INTSET`	使用整数集合实现的集合对象。
`REDIS_SET`	`REDIS_ENCODING_HT`	使用字典实现的集合对象。
`REDIS_ZSET`	`REDIS_ENCODING_ZIPLIST`	使用压缩列表实现的有序集合对象。
`REDIS_ZSET`	`REDIS_ENCODING_SKIPLIST`	使用跳跃表和字典实现的有序集合对象。

使用 OBJECT ENCODING 命令可以查看一个数据库键的值对象的编码：

127.0.0.1:6379> SET msg "hello world"
OK
127.0.0.1:6379> OBJECT ENCODING msg
"embstr"

表：OBJECT ENCODING 对不同编码的输出

对象所使用的底层数据结构	编码常量	OBJECT ENCODING 命令输出
整数	`REDIS_ENCODING_INT`	`"int"`
`embstr` 编码的简单动态字符串（SDS）	`REDIS_ENCODING_EMBSTR`	`"embstr"`
简单动态字符串	`REDIS_ENCODING_RAW`	`"raw"`
字典	`REDIS_ENCODING_HT`	`"hashtable"`
双端链表	`REDIS_ENCODING_LINKEDLIST`	`"linkedlist"`
压缩列表	`REDIS_ENCODING_ZIPLIST`	`"ziplist"`
整数集合	`REDIS_ENCODING_INTSET`	`"intset"`
跳跃表和字典	`REDIS_ENCODING_SKIPLIST`	`"skiplist"`

通过 encoding 属性来设定对象所使用的编码，而不是为特定类型的对象关联一种固定的编码，极大地提升了 Redis 的灵活性和效率，因为 Redis 可以根据不同的使用场景来为一个对象设置不同的编码，从而优化对象在某一场景下的效率。

举个例子，在列表对象包含的元素比较少时， Redis 使用压缩列表作为列表对象的底层实现：

因为压缩列表比双端链表更节约内存，并且在元素数量较少时，在内存中以连续块方式保存的压缩列表比起双端链表可以更快被载入到缓存中；
随着列表对象包含的元素越来越多，使用压缩列表来保存元素的优势逐渐消失时，对象就会将底层实现从压缩列表转向功能更强、也更适合保存大量元素的双端链表上面；

其他类型的对象也会通过使用多种不同的编码来进行类似的优化。

在接下来的内容中，我们将分别介绍 Redis 中的五种不同类型的对象，说明这些对象底层所使用的编码方式，列出对象从一种编码转换成另一种编码所需的条件，以及同一个命令在多种不同编码上的实现方法。

字符串对象

字符串对象的编码可以是 int 、 raw 或者 embstr 。

如果一个字符串对象保存的是整数值，并且这个整数值可以用 long 类型来表示，那么字符串对象会将整数值保存在字符串对象结构的 ptr 属性里面（将 void* 转换成 long ），并将字符串对象的编码设置为 int 。
在这里插入图片描述

图：int编码的字符串对象

如果字符串对象保存的是一个字符串值，并且这个字符串值的长度大于 39 字节，那么字符串对象将使用一个简单动态字符串（SDS）来保存这个字符串值，并将对象的编码设置为 raw 。
在这里插入图片描述

图：raw编码的字符串对象

如果字符串对象保存的是一个字符串值，并且这个字符串值的长度小于等于 39 字节，那么字符串对象将使用 embstr 编码的方式来保存这个字符串值。

embstr 编码是专门用于保存短字符串的一种优化编码方式，这种编码和 raw 编码一样，都使用 redisObject 结构和 sdshdr 结构来表示字符串对象，但 raw 编码会调用两次内存分配函数来分别创建 redisObject 结构和 sdshdr 结构，而 embstr 编码则通过调用一次内存分配函数来分配一块连续的空间，空间中依次包含 redisObject 和 sdshdr 两个结构。

在这里插入图片描述

图：embstr编码创建的内存结构

embstr 编码的字符串对象在执行命令时，产生的效果和 raw 编码的字符串对象执行命令时产生的效果是相同的，但使用 embstr 编码的字符串对象来保存短字符串值有以下好处：

embstr 编码将创建字符串对象所需的内存分配次数从 raw 编码的两次降低为一次。
释放 embstr 编码的字符串对象只需要调用一次内存释放函数，而释放 raw 编码的字符串对象需要调用两次内存释放函数。
因为 embstr 编码的字符串对象的所有数据都保存在一块连续的内存里面，所以这种编码的字符串对象比起 raw 编码的字符串对象能够更好地利用缓存带来的优势。

如果我们要保存一个浮点数到字符串对象里面，那么程序会先将这个浮点数转换成字符串值，然后再保存起转换所得的字符串值。

表：字符串对象保存各类型值的编码方式

值	编码
可以用 `long` 类型保存的整数。	`int`
可以用 `long double` 类型保存的浮点数。	`embstr` 或者 `raw`
字符串值，或者因为长度太大而没办法用 `long` 类型表示的整数，又或者因为长度太大而没办法用 `long double` 类型表示的浮点数。	`embstr` 或者 `raw`

编码的转换

int编码字符串对象，如果对对象执行一些命令，使得对象保存的不再是整数值，而是一个字符串，那么字符串对象的编码就会从int变成raw。

Redis没有对embstr编码的字符串对象编写任何修改程序，所以embstr编码字符串是只读的。当对embstr编码字符串执行修改命令时，会转换成raw

列表对象

列表对象的编码可以是ziplist（底层使用压缩列表实现）或者linkedlist（底层使用双端链表实现）。
在这里插入图片描述

图：ziplist编码的列表对象 ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210626193559759.png) 图：linkedlist编码的列表对象

编码转换

当列表对象可以同时满足以下两个条件时，列表对象使用 ziplist 编码：

列表对象保存的所有字符串元素的长度都小于 64 字节；
列表对象保存的元素数量小于 512 个；

哈希对象

哈希对象的编码可以是 ziplist （压缩列表作为底层实现）或者 hashtable 。

ziplist 编码的哈希对象使用压缩列表作为底层实现，每当有新的键值对要加入到哈希对象时，程序会先将保存了键的压缩列表节点推入到压缩列表表尾，然后再将保存了值的压缩列表节点推入到压缩列表表尾，因此：

保存了同一键值对的两个节点总是紧挨在一起，保存键的节点在前，保存值的节点在后；
先添加到哈希对象中的键值对会被放在压缩列表的表头方向，而后来添加到哈希对象中的键值对会被放在压缩列表的表尾方向。

在这里插入图片描述

hashtable 编码的哈希对象使用字典作为底层实现，哈希对象中的每个键值对都使用一个字典键值对来保存：

字典的每个键都是一个字符串对象，对象中保存了键值对的键；
字典的每个值都是一个字符串对象，对象中保存了键值对的值。

在这里插入图片描述

编码转换

当哈希对象可以同时满足以下两个条件时，哈希对象使用 ziplist 编码：

哈希对象保存的所有键值对的键和值的字符串长度都小于 64 字节；
哈希对象保存的键值对数量小于 512 个；

不能满足这两个条件的哈希对象需要使用 hashtable 编码。

集合对象

集合对象的编码可以是 intset 或者 hashtable 。

intset 编码的集合对象使用整数集合作为底层实现，集合对象包含的所有元素都被保存在整数集合里面。
在这里插入图片描述

图：intset编码的集合对象

hashtable 编码的集合对象使用字典作为底层实现，字典的每个键都是一个字符串对象，每个字符串对象包含了一个集合元素，而字典的值则全部被设置为 NULL 。

在这里插入图片描述

图：hashtable编码的集合对象

编码转换

当集合对象可以同时满足以下两个条件时，对象使用 intset 编码：

集合对象保存的所有元素都是整数值；
集合对象保存的元素数量不超过 512 个；

不能满足这两个条件的集合对象需要使用 hashtable 编码。

有序集合对象

有序集合的编码可以是 ziplist 或者 skiplist 。

ziplist 编码的有序集合对象使用压缩列表作为底层实现，每个集合元素使用两个紧挨在一起的压缩列表节点来保存，第一个节点保存元素的成员（member），而第二个元素则保存元素的分值（score）。

在这里插入图片描述

图：`ziplist`编码的有序集合对象

skiplist 编码的有序集合对象使用 zset 结构作为底层实现，一个 zset 结构同时包含一个字典和一个跳跃表：

typedef struct zset {

    zskiplist *zsl;

    dict *dict;

} zset;

zset 结构中的 zsl 跳跃表按分值从小到大保存了所有集合元素，每个跳跃表节点都保存了一个集合元素：跳跃表节点的 object 属性保存了元素的成员，而跳跃表节点的 score 属性则保存了元素的分值。通过这个跳跃表，程序可以对有序集合进行范围型操作，比如 ZRANK 、 ZRANGE 等命令就是基于跳跃表 API 来实现的。

除此之外， zset 结构中的 dict 字典为有序集合创建了一个从成员到分值的映射，字典中的每个键值对都保存了一个集合元素：字典的键保存了元素的成员，而字典的值则保存了元素的分值。通过这个字典，程序可以用 O(1) 复杂度查找给定成员的分值， ZSCORE 命令就是根据这一特性实现的，而很多其他有序集合命令都在实现的内部用到了这一特性。

有序集合每个元素的成员都是一个字符串对象，而每个元素的分值都是一个 double 类型的浮点数。值得一提的是，虽然 zset 结构同时使用跳跃表和字典来保存有序集合元素，但这两种数据结构都会通过指针来共享相同元素的成员和分值，所以同时使用跳跃表和字典来保存集合元素不会产生任何重复成员或者分值，也不会因此而浪费额外的内存。

为什么有序集合需要同时使用跳跃表和字典来实现？

在理论上来说，有序集合可以单独使用字典或者跳跃表的其中一种数据结构来实现，但无论单独使用字典还是跳跃表，在性能上对比起同时使用字典和跳跃表都会有所降低。

举个例子，如果我们只使用字典来实现有序集合，那么虽然以 O(1) 复杂度查找成员的分值这一特性会被保留，但是，因为字典以无序的方式来保存集合元素，所以每次在执行范围型操作 —— 比如 ZRANK 、 ZRANGE 等命令时，程序都需要对字典保存的所有元素进行排序，完成这种排序需要至少 O(N \log N) 时间复杂度，以及额外的 O(N) 内存空间（因为要创建一个数组来保存排序后的元素）。

另一方面，如果我们只使用跳跃表来实现有序集合，那么跳跃表执行范围型操作的所有优点都会被保留，但因为没有了字典，所以根据成员查找分值这一操作的复杂度将从 O(1) 上升为 O(\log N) 。

因为以上原因，为了让有序集合的查找和范围型操作都尽可能快地执行， Redis 选择了同时使用字典和跳跃表两种数据结构来实现有序集合。
在这里插入图片描述

图：有序集合元素同时被保存在字典和跳跃表中

编码转换

当有序集合对象可以同时满足以下两个条件时，对象使用 ziplist 编码：

有序集合保存的元素数量小于 128 个；
有序集合保存的所有元素成员的长度都小于 64 字节；

不能满足以上两个条件的有序集合对象将使用 skiplist 编码。

类型检查与命令多态

Redis 中用于操作键的命令基本上可以分为两种类型。

其中一种命令可以对任何类型的键执行，比如说 DEL 命令、 EXPIRE 命令、 RENAME 命令、 TYPE 命令、 OBJECT 命令，等等。
而另一种命令只能对特定类型的键执行，比如说：
- SET 、 GET 、 APPEND 、 STRLEN 等命令只能对字符串键执行；
- HDEL 、 HSET 、 HGET 、 HLEN 等命令只能对哈希键执行；
- RPUSH 、 LPOP 、 LINSERT 、 LLEN 等命令只能对列表键执行；
- SADD 、 SPOP 、 SINTER 、 SCARD 等命令只能对集合键执行；
- ZADD 、 ZCARD 、 ZRANK 、 ZSCORE 等命令只能对有序集合键执行；

类型特定命令所进行的类型检查是通过 redisObject 结构的 type 属性来实现的：

在执行一个类型特定命令之前，服务器会先检查输入数据库键的值对象是否为执行命令所需的类型，如果是的话，服务器就对键执行指定的命令；
否则，服务器将拒绝执行命令，并向客户端返回一个类型错误。

Redis 除了会根据值对象的类型来判断键是否能够执行指定命令之外，还会根据值对象的编码方式，选择正确的命令实现代码来执行命令。

考虑这样一个情况，如果我们对一个键执行 LLEN 命令，那么服务器除了要确保执行命令的是列表键之外，还需要根据键的值对象所使用的编码来选择正确的 LLEN 命令实现：

如果列表对象的编码为 ziplist ，那么说明列表对象的实现为压缩列表，程序将使用 ziplistLen 函数来返回列表的长度；
如果列表对象的编码为 linkedlist ，那么说明列表对象的实现为双端链表，程序将使用 listLength 函数来返回双端链表的长度；

借用面向对象方面的术语来说，我们可以认为 LLEN 命令是多态（polymorphism）的：只要执行 LLEN 命令的是列表键，那么无论值对象使用的是 ziplist 编码还是 linkedlist 编码，命令都可以正常执行。

内存回收

因为 C 语言并不具备自动的内存回收功能，所以 Redis 在自己的对象系统中构建了一个引用计数（reference counting）技术实现的内存回收机制，通过这一机制，程序可以通过跟踪对象的引用计数信息，在适当的时候自动释放对象并进行内存回收。

每个对象的引用计数信息由 redisObject 结构的 refcount 属性记录：

typedef struct redisObject {

    // ...

    // 引用计数
    int refcount;

    // ...

} robj;

对象的引用计数信息会随着对象的使用状态而不断变化：

在创建一个新对象时，引用计数的值会被初始化为 1 ；
当对象被一个新程序使用时，它的引用计数值会被增一；
当对象不再被一个程序使用时，它的引用计数值会被减一；
当对象的引用计数值变为 0 时，对象所占用的内存会被释放。

对象共享

除了用于实现引用计数内存回收机制之外，对象的引用计数属性还带有对象共享的作用。
在这里插入图片描述

图： A 创建了一个包含整数值 `100` 的字符串对象作为值对象

如果这时键 B 也要创建一个同样保存了整数值 100 的字符串对象作为值对象，那么服务器有以下两种做法：

为键 B 新创建一个包含整数值 100 的字符串对象；
让键 A 和键 B 共享同一个字符串对象；

以上两种方法很明显是第二种方法更节约内存。

在 Redis 中，让多个键共享同一个值对象需要执行以下两个步骤：

将数据库键的值指针指向一个现有的值对象；
将被共享的值对象的引用计数增一。

图：键 A 和键 B 共享之后的样子

Redis 会在初始化服务器时，创建一万个字符串对象，这些对象包含了从 0 到 9999 的所有整数值，当服务器需要用到值为 0 到 9999 的字符串对象时，服务器就会使用这些共享对象，而不是新创建对象。

为什么 Redis 不共享包含字符串的对象？

当服务器考虑将一个共享对象设置为键的值对象时，程序需要先检查给定的共享对象和键想创建的目标对象是否完全相同，只有在共享对象和目标对象完全相同的情况下，程序才会将共享对象用作键的值对象，而一个共享对象保存的值越复杂，验证共享对象和目标对象是否相同所需的复杂度就会越高，消耗的 CPU 时间也会越多：

如果共享对象是保存整数值的字符串对象，那么验证操作的复杂度为 O(1) ；
如果共享对象是保存字符串值的字符串对象，那么验证操作的复杂度为 O(N) ；
如果共享对象是包含了多个值（或者对象的）对象，比如列表对象或者哈希对象，那么验证操作的复杂度将会是 O(N^2) 。

因此，尽管共享更复杂的对象可以节约更多的内存，但受到 CPU 时间的限制， Redis 只对包含整数值的字符串对象进行共享。

对象的空转时长

除了前面介绍过的 type 、 encoding 、 ptr 和 refcount 四个属性之外， redisObject 结构包含的最后一个属性为 lru 属性，该属性记录了对象最后一次被命令程序访问的时间：

typedef struct redisObject {

    // ...

    unsigned lru:22;

    // ...

} robj;

OBJECT IDLETIME 命令可以打印出给定键的空转时长，这一空转时长就是通过将当前时间减去键的值对象的 lru 时间计算得出的：

除了可以被 OBJECT IDLETIME 命令打印出来之外，键的空转时长还有另外一项作用：如果服务器打开了 maxmemory 选项，并且服务器用于回收内存的算法为 volatile-lru 或者 allkeys-lru ，那么当服务器占用的内存数超过了 maxmemory 选项所设置的上限值时，空转时长较高的那部分键会优先被服务器释放，从而回收内存。