Redis 数据结构与对象编码 (Object Encoding)

时间 2021-02-18

标签 redis 算法数据库数组安全性能优化服务器数据结构 ide 函数栏目 Redis 繁體版

原文原文链接

数据结构实现

相信你们对 redis 的数据结构都比较熟悉：redis

string：字符串（能够表示字符串、整数、位图）
list：列表（能够表示线性表、栈、双端队列、阻塞队列）
hash：哈希表
set：集合
zset：有序集合

为了将性能优化到极致，redis 做者为每种数据结构提供了不一样的实现方式，以适应特定应用场景。
以最经常使用的 string 为例，其底层实现就能够分为 3 种：int, embstr, raw算法

127.0.0.1:6379> SET counter 1
OK
127.0.0.1:6379> OBJECT ENCODING counter
"int"
127.0.0.1:6379> SET name "Tom"
OK
127.0.0.1:6379> OBJECT ENCODING name
"embstr"
127.0.0.1:6379> SETBIT bits 1 1
(integer) 0
127.0.0.1:6379> OBJECT ENCODING bits
"raw"

这些特定的底层实如今 redis 中被称为编码encoding，下面逐一介绍这些编码实现。数据库

string

redis 中全部的 key 都是字符串，这些字符串是经过一个名为 简单动态字符串SDS的数据结构实现的。数组

typedef char *sds; // SDS 字符串指针，指向 sdshdr.buf

    struct sdshdr? { // SDS header，[?] 能够为 8, 16, 32, 64
        uint?_t len;          // 已用空间，字符串的实际长度
        uint?_t alloc;        // 已分配空间，不包含'\0'
        unsigned char flags;  // 类型标记，指明了 len 与 alloc 的实际类型，能够经过 sds[-1] 获取
        char buf[];           // 字符数组，保存以'\0'结尾的字符串，与传统 C 语言中的字符串的表达方式保持一致
    };

内存布局以下：安全

+-------+---------+-----------+-------+
|  len  |  alloc  |   flags   |  buf  |
+-------+---------+-----------+-------+
                   ^--sds[-1]  ^--sds

相较于传统的 C 字符串，其优势以下：性能优化

高效：记录了已用空间，获取字符串长度的操做为O(1)
安全：记录了空闲空间，能够避免写缓冲区越界的问题
内存友好：经过记录了空间信息，能够预分配空间，实现惰性删除，减小内存分配的同时不会形成内存泄露
二进制安全：字符串内容能够为非 ASCII 编码，任意数据都能被编码为二进制字符串
兼容 C 字符串：能够复用部分 C 标准库代码，避免无用重复

list

redis 中 list 的底层实现之一是双向链表，该结构支持顺序访问，并提供了高效的元素增删功能。服务器

typedef struct listNode {
        struct listNode *prev; // 前置节点
        struct listNode *next; // 后置节点
        void *value;           // 节点值
    } listNode;

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

这里使用了函数指针来实现动态绑定，根据 value 类型，指定不一样 dup, free, match 的函数，实现多态。数据结构

该数据结构有如下特征：ide

有长：获取列表长度的操做为O(1)
双端：能够同时支持正向和逆向遍历，获取先后位置的节点复杂度为O(1)
无环：没有设置哨兵节点，列表为空时，表头表尾均为 NULL
多态：经过函数指针实现多态，数据结构能够复用

dict

redis 中使用 dict 来保存键值对，其底层实现之一是哈希表。函数

typedef struct dictEntry {
        void* key;  // 键
        union {     // 值，能够为指针、有符号长整，无符号长整，双精度浮点
            void *val;
            uint64_t u64;
            int64_t s64;
            double d;
        } v;
        struct dictEntry *next;
    } dictEntry;

    typedef struct dictht {
        dictEntry **table;      // 哈希表数组，数组中的每一个元素是一个单向链表
        unsigned long size;     // 哈希表数组大小
        unsigned long sizemask; // 哈希掩码，用于计算索引
        unsigned long used;     // 已有节点数量
    } dictht;

    typedef struct dictType {
        unsigned int (*hashFunction) (const void *key);             // 哈希函数，用于计算哈希值
        int (*keyCompare)(void *privdata, const void *key1, const void *key2); // 键比较函数
        void *(*keyDup)(void *privdata, const void *key);           // 键复制函数
        void *(*valDup)(void *privdata, const void *obj);           // 值复制函数
        void *(*keyDestructor)(void *privdata, const void *key);    // 键销毁函数
        void *(*valDestructor)(void *privdata, const void *obj);    // 值销毁函数
    } dictType;

    typedef struct dict {
        dictType *type;     // 类型函数，用于实现多态
        void *privdata;     // 私有数据，用于实现多态
        dictht ht[2];       // 哈希表，字典使用 ht[0] 做为哈希表，ht[1] 用于进行 rehash
        int rehashidx;      // rehash索引，当没有执行 rehash 时，其值为 -1
    } dict;

