Redis 数据类型底层结构
1 前言
本文将在熟悉使用redis的基本数据结构的基础上,对redis的五种数据类型底层结构进行分析。本次基于redis-3.2.1版本。后续所有讲解如不做特殊说明,都是基于此版本。
2 redis数据库的存储结构
2.1 引言
在了解redis的数据结构原理时,有必要先了解Redis的数据存储结构。redis是一种使用K-V形式做数据存储的数据库。正如Mysql底层使用B+来维护索引和数据的对应关系。redis则使用hash表存储K-V数据(C源码中也叫字典dict)。
我们知道,hash表是一种O(1)时间复杂度的数据结构。其底层是基于数组结构; redis中将hash表中的每一个元素都封装成了entry对象,其对象中保存了实际的key-Value数据。其结构如下所示:
![(E:\java_study\redis\底层数据结构\hashtable结构.png)
说到这里,我们已经明白redis数据库是使用hash表来存储的,那么redis底层又是如何对redisDB和hashtable进行封装的呢?
2.2 redis数据库的底层结构分析
- redisDb
/* Redis database representation. There are multiple databases identified
* by integers from 0 (the default database) up to the max configured
* database. The database number is the 'id' field in the structure. */
typedef struct redisDb {
dict *dict; /* The keyspace for this DB */ //字典对象
dict *expires; /* Timeout of keys with a timeout set */ //过期时间
//用于list类型的阻塞操作
dict *blocking_keys; /* Keys with clients waiting for data (BLPOP) */
//用于list类型的阻塞操作
dict *ready_keys; /* Blocked keys that received a PUSH */
dict *watched_keys; /* WATCHED keys for MULTI/EXEC CAS */
struct evictionPoolEntry *eviction_pool; /* Eviction pool of keys */
int id; /* Database ID */
PORT_LONGLONG avg_ttl; /* Average TTL, just for stats */
} redisDb;
上图为redis源码中对其DB库中定义数据类型和字段。可以看出在dictEntry结构体中有一个字典类型字段dictEntry,该字段就是redis存放K-V数据的hashtable。我们进入到dict类型中查看。
- dict
typedef struct dict {
dictType *type; //存储了一下hashtable的函数操作,包括对key的hash以及比较key的函数等
void *privdata;
dictht ht[2]; //两个字典对象,其中ht[1]的内存是ht[0]的两倍,用于渐进式rehash使用
//记录rehash 进度的标志,值为-1表示rehash未进行
PORT_LONG rehashidx; /* rehashing not in progress if rehashidx == -1 */
int iterators; /* number of iterators currently running */
} dict;
上图为redis中hashtable具体的数据结构。各个字段都已标注注释。其中最为重要的两个字段分别是dictht ht[2]和rehashidx。其中字段ht便是redis的hashtable。至于为什么是两个ht以及rehashidx字段,都是为了渐进式rehash做准备。该部分将在下面详细讲解
- dictht
/* 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; //hash表
PORT_ULONG size; //hash表大小
PORT_ULONG sizemask; // 等于size - 1;会用于后续与hash一起确定该数据存放的索引位
PORT_ULONG used; //hash表中已使用的大小
} dictht;
经过上面的分析,我们已经明白了字段ht就是redis中的hastable.我们进一步跟进到dictht 这个结构体中。结构如上图。可以明显的看到。redis的hashtable对象中定义了一个 dictEntry对象,到这里我们就豁然开朗了,和我们认知的hashtable结构一致。因此,我们可以大胆猜测,dictEntry字段一定 定义了我们的key和value字段。我们进入到dictEntry字段查看。
- dictEntry
typedef struct dictEntry {
void *key; //redis的key 封装为SDS
union {
void *val; //value, 指向底层数据结构
uint64_t u64;
int64_t s64;
double d;
} v;
struct dictEntry *next; //hash冲突时指向下一个数据节点
} dictEntry;
从图中可以看出,dictEntry字段定了我们存入的key字段和value字段。
- redisObject
typedef struct redisObject {
unsigned type:4; //记录了该对象的类型
unsigned encoding:4; //表示ptr指针指向的具体使用到的数据结构
unsigned lru:LRU_BITS; /* lru time (relative to server.lruclock) */ //对象最后一次被访问的时间
int refcount; // 引用计数
void *ptr; //指向实际值的指针
} robj;
redisObject是redis中封装value的对象,其每个存入到redis中的value都会被封装成redisObject对象保存;其内存也包含了五个字段:
1、type:用于表示该对象的类型,其包含了string、list、hash、set、zset等;
2、encoding:表示ptr指针指向的具体使用到的数据结构,也就是value用什么底层数据类型存储的;
3、lru:对象最后一次被访问的时间,用户后续的过期策略;
4、refcount:引用计数器;表明了redis中的垃圾回收算法是使用了引用计数法完成的;因C语言中不存在
5、ptr指针:指向实际保存数据的底层结构对象;
那么问题来了:我们在学习JVM的时候已经知道了,引用计数法这种垃圾回收机制虽然效率很高,但是不能解决循环依赖的问题,因此可能会导致内存泄漏,那么为什么redis还要使用这种gc算法呢?
从上面的对redis的结构分析可知,redis中每个key-value都对应这一个底层数据结构来维护,所以就不会出现循环引用的情况了;
2.3 总结
通过上面层层递进的结构体类型,我们对redis的底层数据库的结构已经有了深刻的认识。下面对着四种结构体进行总结归纳。
- redisDb :redis的顶层数据库结构,内部定义了数据存储结构字典dict,过期时间、用于阻塞key以及事务相关的监听。
- dict :用于存储redis中的k-v数据的字段结构。其中定义了两个hashtable和rehash下标值。
- dictht : redis中真正的hash表,二维数组结构,内部定义了存储k-v的entry、数组长度、确定数据存放位置的模、数组内的数据量。
- dictEntry :用于存储k-v数据的entry对象,内部封装了key、value字段,以及用于处理hash冲突的指针。
- redisObject:用于封装value数字的对象;其内部包含了value的命令类型、底层存储结构、回收策略、lru信息等;
我们可以用下图清晰的描述各个结构体的包含关系
3 redis中的hash冲突
到此为止,redis底层的数据库结构我们已经了解了。于此同时也存在了一些困惑,只要使用hash,就一定会存在hash冲突,因此又引入了另一个话题:redis是如何解决hash冲突的呢。他和java中的hashMap的处理方式是否一样呢?下面我们一起来探讨。
通过上面对redis护具库结构的分析,我们可以发现在dictEntry结构体中定义了next字段并且还是一个dictEntry类型的指针。以此可以得出redis是采用了拉链法来解决hash冲突。
但是读过hashMap源码的同学应该知道,hashMap解决hash冲突的方式也是拉链法,但是当同一分支hash冲突过多,就会导致生成的链表数据过长,从而使查询效率下降,hashMap中当链表长度超过8时就会装换为红黑树来增加查询效率。那么redis作为高效的查存数据库,是如何解决拉链法导致的查询效率下降的呢?
3.1 incremental rehashing——渐进式rehash
在经过对redis底层的数据库结构梳理后,可以发现在dict结构体中定义了两个hashtable。所以redis是通过渐进式rehash来解决解决链表过长带来的问题。
当第一个hashtable中的元素数量达到了其容量时,redis会生成比当前hashtab容量大1倍的新hashtable,然后把旧的hashtable中的数据转移到新的hashtable里,当旧数据全部迁移完毕后,旧hashtable内存将会释放,使用新的hashtable。在数据未全部迁移到新hashtable前,每次查询查询都会优先从旧的hashtable中获取。
但是由于redis在增删改查时时单线程处理,如果一次性全部rehash到新的hashtable中,但是数据量很大时,可能会阻塞主线程。因此redis采用了渐进式的rehash迁移。也即在每次读命令操作时,就会对当前的hash桶进行rehash迁移,直到旧的hashtable中无数据。这次会将dictht[0]内存释放。
值得注意的是,当redis进行rehash时由于会重新申请一块内存区域,所以在这段时间内,redis内存占比可能会明显增加。但是当rehash结束后,内存则会恢复到平均水位。
4 redis底层数据结构
下面汇总了redis底层现有在使用的底层数据结构
SDS | 简单动态字段串 |
---|---|
hashtable | 基于hash桶结构 |
intlist | 整形数组 |
ziplist | 压缩列表;对双向链表的改造,减少内存开销 |
quicklist | 快速列表;基于zipList的改造,减少zipList插入带来的性能问题 |
skiplist | 跳表;基于双向链表二分查找思想,建立多索引来增加检索效率 |
4.1 SDS
SDS是redis设计的一种保存字符串的数据结构,其内部结构定义如下图所示:
可以很明显的看到,sds已经记录了所存储的字符串长度大小,并且使用可扩容字符数组存储字符串;SDS相对于原有C中的字符串有哪些优势呢?
1、效率高
C中要获取字符串的长度需要遍历整个字符串,时间复杂度是O(n),而sds内部的len已经记录了字符串的长度,因此查询的时间复杂度是O(1);
2、安全的动态扩容
C中如果想对一个字符串进行修改(增加字符串长度),那么如果不事先指定好内存大小,有可能出现内存溢出,进而可能覆盖其他的字符串数据,对数据不安全;而sds可以在修改字符串之前先进行内存预估,如果该字符串内存大小不足以保存修改后的大小,就会进行自动扩容来避免出现内存溢出的问题;同时在每次扩容是会额外预留一下内存最为预留内存,以防止频繁的修改操作
3、二进制安全
由于C中字符串都是以’\0’结尾,因此如果保存的字符串中包含字符’\0’,那么C就会自动停止检索,直接返回该字符之前的数据,造成了数据截断;但是sds中的len字段由于保存了字符串的长度,因此sds判断字符串是否结束是按照len的大小判断的;所以对二进制数据是安全的;
4.2 hashtable
hashtable的底层实现我们已经较为熟悉,正如2.2节所示;并且关于使用hashtable可能会出现的hash冲突以及redis中的解决方案也已经详细说明;
4.3 intlist(整形数组)
整形数组在redis中使用的场景较少,只有set的数据类型中可能会使用到;该数据类型特点就是只能存储整形数据,同时redis中使用的整形数组会自动进行递增排序处理。
4.4 ziplist
ziplist数据结构是redis在linklist的基础上进行了改进,将双端指针改为使用数组存储,大大节省了内存开销;下面这段话为redis源码中对ziplist的介绍:
/* The ziplist is a specially encoded dually linked list that is designed
* to be very memory efficient. It stores both strings and integer values,
* where integers are encoded as actual integers instead of a series of
* characters. It allows push and pop operations on either side of the list
* in O(1) time. However, because every operation requires a reallocation of
* the memory used by the ziplist, the actual complexity is related to the
* amount of memory used by the ziplist.
*
* ----------------------------------------------------------------------------
*
* ZIPLIST OVERALL LAYOUT:
* The general layout of the ziplist is as follows:
* <zlbytes><zltail><zllen><entry><entry><zlend>
*
* <zlbytes> is an unsigned integer to hold the number of bytes that the
* ziplist occupies. This value needs to be stored to be able to resize the
* entire structure without the need to traverse it first.
*
* <zltail> is the offset to the last entry in the list. This allows a pop
* operation on the far side of the list without the need for full traversal.
*
* <zllen> is the number of entries.When this value is larger than 2**16-2,
* we need to traverse the entire list to know how many items it holds.
*
* <zlend> is a single byte special value, equal to 255, which indicates the
* end of the list.
从上面我们可以看出,ziplist是一种经过特殊编码的双链表,其非常节省内存。同时他可以存储字符串和整形数据;可以以O(1)的时间复杂度完成任一侧的push和pop操作;
注释中给出了ziplist的完整的数据结构,因此我们就可以很清楚的了解ziplist的结构构成。
虽然ziplist可以很大程度上减少内存开销,但是每次对ziplist的操作都会使其重新分配内存,因此ziplist的时间复杂度和实际使用的内存大小有关。
4.5 quicklist
上一小节我们已经知道当使用list命令插入一个元素时,会在ziplist中分配该元素的内存空间,而ziplist的内存空间又是连续的,如果待插入的元素的内存较大或者ziplist的元素个数过多时,会导致ziplist内存不足,从而触发扩容并进行内存重分配,导致效率严重下降。因此redis提出了quicklist来解决ziplist的内存重分配问题。
在redis的配置文件中,可以设置ziplist的存储节点的大小,当达到存储ziplist内存大小时,就会触发quicklist的节点分裂;其配置如下:
# Lists are also encoded in a special way to save a lot of space.
# The number of entries allowed per internal list node can be specified
# as a fixed maximum size or a maximum number of elements.
# For a fixed maximum size, use -5 through -1, meaning:
# -5: max size: 64 Kb <-- not recommended for normal workloads
# -4: max size: 32 Kb <-- not recommended
# -3: max size: 16 Kb <-- probably not recommended
# -2: max size: 8 Kb <-- good
# -1: max size: 4 Kb <-- good
# Positive numbers mean store up to _exactly_ that number of elements
# per list node.
# The highest performing option is usually -2 (8 Kb size) or -1 (4 Kb size),
# but if your use case is unique, adjust the settings as necessary.
list-max-ziplist-size -2
qiucklist数据结构就是双端链表,不同的是,其每个节点都是由ziplist组成,当ziplist的元素个数达到预设的上线时,就会分裂出一个新的ziplist,并使用双端列表关联。其结构图如下所示:
同时,为了更好的节省quicklist的内存消耗,redis还可以配置化的设置quicklist是否进行压缩(默认不进行压缩),其配置如下:
# Lists may also be compressed.
# Compress depth is the number of quicklist ziplist nodes from *each* side of
# the list to *exclude* from compression. The head and tail of the list
# are always uncompressed for fast push/pop operations. Settings are:
# 0: disable all list compression
# 1: depth 1 means "don't start compressing until after 1 node into the list,
# going from either the head or tail"
# So: [head]->node->node->...->node->[tail]
# [head], [tail] will always be uncompressed; inner nodes will compress.
# 2: [head]->[next]->node->node->...->node->[prev]->[tail]
# 2 here means: don't compress head or head->next or tail->prev or tail,
# but compress all nodes between them.
# 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail]
# etc.
list-compress-depth 0
值的注意的是,由于quicklist的两端都是进行会被访问到的,如果进行压缩的话会影响查询效率,所以其头尾两端是不参与压缩的;
1:表示从插入第一个节点开始进行压缩,也即压缩第一个节点;
2:不压缩头尾结点和头的下一个节点以及尾的上一个节点;也即从第2个节点和倒数第2个节点开始压缩;
3:表示从第3个节点和倒数第3个节点开始压缩;
…
n:表示从第n节点和倒数第n个节点开始压缩;
4.6 skiplist
跳表是特殊的双向链表,是redis用来解决ziplist低查询效率而设计的。其主要特点就是可以向上分裂出多级索引,从而达到快速检索的目的(其原理类似于二分查找思想)。
/* ZSETs use a specialized version of Skiplists */
//跳表节点组成
typedef struct zskiplistNode {
robj *obj; //元素成员 封装成redisObject对象
double score; //该元素成员对应的分数
struct zskiplistNode *backward; //后置指针
struct zskiplistLevel { //数组类型
struct zskiplistNode *forward; //指向下一个元素
unsigned int span; //与下一个元素的间隔
} level[];
} zskiplistNode;
//跳表结构组成
typedef struct zskiplist {
struct zskiplistNode *header, *tail; //头尾指针
PORT_ULONG length; //跳表最底层列表的节点数
int level; //记录当前跳表最高索引层
} zskiplist;
//zset结构组成
typedef struct zset {
dict *dict; //字典对象 用于保存value-> score的映射关系,方便通过O(1)复杂度根据元素获取对应的分数
zskiplist *zsl; //跳表对象
} zset;
从redis中可以看到zset的对象结构包含了字典对象和skiplist对象。其中这个字典对象dict是为了存储value和score的映射关系的,便于以O(1)的速度根据value获取对于的score值,其对应的命令为:ZSCORE 。
再进入skiplist对象查看,发现其一共包含四个字段:
1、header、tail: ziplist的头尾指针;
2、length:记录着跳表最底层列表的节点数;
3、level:记录了当前的最高索引层;
最后我们进入到保存节点数据的zskiplistNode对象中,其结构体中包含了四个字段:
1、obj:redisObject对象类型,其保存了value值;
2、score:value对应的分数;
3、backward:后置指针,用于前一个节点;连接上一个节点的指针;
4、level数组:用于建立索引位,其内部包含了一个签字节点forward:指向后置节点;一个span字段:用于保存与后一个节点的间隔不包括当前节点),主要用于进行排名使用,eg;ZRANK 、ZREVRANK 命令
在redis中,跳表升级一层索引时(每次插入数据的时候)采用随机的方式,并且随着索引的层数越高进行索引升级的概率就会越小。
第一次升级索引:P1 = 0.25
第二次升级索引:P2 = (1- 0.25)* P1
第三次升级索引:P3 = (1- 0.25)* P2
第N次升级索引:P = (1- 0.25)* P(n-1)
5 redis数据类型对应的底层数据结构关系
由于本文重在讲解redis的五种数据类型的底层结构,因此对redis的相关命令还不清楚的同学可以移步该网站熟悉即可: http://redisdoc.com/
下图展示了五种常用的数据类型和Redis底层的数据结构对于关系。从图中可以看出,除了string类型外,其他的数据类型至少有两种不同的底层结构。
上图为redis的五种常用数据类型使用到的底层数据结构;下面将分别讲解这五种数据类型;
5.1 string
string类型是redis中最为基础的数据类型,因此其底层使用的数据结构也是最简单的一个——动态字符串(SDS);
1、int编码:用于存储整形数据,是以Long类型存储,未使用SDS类型;
2、embstr:用于存储小于等于32字节的字符串值,其结构使用的是SDS结构;
3、raw:用于存储大于32字节的字符串值,其结构使用的是SDS结构;
5.2 hash
hash结构底层使用到了ziplist和hashtable两种数据结构;那么满足什么条件会使用哪种数据结构呢?满足一下任意条件时都会从ziplist转为hashtable。
1、ziplist元素个数超过512个;
2、单个元素大小超过64byte;
这两个阈值在redis的配置文件中都可以设置:
# Hashes are encoded using a memory efficient data structure when they have a
# small number of entries, and the biggest entry does not exceed a given
# threshold. These thresholds can be configured using the following directives.
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
- ziplist存储特点:当使用ziplist作为存储结构时,redis将field和value当做成两个元素分别放置在ziplist数组的前后节点处。
- 为什么使用ziplist:由于hashtable在内存方面比ziplist要高一些(多了指针),并且内存对redis来说至关重要,所以在数据量不大的前提下,使用了内存利用率更高的ziplist结构。
5.3 list
在redis3.2之后,redis使用qiucklist代替了原来的ziplist+linkedlist结构。因此3.22版本级以后,list命令的存储结构变为了单一的qiucklist结构;
因此为了这里补充分析一下3.2版本之前的list底层结构。本次使用2.8.9版本,在其配置文件中存在对应ziplist转linkedlist的阈值配置:
# Similarly to hashes, small lists are also encoded in a special way in order
# to save a lot of space. The special representation is only used when
# you are under the following limits:
list-max-ziplist-entries 512
list-max-ziplist-value 64
1、ziplist的节点数超过512个时;
2、ziplist中存储的单个节点内存大于64字节时;
当满足上述两个条件之一,就会将ziplist结构转为linkedlist;
5.4 set
redis对应set命令也进行了两层数据结构存储,分别是整形数组(intlist)和hashtable。其中前者只能存储整形数据,当数据为非整形时,就会转为hashtable结构存储。
当使用intlist进行存储时,redis会自动的进行递增排序。因此,对于只存储整形的set命令,其是一个有顺序的结构。
如果这个时候在test_set中插入一个非整形数据,那么该结构就会转变为hashtable,并且value的顺序也是随机的。同时hashtable的存储方式和java的hashset类似,用key存储数据,而value为null
![在这里插入图片描述](https://img-blog.csdnimg.cn/3df63e082b6640198e667545b7f50d12.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAMzNBMTE=,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center
但是,并不是我们一直使用整形存储时就会始终是intlist类型,因为这种结构是数组结构,所以当元素个数过多时会影响查询效率,因此redis在配置文件中对intlist的元素个数做了限制,当达到设定的元素个数时就会自动转为hashtable存储方式。默认是512个元素个数。
# Sets have a special encoding in just one case: when a set is composed
# of just strings that happen to be integers in radix 10 in the range
# of 64 bit signed integers.
# The following configuration setting sets the limit in the size of the
# set in order to use this special memory saving encoding.
set-max-intset-entries 512
5.5 zset
zset是工作中较为常用的结构类型,其底层存储结构也使用了两种,ziplist和skiplist。同时也存在切换关系:
# Similarly to hashes and lists, sorted sets are also specially encoded in
# order to save a lot of space. This encoding is only used when the length and
# elements of a sorted set are below the following limits:
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
满足一下条件任意一种,就会将ziplist结构转为skiplist:
1、ziplist存储的元素个数大于128个;
2、ziplist存储的单个节点数据内存超过64字节;
当使用ziplist存储数据时,其原理和hash一样,都是将value和score保存在ziplist的前后节点。
总结
以上便是关于redis中常用的五种类型底层的存储结构;关于第五节的描述也有一篇写的较好的博客大家可以阅读学习:https://www.cnblogs.com/qmillet/p/12494469.html