浅谈Redis五种资料结构的底层原理

概念Redis作为一个开源的用C编写的非关系型数据库，基于优秀的CRUD效率，常用于软件系统的快取，其本身提供了以下五种资料格式：

string：字串list：列表hash：散列表set：无序集合zset：有序集合接下来我们就要针对这五种资料结构，来分析其底层的结构

这里选用的版本是redis-5.0.4，所以可能有很多地方和如今网络上的其他博文不太一致，不同的地方我会在文中指出

string因为redis使用c语言开发，所以自然没有java和c++的那些字串类库，在redis中，其自己定义了一种字串格式，叫做SDS（Simple Dynamic String），即简单动态字串

这个结构定义在sds.h中：

typedef char *sds;

但是这个sds型别仅作为引数和返回值使用，并不是真正用于操作的型别，真正核心的部分是下面的这些类：

struct __attribute__ ((__packed__)) sdshdr5 { unsigned char flags; char buf; }; struct __attribute__ ((__packed__)) sdshdr8 { uint8_t len; uint8_t alloc; unsigned char flags; char buf; }; struct __attribute__ ((__packed__)) sdshdr16 { uint16_t len; uint16_t alloc; unsigned char flags; char buf; }; struct __attribute__ ((__packed__)) sdshdr32 { uint32_t len; uint32_t alloc; unsigned char flags; char buf; }; struct __attribute__ ((__packed__)) sdshdr64 { uint64_t len; uint64_t alloc; unsigned char flags; char buf; };

除掉第一个结构体（已经弃用），sds具体型别的结构可以分为以下部分：