该数据结构有如下特征：

哈希算法：使用 murmurhash2 做为哈希函数，时间复杂度为O(1)
冲突解决：使用链地址法解决冲突，新增元素会被放到表头，时间复杂度为O(1)
从新散列：每次 rehash 操做都会分红 3 步完成

步骤1：为dict.ht[1]分配空间，其大小为 2 的 n 次方幂
步骤2：将dict.ht[0]中的全部键值对 rehash 到dict.ht[1]上
步骤3：释放dict.ht[0]的空间，用dict.ht[1]替换 dict.ht[0]

rehash 的一些细节

分摊开销

为了减小停顿，步骤2 会分为屡次渐进完成，将 rehash 键值对所需的计算工做，平均分摊到每一个字典的增长、删除、查找、更新操做，期间会使用dict.rehashidx记录dict.ht[0]中已经完成 rehash 操做的dictht.table索引：
- 每执行一次 rehash 操做，dict.rehashidx计数器会加 1
- 当 rehash 完成后，dict.rehashidx会被设置为 -1
触发条件
计算当前负载因子：loader_factor = ht[0].used / ht[0].size
收缩： 当 loader_factor < 0.1 时，执行 rehash 回收空闲空间
扩展：
1. 没有执行 BGSAVE 或 BGREWRITEAOF 命令，loader_factor >= 1 执行 rehash
2. 正在执行 BGSAVE 或 BGREWRITEAOF 命令，loader_factor >= 5 执行 rehash
大多操做系统都采用了 写时复制copy-on-write技术来优化子进程的效率：

父子进程共享同一份数据，直到数据被修改时，才实际拷贝内存空间给子进程，保证数据隔离

在执行 BGSAVE 或 BGREWRITEAOF 命令时，redis 会建立子进程，此时服务器会经过增长 loader_factor 的阈值，避免在子进程存在期间执行没必要要的内存写操做，节约内存

skiplist

跳表是一种有序数据结构，而且经过维持多层级指针来达到快速访问的目的，是典型的空间换时间策略。
其查找效率与平衡树相近，可是维护成本更低，且实现简单。

typedef struct zskiplistNode {
        sds ele;                        // 成员对象
        double score;                   // 分值
        struct zskiplistNode *backward; // 后退指针
        struct zskiplistLevel {
            struct zskiplistNode *forward;  // 前进指针
            unsigned long span;             // 跨度，当前节点和前进节点之间的距离
        } level[];
    } zskiplistNode;

    typedef struct zskiplist {
        struct zskiplistNode *header, *tail;// 头尾指针
        unsigned long length;               // 长度
        int level;                          // 最大层级
    } zskiplist;

该数据结构有如下特征：

查找：平均查找时间为O(logN)，最坏查找时间为O(N)，而且支持范围查找
几率：每次建立节点的时候，程序根据幂次定律随机生成一个 1 至 32 之间的随机数，用于决定层高
排位：在查找节点的过程当中，沿途访问过全部的跨度 span 累计起来，获得目标节点在表中的排位

intset

有序整型集合，具备紧凑的存储空间，添加操做的时间复杂度为O(N)。

typedef struct intset {
        uint32_t encoding;  // 编码方式，指示元素的实际类型
        uint32_t length;    // 元素数量
        int8_t contents[];  // 元素数组，元素实际类型可能为 int16_t,int32_t,int64_t,
    } intset;

该数据结构有如下特征：

有序：元素数组中的元素按照从小到大排列，使用二分查找时间复杂度为O(logN)
升级：当有新元素加入集合，且新元素比全部现有元素类型都长时，集合须要进行升级：

步骤1：根据新元素的类型，扩展元素数组空间
步骤2：将现有元素都转换为新类型
步骤3：将新元素添加到数组中

ziplist

压缩列表是为了节约内存而开发的，是存储在连续内存块上的顺序数据结构。
一个压缩列表能够包含任意多的 entry 节点，每一个节点包含一个字节数组或整数。
redis 中并无显式定义 ziplist 的数据结构，仅仅提供了一个描述结构 zlentry 用于操做数据。

