作者: RyuGou 来自:互联网技术窝
redis有五种基本数据结构:字符串、hash、set、zset、list。但是你知道构成这五种结构的底层数据结构是怎样的吗?今天我们来花费五分钟的时间了解一下。(目前redis版本为3.0.6)
动态字符串SDS
SDS是"simple dynamic string"的缩写。redis中所有场景中出现的字符串,基本都是由SDS来实现的
- 所有非数字的key。例如 setmsg"hello world" 中的key msg.
- 字符串数据类型的值。例如`` set msg "hello world"中的msg的值"hello wolrd"
- 非字符串数据类型中的“字符串值”。例如 RPUSH fruits"apple""banana""cherry"中的"apple" "banana" "cherry"
SDS长这样:
![7f8bda5a65a0e7db2ddaf3ef365c1699.png](https://i-blog.csdnimg.cn/blog_migrate/3001b292165fdda933ac5b2b23eef0ec.jpeg)
free:还剩多少空间 len:字符串长度 buf:存放的字符数组
空间预分配
为减少修改字符串带来的内存重分配次数,sds采用了“一次管够”的策略:
- 若修改之后sds长度小于1MB,则多分配现有len长度的空间
- 若修改之后sds长度大于等于1MB,则扩充除了满足修改之后的长度外,额外多1MB空间
![ea8e0146b0707d0a9a60100755e56689.gif](https://i-blog.csdnimg.cn/blog_migrate/533550e256c6db6649f5174ae088c2a4.gif)
惰性空间释放
为避免缩短字符串时候的内存重分配操作,sds在数据减少时,并不立刻释放空间。
![81fa4961a885501b00d0417e1806394f.gif](https://i-blog.csdnimg.cn/blog_migrate/b924a45d75fd8185796cf506fb52aedc.gif)
int
就是redis中存放的各种数字 包括以下这种,故意加引号“”的
![bd2608ac5a4fb313f2081298a44aac63.png](https://i-blog.csdnimg.cn/blog_migrate/9411484db010fb01118b6bcb469bd303.jpeg)
双向链表
长这样:
![128759d0a8bac0dd3b56e7016b50efb0.png](https://i-blog.csdnimg.cn/blog_migrate/7147395a8df6bd6e2e0f6a79cd613d60.jpeg)
分两部分,一部分是“统筹部分”:橘黄色,一部分是“具体实施方“:蓝色。
主体”统筹部分“:
- head指向具体双向链表的头
- tail指向具体双向链表的尾
- len双向链表的长度
具体"实施方":一目了然的双向链表结构,有前驱 pre有后继 next
由 list和 listNode两个数据结构构成。
ziplist
压缩列表。redis的列表键和哈希键的底层实现之一。此数据结构是为了节约内存而开发的。和各种语言的数组类似,它是由连续的内存块组成的,这样一来,由于内存是连续的,就减少了很多内存碎片和指针的内存占用,进而节约了内存。
![e8978aa1f3bcaf460fbd960aeda320d1.png](https://i-blog.csdnimg.cn/blog_migrate/69566dbc728ee53711f73b99bf92092f.jpeg)
然后文中的 entry的结构是这样的:
![32cf71cc1937210b6f79595aac5a5ba4.png](https://i-blog.csdnimg.cn/blog_migrate/8928d20a0d5ae32bba01501326cdc309.jpeg)
元素的遍历
先找到列表尾部元素:
![8459bb8d9600ddefe76df9c7bc2b9cb6.gif](https://i-blog.csdnimg.cn/blog_migrate/80d845b82a3df2fd4a8a8b19171fbd5b.gif)
然后再根据ziplist节点元素中的 previous_entry_length属性,来逐个遍历:
![7ce83c8ba23261625ecfe6575733ddd1.gif](https://i-blog.csdnimg.cn/blog_migrate/5408e31cd780f62f1c2de1c8f8e67bbe.gif)
连锁更新
再次看看 entry元素的结构,有一个 previous_entry_length字段,他的长度要么都是1个字节,要么都是5个字节:
- 前一节点的长度小于254字节,则 previous_entry_length长度为1字节
- 前一节点的长度大于254字节,则 previous_entry_length长度为5字节
假设现在存在一组压缩列表,长度都在250字节至253字节之间,突然新增一新节点 new, 长度大于等于254字节,会出现:
![810fbdd2cdc5c2b4ac56076faa7adbd8.gif](https://i-blog.csdnimg.cn/blog_migrate/c660979fbadb1b9fd505f450ac3472e5.gif)
程序需要不断的对压缩列表进行空间重分配工作,直到结束。
除了增加操作,删除操作也有可能带来“连锁更新”。请看下图,ziplist中所有entry节点的长度都在250字节至253字节之间,big节点长度大于254字节,small节点小于254字节。
![ada75cdf429fe02aebf538ce093c4f7a.gif](https://i-blog.csdnimg.cn/blog_migrate/800acf31f6aa73b0f2a6400db5cdd397.gif)
哈希表
哈希表略微有点复杂。哈希表的制作方法一般有两种,一种是:开放寻址法,一种是 拉链法。redis的哈希表的制作使用的是 拉链法。
整体结构如下图:
![167bd78091e00f645ca960a41062ffaf.png](https://i-blog.csdnimg.cn/blog_migrate/fe7e86cd4426ebc512ff44c43a57f283.jpeg)
也是分为两部分:左边橘黄色部分和右边蓝色部分,同样,也是”统筹“和”实施“的关系。具体哈希表的实现,都是在蓝色部分实现的。先来看看蓝色部分:
![82f2b87e36c7a64486f3ca536608b64e.png](https://i-blog.csdnimg.cn/blog_migrate/c0627513006d46b5da03d75b693fb288.jpeg)
这也分为左右两边“统筹”和“实施”的两部分。
右边部分很容易理解:就是通常拉链表实现的哈希表的样式;数组就是bucket,一般不同的key首先会定位到不同的bucket,若key重复,就用链表把冲突的key串起来。
新建key的过程:
![35fbffb32be3d1999461e61404a722b0.gif](https://i-blog.csdnimg.cn/blog_migrate/0ed4d6487b889a3fb1c115fc3ed295e3.gif)
假如重复了:
![a105653cfc93bddc83ce2b4d84848ea6.gif](https://i-blog.csdnimg.cn/blog_migrate/55cb0c0f76c9bb265d91dcbf8285c6c7.gif)
rehash
再来看看哈希表总体图中左边橘黄色的“统筹”部分,其中有两个关键的属性:ht和 rehashidx。ht是一个数组,有且只有俩元素ht[0]和ht[1];其中,ht[0]存放的是redis中使用的哈希表,而ht[1]和rehashidx和哈希表的 rehash有关。
rehash指的是重新计算键的哈希值和索引值,然后将键值对重排的过程。
加载因子(load factor)=ht[0].used/ht[0].size。
扩容和收缩标准
扩容:
- 没有执行BGSAVE和BGREWRITEAOF指令的情况下,哈希表的 加载因子大于等于1。
- 正在执行BGSAVE和BGREWRITEAOF指令的情况下,哈希表的 加载因子大于等于5。
收缩:
- 加载因子小于0.1时,程序自动开始对哈希表进行收缩操作。
扩容和收缩的数量
扩容:
- 第一个大于等于 ht[0].used*2的 2^n(2的n次方幂)。
收缩:
- 第一个大于等于 ht[0].used的 2^n(2的n次方幂)。
(以下部分属于细节分析,可以跳过直接看扩容步骤)对于收缩,我当时陷入了疑虑:收缩标准是 加载因子小于0.1的时候,也就是说假如哈希表中有4个元素的话,哈希表的长度只要大于40,就会进行收缩,假如有一个长度大于40,但是存在的元素为4即( ht[0].used为4)的哈希表,进行收缩,那收缩后的值为多少?
我想了一下:按照前文所讲的内容,应该是4。但是,假如是4,存在和收缩后的长度相等,是不是又该扩容?翻开源码看看:
收缩具体函数:
![05737d6bec7616faeea93259d80a9dcb.png](https://i-blog.csdnimg.cn/blog_migrate/e55faceec3256ba0ecfd1b4114ac188d.jpeg)
![ef7629fd6064d00dea57e6a0b1e196bb.png](https://i-blog.csdnimg.cn/blog_migrate/25a650511a1187609918d0a12ab760f1.jpeg)
![85ce28f2166c4de115981b00e0adb51d.png](https://i-blog.csdnimg.cn/blog_migrate/63cd08989988761b8094e9f944ab1b66.jpeg)
由代码我们可以看到,假如收缩后长度为4,不仅不会收缩,甚至还会报错。()
我们回过头来再看看设定:题目可能成立吗?哈希表的扩容都是2倍增长的,最小是4, 4 ===》 8 ====》 16 =====》 32 ======》 64 ====》 128
也就是说:不存在长度为 40多的情况,只能是64。但是如果是64的话,64 X 0.1(收缩界限)= 6.4 ,也就是说在减少到6的时候,哈希表就会收缩,会缩小到多少呢?是8。此时,再继续减少到4,也不会再收缩了。所以,根本不存在一个长度大于40,但是存在的元素为4的哈希表的。
扩容步骤
![3cde634fc13f3001208f40db7a582bff.gif](https://i-blog.csdnimg.cn/blog_migrate/6962c8ef024d6c2fe60dd0cf7fdb5a2a.gif)
收缩步骤
![f5c9438e1f23a0871281e4bbb52774ad.gif](https://i-blog.csdnimg.cn/blog_migrate/03a41421b72440ffcc52f83cbd09697d.gif)
渐进式refresh
在"扩容步骤"和"收缩步骤" 两幅动图中每幅图的第四步骤“将ht[0]中的数据利用哈希函数重新计算,rehash到ht[1]”,并不是一步完成的,而是分成N多步,循序渐进的完成的。因为hash中有可能存放几千万甚至上亿个key,毕竟Redis中每个hash中可以存 2^32-1 键值对(40多亿),假如一次性将这些键值rehash的话,可能会导致服务器在一段时间内停止服务,毕竟哈希函数就得计算一阵子呢((#^.^#))。
哈希表的refresh是分多次、渐进式进行的。
渐进式refresh和下图中左边橘黄色的“统筹”部分中的 rehashidx密切相关:
- rehashidx 的数值就是现在rehash的元素位置
- rehashidx 等于 -1 的时候说明没有在进行refresh
![c3081c0572d88f38dcad83883277601f.png](https://i-blog.csdnimg.cn/blog_migrate/66f3782308c16bc1ae9ee29854e57320.jpeg)
甚至在进行期间,每次对哈希表的增删改查操作,除了正常执行之外,还会顺带将ht[0]哈希表相关键值对rehash到ht[1]。
以扩容步骤为例:
![155689c04d94c1f0f37e0382622ae20a.gif](https://i-blog.csdnimg.cn/blog_migrate/30accced5ceb7d4b56cc04b700dc9056.gif)
intset
整数集合是集合键的底层实现方式之一。
![f091da35b571e95951419821fe5e6217.png](https://i-blog.csdnimg.cn/blog_migrate/324becc0be76e11146ceea7e9f62845b.jpeg)
跳表
跳表这种数据结构长这样:
![3ac345df086809301bd3f47d8dd8979c.png](https://i-blog.csdnimg.cn/blog_migrate/1151ff4a8ce05dc01e9133a4605f1bce.jpeg)
redis中把跳表抽象成如下所示:
![8a5362b7979d1ed07c9801b3748d4676.png](https://i-blog.csdnimg.cn/blog_migrate/7ac5758e7c03c86c20a10dc0060df31a.jpeg)
看这个图,左边“统筹”,右边实现。统筹部分有以下几点说明:
- header: 跳表表头
- tail:跳表表尾
- level:层数最大的那个节点的层数
- length:跳表的长度
实现部分有以下几点说明:
- 表头:是链表的哨兵节点,不记录主体数据。
- 是个双向链表
- 分值是有顺序的
- o1、o2、o3是节点所保存的成员,是一个指针,可以指向一个SDS值。
- 层级高度最高是32。每次创建一个新的节点的时候,程序都会随机生成一个介于1和32之间的值作为level数组的大小,这个大小就是“高度”
redis五种数据结构的实现
redis对象
redis中并没有直接使用以上所说的各种数据结构来实现键值数据库,而是基于一种对象,对象底层再间接的引用上文所说的具体的数据结构。
结构如下图:
![82ef66ec461b9c66db8f87097d52f91e.png](https://i-blog.csdnimg.cn/blog_migrate/ea5e170ea5f930308ca85ac0376763ec.jpeg)
字符串
![ecd97d99b55ddb13193b8a2951953364.png](https://i-blog.csdnimg.cn/blog_migrate/60a38e82dc65bbe837a873bff8c95227.jpeg)
其中:embstr和raw都是由SDS动态字符串构成的。唯一区别是:raw是分配内存的时候,redisobject和 sds 各分配一块内存,而embstr是redisobject和raw在一块儿内存中。
列表
![eae9340b023e63c4c730f16c036ed670.png](https://i-blog.csdnimg.cn/blog_migrate/45f3adf294a5472d09338885ca4fad11.jpeg)
hash
![401d00b149e79e4e8162cabc973f8d86.png](https://i-blog.csdnimg.cn/blog_migrate/98fa7fb954432d8e1fc79b17635ceb69.jpeg)
set
![38b46405b6e0f0c21a01837bb6a3a576.png](https://i-blog.csdnimg.cn/blog_migrate/6732dcb8780014e31f0bacb92b281065.jpeg)
zset
![47e56b6aa910584ef4ac633e847c6882.png](https://i-blog.csdnimg.cn/blog_migrate/b05a16de6d62b659d8eea171e6606121.jpeg)