Redis原理(二) Redis的对象类型及其内部编码

Redis 支持 5 种对象类型，而每种结构都有至少两种编码。

这样做的好处在于：一方面接口与实现分离，当需要增加或改变内部编码时，用户使用不受影响，另一方面可以根据不同的应用场景切换内部编码，提高效率。

Redis 各种对象类型支持的内部编码官网描述：

Strings can be encoded as raw (normal string encoding) or int (strings representing integers in a 64 bit signed interval are encoded in this way in order to save space).

Lists can be encoded as ziplist or linkedlist. The ziplist is the special representation that is used to save space for small lists.

Sets can be encoded as intset or hashtable. The intset is a special encoding used for small sets composed solely of integers.

Hashes can be encoded as ziplist or hashtable. The ziplist is a special encoding used for small hashes.

Sorted Sets can be encoded as ziplist or skiplist format. As for the List type small sorted sets can be specially encoded using ziplist, while the skiplist encoding is the one that works with sorted sets of any size.

翻译如下表格：

类型	编码	对象
String	int	整数值实现
String	embstr	sds实现 <=39 字节
String	raw	sds实现 > 39字节
List	ziplist	压缩列表实现
List	linkedlist	双端链表实现
Set	intset	整数集合使用
Set	hashtable	字典实现
Hash	ziplist	压缩列表实现
Hash	hashtable	字典使用
Sorted set	ziplist	压缩列表实现
Sorted set	skiplist	跳跃表和字典

关于 Redis 内部编码的转换，都符合以下规律：编码转换在 Redis 写入数据时完成，且转换过程不可逆，只能从小内存编码向大内存编码转换。

String

字符串长度不能超过 512MB

字符串的两种编码中，对应的场景如下：

int：8 个字节的长整型。字符串值是整型时，这个值使用 long 整型表示。

embstr： <=39 字节

raw：> 39 个字节的字符串。

embstr 的使用只分配一次内存空间（因此 RedisObject 和 sds 是连续的），而 raw 需要分配两次内存空间（分别为 RedisObject 和 sds 分配空间）。

与 raw 相比，embstr 的好处在于创建时少分配一次空间，删除时少释放一次空间，以及对象的所有数据连在一起，寻找方便。

而如果字符串的长度增加需要重新分配内存时，整个 RedisObject 和 sds 都需要重新分配空间，因此 Redis 中的 embstr 实现为只读。

当 int 数据不再是整数，或大小超过了 long 的范围时，自动转化为 raw。

而对于 embstr，由于其实现是只读的，因此在对 embstr 对象进行修改时，都会先转化为 raw 再进行修改。

因此，只要是修改 embstr 对象，修改后的对象一定是 raw 的，无论是否达到了 39 个字节。（通过append 修改）

List

用来存储多个有序的字符串，每个字符串称为元素；一个列表可以存储 2^32-1 个元素。

Redis 中的列表支持两端插入和弹出，并可以获得指定位置（或范围）的元素，可以充当数组、队列、栈等。

双端链表：由一个 list 结构和多个 listNode 结构组成；典型结构如下图所示：

通过图中可以看出，双端链表同时保存了表头指针和表尾指针，并且每个节点都有指向前和指向后的指针。

链表中保存了列表的长度；dup、free 和 match 为节点值设置类型特定函数。

所以链表可以用于保存各种不同类型的值，而链表中每个节点指向的是type为字符串的 RedisObject。

压缩列表：压缩列表是 Redis 为了节约内存而开发的，是由一系列特殊编码的连续内存块(而不是像双端链表一样每个节点是指针)组成的顺序型数据结构，具体结构相对比较复杂。

与双端链表相比，压缩列表可以节省内存空间，但是进行修改或增删操作时，复杂度较高。

因此当节点数量较少时，可以使用压缩列表；但是节点数量多时，还是使用双端链表划算。

压缩列表不仅用于实现列表，也用于实现哈希、有序列表；使用非常广泛。

只有同时满足下面两个条件时，才会使用压缩列表：

• 列表中元素数量小于 512 个；
• 列表中所有字符串对象都不足 64 字节。

如果有一个条件不满足，则使用双端列表；且编码只可能由压缩列表转化为双端链表，反方向则不可能。

Hash

Redis作为key-value对外提供服务时，仅使用了hashtable。
而在Redis内部的Hash数据结构中使用的内部编码可以是压缩列表（ziplist）和哈希表（hashtable）2 种。

压缩列表前面已介绍，与哈希表相比，压缩列表用于元素个数少、元素长度小的场景；其优势在于集中存储，节省空间。

同时，虽然对于元素的操作复杂度也由 O(n)变为了 O(1)，但由于哈希中元素数量较少，因此操作的时间并没有明显劣势。

hashtable：一个 hashtable 由 1 个 dict 结构、2 个 dictht 结构、1 个 dictEntry 指针数组（称为 bucket）和多个 dictEntry 结构组成。

dictEntry 结构

//From https://github.com/antirez/redis/blob/fc0c9c8097a5b2bc8728bec9cfee26817a702f09/src/dict.h
typedef struct dictEntry {
    void *key;
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    struct dictEntry *next;
} dictEntry;

key：键值对中的键。