typedef struct zlentry {
        unsigned int prevrawlensize;// 用于记录前一个 entry 长度的字节数
        unsigned int prevrawlen;    // 前一个 entry 的长度
        unsigned int lensize        // 用于记录当前 entry 类型/长度的字节数
        unsigned int len;           // 实际用于存储数据的字节数
        unsigned int headersize;    // prevrawlensize + lensize
        unsigned char encoding;     // 用于指示 entry 数据的实际编码类型
        unsigned char *p;           // 指向 entry 的开头
    } zlentry;

其实际的内存布局以下：

+----------+---------+---------+--------+-----+--------+--------+
|  zlbytes |  zltail |  zllen  | entry1 | ... | entryN |  zlend |
+----------+---------+---------+--------+-----+--------+--------+
<--------------------------- zlbytes --------------------------->
                                               ^--zltail
                                <------- zllen ------->

zlbytes : 压缩列表占用的字节数 (u_int32)
zltail : 压缩列表表尾偏移量，无需遍历便可肯定表尾地址，方便反向遍历 (u_int32)
zllen : 压缩列表节点数量，当节点数量大于 65535 时，具体数量须要经过遍历得出 (u_int16)
entryX : 列表节点，具体长度不定
zlend : 列表末端，特殊值 0xFF (u_int8)

entry 的内存布局以下：

+-------------------+----------+---------+
| prev_entry_length | encoding | content |
+-------------------+----------+---------+

prev_entry_length : 前一个节点的长度，能够根据当前节点的起始地址，计算前一个节点的起始地址（变长：1字节/5字节）
encoding : 节点保存数据的类型和长度（变长：1字节/2字节/5字节）
content : 节点保存的数据，能够保存整数或者字节数组

该数据结构具备如下特征：

结构紧凑：一整块连续内存，没有多余的内存碎片，更新会致使内存 realloc 与内存复制，平均时间复杂度为 O(N)
逆向遍历：从表尾开始向表头进行遍历
连锁更新：对前一条数据的更新，可能致使后一条数据的 prev_entry_length 与 encoding 所需长度变化，产生连锁反应，更新操做最坏时间为 O(N²)

quicklist

在较早版本的 redis 中，list 有两种底层实现：

当列表对象中元素的长度比较小或者数量比较少的时候，采用压缩列表 ziplist 来存储
当列表对象中元素的长度比较大或者数量比较多的时候，则会转而使用双向列表 linkedlist 来存储

二者各有优缺点：

ziplist 的优势是内存紧凑，访问效率高，缺点是更新效率低，而且数据量较大时，可能致使大量的内存复制
linkedlist 的优势是节点修改的效率高，可是须要额外的内存开销，而且节点较多时，会产生大量的内存碎片

为告终合二者的优势，在 redis 3.2 以后，list 的底层实现变为快速列表 quicklist。
快速列表是 linkedlist 与 ziplist 的结合: quicklist 包含多个内存不连续的节点，但每一个节点自己就是一个 ziplist。

typedef struct quicklistNode {
        struct quicklistNode *prev;  // 上一个 ziplist 
        struct quicklistNode *next;  // 下一个 ziplist 
        unsigned char *zl;           // 数据指针，指向 ziplist 结构，或者 quicklistLZF 结构
        unsigned int sz;             // ziplist 占用内存长度（未压缩）
        unsigned int count : 16;     // ziplist 记录数量
        unsigned int encoding : 2;   // 编码方式，1 表示 ziplist ，2 表示 quicklistLZF
        unsigned int container : 2;  // 
        unsigned int recompress : 1;         // 临时解压，1 表示该节点临时解压用于访问
        unsigned int attempted_compress : 1; // 测试字段
        unsigned int extra : 10;             // 预留空间
    } quicklistNode;

    typedef struct quicklistLZF {
        unsigned int sz;    // 压缩数据长度
        char compressed[];  // 压缩数据
    } quicklistLZF;

    typedef struct quicklist {
        quicklistNode *head;        // 列表头部
        quicklistNode *tail;        // 列表尾部
        unsigned long count;        // 记录总数
        unsigned long len;          // ziplist 数量
        int fill : 16;              // ziplist 长度限制，每一个 ziplist 节点的长度（记录数量/内存占用）不能超过这个值
        unsigned int compress : 16; // 压缩深度，表示 quicklist 两端不压缩的 ziplist 节点的个数，为 0 表示全部 ziplist 节点都不压缩
    } quicklist;