len：已使用的长度，即字串的真实长度alloc：除去标头和终止符(\'\\0\')后的长度flags：低3位表示字串型别，其余5位未使用（我暂时没发现redis在哪里使用过这个属性）buf：储存字元资料这里和老版本做一下对比，因为我手头只有4.x和5.x的版本，它们sds的实现是一致的，但是据其他人说sds之前的版本实现方式不同，有时间我会去下载下来看一下，其将字串分为以下部分：

len：buf中已经占有的长度（表示此字串的实际长度）free：buf中未使用的缓冲区长度buf：实际储存字串资料的地方redis同时写重写了大量的与sds型别相关的方法，那redis为什么要这么下功夫呢，有以下4个优点：

降低获取字串长度的时间复杂度到O(1)减少了修改字串时的内存重分配次数相容c字串的同时，提高了一些字串工具方法的效率二进位制安全（资料写入的格式和读取的格式一致）list我们检视原始档可以看到有两个list，一个是ziplist，字面意是压缩列表，另一个是quicklist，字面意是快速列表，在redis中直接使用的是quicklist，但是我们先来看ziplist

ziplistziplist并不是一个类名，其结构是下面这样的： ...

其中各部分代表的含义如下：

zlbytes：4个字节（32bits），表示ziplist占用的总字节数zltail：4个字节（32bits），表示ziplist中最后一个节点在ziplist中的偏移字节数entries：2个字节（16bits），表示ziplist中的元素数entry：长度不定，表示ziplist中的资料zlend：1个字节（8bits），表示结束标记，这个值固定为ff（255）这些资料均为小端储存，所以可能有些人检视资料的二进位制流与其含义对应不上，其实是因为读资料的方式错了

ziplist内部采取资料压缩的方式进行储存，压缩方式就不是重点了，我们仅从宏观来看，ziplist类似一个封装的阵列，通过zltail可以方便地进行追加和删除尾部资料、使用entries可以方便地计算长度

但是其依然有阵列的缺点，就是当插入和删除资料时会频繁地引起资料移动，所以就引出了quicklist资料型别

quicklist其核心资料结构如下：

typedef struct quicklist { quicklistNode *head; quicklistNode *tail; unsigned long count; /* ziplist所有节点的个数 */ unsigned long len; /* quicklistNode节点的个数 */ int fill : 16; /* 单个节点的填充因子 */ unsigned int compress : 16; /* 压缩端结点的深度 */ } quicklist;

我们可以明显地看出，quicklist是一个双向连结串列的结构，但是内部又涉及了ziplist，我们可以这么说，在宏观上，quicklist是一个双向连结串列，在微观上，每一个quicklist的节点都是一个ziplist

在redis.conf中，可以使用下面两个引数来进行优化：

list-max-ziplist-size：表示每个quicklistNode的字节大小。预设为2，表示8KBlist-compress-depth：表示quicklistNode节点是否要压缩。预设为0，表示不压缩这种储存方式的优点和连结串列的优点一致，就是插入和删除的效率很高，而连结串列查询的效率又由ziplist来进行弥补，所以quicklist就成为了list资料结构的首选

hashhash这种结构在redis的使用时最为常见，在redis中，hash这种结构有两种表示：zipmap和dict

zipmapzipmap其格式形如下面这样： "foo""bar""hello""world"

各部分的含义如下：

zmlen：1个字节，表示zipmap的总字节数len：1~5个字节，表示接下来储存的字串长度free：1个字节，是一个无符号的8位数，表示字串后面的空闲未使用字节数，由于修改与键对应的值而产生这其中相邻的两个字串就分别是键和值，比如在上面的例子中，就表示"foo" => "bar", "hello" => "world"这样的对应关系

这种方式的缺点也很明显，就是查询的时间复杂度为O(n)，所以只能当作一个轻量级的hashmap来使用

dict这种方式就适于储存大规模的资料，其格式如下：

typedef struct dict { dictType *type;/* 指向自定义型别的指标，可以储存各型别资料 */ void *privdata; /* 私有资料的指标 */ dictht ht[2];/* 两个hash表，一般只有h[0]有效，h1[1]只在rehash的时候才有值 */ long rehashidx; /* -1：没有在rehash的过程中，大于等于0：表示执行rehash到第几步 */ unsigned long iterators; /* 正在遍历的迭代器个数 */ } dict;

如果我们不想更深入的话了解到这种程度就可以了，其中真正储存资料的是dictEntry结构，如下：

typedef struct dictEntry { void *key; union { void *val; uint64_t u64; int64_t s64; double d; } v; struct dictEntry *next; } dictEntry;

很明显是一个连结串列，我们知道这是采用链式结构储存就足够了

这种方式会消耗较多的内存，所以一般资料较少时会采用轻量级的zipmap

set在redis中，我们可以检视intset.h档案，这是一个储存整数的集合，其结构如下：

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

其中各字段含义如下：

encoding：资料编码格式，表示每个资料元素用几个字节储存（可取的值有2、4，和8）length：元素个数contents：柔性阵列，这部分内存单独分配，不包含在intset中具体的操作我们就不详细展开了，了解集合这种资料结构的应该都很清楚，我们这里说一下，intset有一个数据升级的概念，比方说我们有一个16位整数的set，这时候插入了一个32位整数，所以就导致整个集合都升级为32位整数，但是反过来却不行，这也就是柔性阵列的由来

如果集合过大，会采用dict的方式来进行储存

zsetzset，有很多地方也叫做sorted set，是一个键值对的结构，其键被称为member，也就是集合元素（zset依然是set，所以member不能相同），其对应的值被称为score，是一个浮点数，可以理解为优先级，用于排列zset的顺序

其也有两种储存方式，一种是ziplist/zipmap的格式，这种方式我们就不过多介绍了，只需要了解这种格式将资料按照score的顺序排列即可

另一种储存格式是采用了skiplist，意为跳跃表，可以看成平衡树对映的阵列，其查询的时间复杂度和平衡树基本没有差别，但是实现更为简单，形如下面这样的结构（图来源跳跃表的原理）：

作者：中关村的老男孩

原创：https://my.oschina.net/u/4142269/blog/3063416