val：键值对中的值，使用 union(即共用体)实现，存储的内容既可能是一个指向值的指针，也可能是 64 位整型，或无符号 64 位整型。
next：指向下一个 dictEntry，用于解决哈希冲突问题。(解决哈希冲突类似于Java中的Map实现)

bucket：

bucket 是一个数组，数组的每个元素都是指向 dictEntry 结构的指针。

bucket 数组的大小计算规则如下：大于 dictEntry 的、最小的 2^n。

dictht 结构

//From  https://github.com/antirez/redis/blob/fc0c9c8097a5b2bc8728bec9cfee26817a702f09/src/dict.h

/* This is our hash table structure. Every dictionary has two of this as we
 * implement incremental rehashing, for the old to the new table. */
typedef struct dictht {
    dictEntry **table;
    unsigned long size;
    unsigned long sizemask;
    unsigned long used;
} dictht;

table 属性是一个指针，指向 bucket。

size 属性记录了哈希表的大小，即 bucket 的大小。

used 记录了已使用的 dictEntry 的数量。

sizemask 属性的值总是为
size-1，这个属性和哈希值一起决定一个键在 table 中存储的位置。

dict结构

一般来说，通过使用 dictht 和 dictEntry 结构，便可以实现普通哈希表的功能。Java中的Map实现就类似这种。

但是 Redis 的实现中，在 dictht 结构的上层，还有一个 dict 结构。下面说明 dict 结构的定义及作用。

//From https://github.com/antirez/redis/blob/fc0c9c8097a5b2bc8728bec9cfee26817a702f09/src/dict.h

typedef struct dict {
    dictType *type;
    void *privdata;
    dictht ht[2];
    long rehashidx; /* rehashing not in progress if rehashidx == -1 */
    unsigned long iterators; /* number of iterators currently running */
} dict;

type 属性和 privdata 属性是为了适应不同类型的键值对，用于创建多态字典。

ht 属性和 trehashidx 属性则用于 rehash，即当哈希表需要扩展或收缩时使用。

ht 是一个包含两个项的数组，每项都指向一个 dictht 结构，这也是 Redis 的哈希会有 1 个 dict、2 个 dictht 结构的原因。

通常情况下，所有的数据都是存在放 dict 的 ht[0] 中，ht[1] 只在 rehash 的时候使用。

dict 进行 rehash 操作的时候，将 ht[0] 中的所有数据 rehash 到 ht[1] 中。然后将 ht[1] 赋值给 ht[0]，并清空 ht[1]。

因此，Redis 中的哈希之所以在 dictht 和 dictEntry 结构之外还有一个 dict 结构，一方面是为了适应不同类型的键值对，另一方面是为了 rehash。

哈希中元素数量小于 512 个；哈希中所有键值对的键和值字符串长度都小于 64 字节。这时会使用性能更加的压缩列表。

如果有一个条件不满足，则使用哈希表；且编码只可能由压缩列表转化为哈希表，反方向则不可能。

Set

集合（set）与列表类似，都是用来保存多个字符串，但集合与列表有两点不同：集合中的元素是无序的，因此不能通过索引来操作元素；集合中的元素不能有重复。

一个集合中最多可以存储 2^32-1 个元素；除了支持常规的增删改查，Redis 还支持多个集合取交集、并集、差集。

集合的内部编码可以是整数集合（intset）或哈希表（hashtable）。

当集合在使用哈希表时，值全部被置为 null。

intset

//From https://github.com/antirez/redis/blob/fc0c9c8097/src/intset.h

typedef struct intset {
    uint32_t encoding;
    uint32_t length;
    int8_t contents[];
} intset;

encoding 代表 contents 中存储内容的类型（int16_t、int32_t 或 int64_t）

length 表示元素个数

整数集合适用于集合所有元素都是整数且集合元素数量较小的时候，与哈希表相比，整数集合的优势在于集中存储，节省空间。

当集合中元素数量小于 512个，集合中所有元素都是整数值时会使用整数集合。

如果有一个条件不满足，则使用哈希表；且编码只可能由整数集合转化为哈希表，反方向则不可能。

Sorted Set

有序集合与集合一样，元素都不能重复；但与集合不同的是，有序集合中的元素是有顺序的。

与List使用索引下标作为排序依据不同，有序集合为每个元素设置一个分数（score）作为排序依据。

有序集合的内部编码可以是压缩列表（ziplist）或跳跃表（skiplist）。

跳跃表是一种有序数据结构，通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的。

除了跳跃表，实现有序数据结构的另一种典型实现是平衡树；大多数情况下，跳跃表的效率可以和平衡树媲美，且跳跃表实现比平衡树简单很多，因此 Redis 中选用跳跃表代替平衡树。

跳跃表支持平均 O(logN)、最坏 O(N) 的复杂点进行节点查找，并支持顺序操作。

Redis 的跳跃表实现由 zskiplist 和 zskiplistNode 两个结构组成：前者用于保存跳跃表信息（如头结点、尾节点、长度等），后者用于表示跳跃表节点。

当有序集合中元素数量小于 128个；有序集合中所有成员长度都不足 64 字节时会使用压缩列表。

如果有一个条件不满足，则使用跳跃表；且编码只可能由压缩列表转化为跳跃表，反方向则不可能。