该数据结构有如下特征：

无缝切换：结合了 linkedlist 与 ziplist 的优势，无需在两种结构之间进行切换
中间压缩：做为队列使用的场景下，list 中间的数据被访问的频率比较低，能够选择进行压缩以减小内存占用

robj

为了实现动态编码技术，redis 构建了一个对象系统。
redis 能够在执行命令前，根据对象类型判断当前命令是否可以执行。
此外，该系统经过引用计数实现内存共享，并记录来对象访问时间，为优化内存回收策略提供了依据。

typedef struct redisObject {
        unsigned type:4;        // 类型，当前对象的逻辑类型，例如：set
        unsigned encoding:4;    // 编码，底层实现的数据结构，例如：intset / ziplist
        unsigned lru:24;        /* LRU 时间 (相对与全局 lru_clock 的时间) 或
                                 * LFU 数据 (8bits 记录访问频率，16 bits 记录访问时间). */
        int refcount;           // 引用计数
        void *ptr;              // 数据指针，指向具体的数据结构
    } robj;

该数据结构有如下特征：

高效：同个类型的 redis 对象可使用不一样的底层实现，能够在不一样的应用场景上优化对象的使用效率
节约内存：对于整数值的内存字符串对象，redis 能够经过记录引用计数来减小内存复制
空转时长：对象系统会记录对象的访问时间，方便 LRU 算法优先回收较少使用的对象

编码格式

string 类型

string 的编码类型可能为：

OBJ_ENCODING_INT int：long 类型整数
OBJ_ENCODING_RAW raw：sds 字符串
OBJ_ENCODING_EMBSTR embstr：嵌入式字符串（编码后长度小于 44 字节的字符串）

127.0.0.1:6379> SET str "1234567890 1234567890 1234567890 1234567890"
OK
127.0.0.1:6379> STRLEN str
(integer) 43
127.0.0.1:6379> OBJECT ENCODING str
"embstr"
127.0.0.1:6379> APPEND str _
(integer) 44
127.0.0.1:6379> OBJECT ENCODING str
"raw"

使用 embstr 编码是为了减小短字符串的内存分配次数，参考 redis 做者原话：

REDIS_ENCODING_EMBSTR_SIZE_LIMIT set to 39.
The new value is the limit for the robj + SDS header + string + null-term to stay inside the 64 bytes Jemalloc arena in 64 bits systems.

对比二者内存布局能够发现：

embstr 是一个完整连续的内存块，只须要 1 次内存分配
raw 的内存是不连续的，须要申请 2 次内存

<------------------------------------------ Jemalloc arena (64 bytes)  ---------------------------------------------->
+-------------------------------------------------------------------------------+---------------------+--------------+
|                             redisObject (16 bytes)                            |  sdshdr8 (3 bytes)  |   45 bytes   |
+--------------------+---------------------------------+-------+----------+-----+-----+-------+-------+---------+----+
| type(REDIS_STRING) | encoding(REDIS_ENCODING_EMBSTR) |  lru  | refcount | ptr | len | alloc | flags |   buf   | \0 |
+--------------------+---------------------------------+-------+----------+-----+-----+-------+-------+---------+----+


+--------------------+
|    redisObject     |
+--------------------+
|        type        |
|    REDIS_STRING    |
+--------------------+
|      encoding      |
| REDIS_ENCODING_RAW |
+--------------------+      +---------+
|         ptr        | ---> | sdshdr? |
+--------------------+      +---------+
                            |   len   |
                            +---------+
                            |  alloc  |
                            +---------+
                            |  flags  |
                            +---------++---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
                            |   buf   || T | h | e | r | e |   | i | s |   | n | o |   | c | e | r | t | a |...|
                            +---------++---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

list 类型

list 默认的编码类型为 OBJ_ENCODING_QUICKLIST quicklist

list-max-ziplist-size：每一个 quicklist 节点上的 ziplist 长度
list-compress-depth：quicklist 两端不压缩的节点数目

hash 类型

hash 的编码类型有 OBJ_ENCODING_ZIPLIST ziplist 与 OBJ_ENCODING_HT hashtable，具体使用哪一种编码受下面两个选项控制：

hash-max-ziplist-value：当 key 与 value 的长度都小于该值时使用 ziplist 编码（默认为 64）
hash-max-ziplist-entries：当 hash 中的元素数量小于该值时使用 ziplist 编码（默认为 512）

key 长度超过 64 的状况：

127.0.0.1:6379> HSET table x 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
(integer) 0
127.0.0.1:6379> OBJECT ENCODING table
"ziplist"
127.0.0.1:6379> HSET table x 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
(integer) 0
127.0.0.1:6379> OBJECT ENCODING table
"hashtable"
127.0.0.1:6379> DEL table
(integer) 1
127.0.0.1:6379> HSET table xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 'x'
(integer) 1
127.0.0.1:6379> OBJECT ENCODING table
"ziplist"
127.0.0.1:6379> HSET table xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 'x'
(integer) 1
127.0.0.1:6379> OBJECT ENCODING table
"hashtable"

value 长度超过 64 的状况：

127.0.0.1:6379> HSET table x 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
(integer) 0
127.0.0.1:6379> OBJECT ENCODING table
"ziplist"
127.0.0.1:6379> HSET table x 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
(integer) 0
127.0.0.1:6379> OBJECT ENCODING table
"hashtable"
127.0.0.1:6379> DEL table
(integer) 1
127.0.0.1:6379> HSET table xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 'x'
(integer) 1
127.0.0.1:6379> OBJECT ENCODING table
"ziplist"
127.0.0.1:6379> HSET table xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 'x'
(integer) 1
127.0.0.1:6379> OBJECT ENCODING table
"hashtable"

元素数量度超过 512 的状况：

127.0.0.1:6379> EVAL "for i=1,512 do redis.call('HSET', KEYS[1], i, i) end" 1 numbers
(nil)
127.0.0.1:6379> HLEN numbers
(integer) 512
127.0.0.1:6379> OBJECT ENCODING numbers
"ziplist"
127.0.0.1:6379> DEL numbers
(integer) 1
127.0.0.1:6379> EVAL "for i=1,513 do redis.call('HSET', KEYS[1], i, i) end" 1 numbers
(nil)
127.0.0.1:6379> HLEN numbers
(integer) 513
127.0.0.1:6379> OBJECT ENCODING numbers
"hashtable"

set 类型

set 的编码类型有 OBJ_ENCODING_INTSET intset 与 OBJ_ENCODING_HT hashtable，具体使用哪一种编码受下面两个选项控制：

当 set 中的全部元素都是整数时考虑使用 intset 编码，不然只能使用 hashtable 编码
set-max-intset-entries：当 set 中的元素数量小于该值时使用 intset 编码（默认为 512）

包含非整数元素的状况：

127.0.0.1:6379> SADD set 1 2
(integer) 2
127.0.0.1:6379> OBJECT ENCODING set
"intset"
127.0.0.1:6379> SADD set "ABC"
(integer) 1
127.0.0.1:6379> OBJECT ENCODING set
"hashtable"

元素数量度超过 512 的状况：

127.0.0.1:6379> EVAL "for i=1,512 do redis.call('SADD', KEYS[1], i, i) end" 1 numbers
(nil)
127.0.0.1:6379> SCARD numbers
(integer) 512
127.0.0.1:6379> OBJECT ENCODING numbers
"intset"
127.0.0.1:6379> DEL numbers
(integer) 1
127.0.0.1:6379> EVAL "for i=1,513 do redis.call('SADD', KEYS[1], i, i) end" 1 numbers
(nil)
127.0.0.1:6379> SCARD numbers
(integer) 513
127.0.0.1:6379> OBJECT ENCODING numbers
"hashtable"

zset 类型

set 的编码类型有 OBJ_ENCODING_ZIPLIST ziplist 与 OBJ_ENCODING_SKIPLIST skiplist。

使用 ziplist 编码时，每一个集合元素使用两个相邻的 entry 节点保存，第一个节点保存成员值 member，第二节点保存元素的分值 score，而且 entry 按照 score 从小到大进行排序：

+----------------------+
|     redisObject      |
+----------------------+
|         type         |
|      REDIS_ZSET      |
+----------------------+
|       encoding       |
| OBJ_ENCODING_ZIPLIST |
+----------------------+      +----------+----------+---------+--------------------+-------------------+-----+-----------------------+--------------------+-------+
|          ptr         | ---> |  zlbytes |  zltail  |  zllen  | entry 1 (member 1) | entry 2 (score 1) | ... | entry 2N-1 (member N) | entry 2N (score N) | zlend |
+----------------------+      +----------+----------+---------+--------------------+-------------------+-----+-----------------------+--------------------+-------+
                                                               >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> score increase >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

使用 skiplist 实现时，使用会使用一个名为 zset 的数据结构：

typedef struct zset {
        dict *dict;      // 维护 member -> score 的映射，查找给的成员的分值
        zskiplist *zsl;  // 按 score 大小保存了全部集合元素，支持范围操做
    } zset; // dict 与 zsl 会共享成员与分值

+----------------------+                                       +--------+     +------------+    +---------+
|     redisObject      |                                   +-->| dictht |     |  StringObj | -> |  long   |
+----------------------+                       +-------+   |   +--------+     +------------+    +---------+
|         type         |                   +-->| dict  |   |   | table  | --> |  StringObj | -> |  long   |
|      REDIS_ZSET      |                   |   +-------+   |   +--------+     +------------+    +---------+
+----------------------+                   |   | ht[0] | --+                  |  StringObj | -> |  long   |
|       encoding       |      +--------+   |   +-------+      +-----+         +------------+    +---------+
| OBJ_ENCODING_ZIPLIST |      |  zset  |   |                  | L32 | -> NULL
+----------------------+      +--------+   |                  +-----+
|          ptr         | ---> |  dict  | --+                  | ... |
+----------------------+      +--------+       +--------+     +-----+    +-----------+                     +-----------+
                              |  zsl   | --->  | header | --> | L4  | -> |     L4    | ------------------> |     L4    | -> NULL
                              +--------+       +--------+     +-----+    +-----------+                     +-----------+
                                               | tail   |     | L3  | -> |     L3    | ------------------> |     L3    | -> NULL
                                               +--------+     +-----+    +-----------+    +-----------+    +-----------+
                                               | level  |     | L2  | -> |     L2    | -> |     L2    | -> |     L2    | -> NULL
                                               +--------+     +-----+    +-----------+    +-----------+    +-----------+
                                               | length |     | L1  | -> |     L1    | -> |     L1    | -> |     L1    | -> NULL
                                               +--------+     +-----+    +-----------+    +-----------+    +-----------+
                                                                 NULL <- |     BW    | <- |     BW    | <- |     BW    |
                                                                         +-----------+    +-----------+    +-----------+
                                                                         | StringObj |    | StringObj |    | StringObj |
                                                                         +-----------+    +-----------+    +-----------+
                                                                         |    long   |    |    long   |    |    long   |
                                                                         +-----------+    +-----------+    +-----------+

zset 具体使用哪一种编码受下面两个选项控制：

zset-max-ziplist-value：当 member 的长度都小于该值时使用 ziplist 编码（默认为 64）
zset-max-ziplist-entries：当 zset 中的元素数量小于该值时使用 ziplist 编码（默认为 128)

Redis 总体结构

每一个数据库都是一个 redisDb 结构体：

typedef struct redisDb {
        dict *dict;                 /* 据库的键空间 keyspace */
        dict *expires;              /* 设置了过时时间的 key 集合 */
        dict *blocking_keys;        /* 客户端阻塞等待的 key 集合 (BLPOP)*/
        dict *ready_keys;           /* 已就绪的阻塞 key 集合 (PUSH) */
        dict *watched_keys;         /* 在事务中监控受监控的 key 集合 */
        int id;                     /* 数据库 ID */
        long long avg_ttl;          /* 平均 TTL, just for stats */
        unsigned long expires_cursor; /* 过时检测指针 */
        list *defrag_later;         /* 内存碎片回收列表 */
    } redisDb;

redis 全部数据库都保存着 redisServer.db 数组中，redisServer.dbnum 保存了数据库的数量，简化后的内存布局大体以下：

+-------------+
| redisServer |
+-------------+    +------------+------+-------------+
|     db      | -> | redisDb[0] | .... | redisDb[15] |
+-------------+    +------------+------+-------------+
|    dbnum    |      |
|     16      |      |
+-------------+      |  +---------+                         +------------+
                     +->| redisDb |                     +-> | ListObject |
                        +---------+    +------------+   |   +------------+
                        |  dict   | -> |  StringObj | --+
                        +---------+    +------------+       +------------+
                        | expires |    |  StringObj | ----> | HashObject |
                        +---------+    +------------+       +------------+
                              |        |  StringObj | --+
                              |        +------------+   |   +------------+
                              |                         +-> | StringObj  |
                              |                             +------------+
                              |
                              |       +------------+    +-------------+
                              +---->  |  StringObj | -> |    long     |
                                      +------------+    +-------------+
                                      |  StringObj | -> |    long     |
                                      +------------+    +-------------+

至此，redis 的几种编码方式都介绍完毕，后续将对 redis 的一些其余细节进行分享，感谢观看。