Redis数据结构详解(2)-redis中的字典dict

前提知识🧀

字典,又被称为符号表(symbol table)或映射(map),其实简单地可以理解为键值对key-value

比如Java的常见集合类HashMap,就是用来存储键值对的。

字典中的键(key)都是唯一的,由于这个特性,我们可以根据键(key)查找到对应的值(value),又或者进行更新和删除操作。

 

字典dict的实现

Redis的字典使用了哈希表作为底层实现,一个哈希表里面可以有多个哈希表节点,每个节点也保存了对应的键值对。

Redis的字典dict结构如下:

typedef struct dict { //类型特定函数 //是一个指向dictType结构的指针,可以使dict的key和value能够存储任何类型的数据 dictType *type; //私有数据 //私有数据指针,不是讨论的重点,暂忽略 void *privdata; //哈希表 dictht ht[2]; //rehash 索引 //当 rehash 不在进行时,值为 -1 int rehashidx; }

 

我们重点关注两个属性就可以:

  • ht 属性:

可以看到ht属性是一个 size为2dictht哈希表数组,在平常情况下,字典只用到 ht[0],ht[1] 只会在对 ht[0] 哈希表进行rehash时才会用到。

  • rehashidx 属性:

它记录了rehash目前的进度,如果现在没有进行rehash,那么它的值为-1,可以理解为rehash状态的标识。

 

下图就是一个普通状态下的字典:

实际的数据在 ht[0] 中存储;ht[1] 起辅助作用,只会在进行rehash时使用,具体作用包括rehash的内容我们会在后面进行详细介绍。

 

哈希算法定位索引

PS:如果你有HashMap的相关知识,知道如何计算索引值,那么你可以跳过这一部分。

 

假如我们现在模拟将 hash值从0到5的哈希表节点 放入 size为4的哈希表数组 中,也就是将包含键值对的哈希表节点放在哈希表数组的指定索引上。

对应索引的计算公式:

index = hash & ht[x].sizemask

 

看不懂没关系,可以简单的理解为hash值对哈希表数组的size值求余;

比如上面 hash值为0的节点,0 % 4 = 0,所以放在索引0的位置上,

hash值为1的节点,1 % 4 = 1,所以放在索引1的位置上,

hash值为5的节点,5 % 4 = 1,也等于1,也会被分配在索引1的位置上,并且因为dictEntry节点组成的链表没有指向链表表尾的指针,所以会将新节点添加在链表的表头位置,排在已有节点的前面。

 

我们把上面索引相同从而形成链表的情况叫键冲突,而且因为形成了链表!那么就意味着查找等操作的复杂度变高了!

例如你要查找hash=1的节点,你就只能先根据hash值找到索引为1的位置,然后找到hash=5的节点,再通过next指针才能找到最后的结果,也就意味着键冲突发生得越多,查找等操作花费的时间也就更多。

如果解决键冲突?rehash!

其实rehash操作很好理解,可以简单地理解为哈希表数组扩容或收缩操作,即将原数组的内容重新hash放在新的数组里

比如还是上面的数据,我们这次把它们放在 size等于8的哈希表数组 里。

如下图,此时size = 8,hash为5的键值对,重新计算索引:5 % 8 = 5,所以这次会放在索引5的位置上。


那么假如我们还要找hash=1的节点,因为没有键冲突,自然也没有链表,我们可以直接通过索引来找到对应节点。

可以看到,因为rehash操作数组扩容的缘故,键冲突的情况少了,进而我们可以更高效地进行查找等操作。

 

触发rehash操作的条件

首先我们先引入一个参数,叫做负载因子(load_factor),要注意的是:它与HashMap中的负载因子代表的含义不同;在HashMap里负载因子loadFactor作为一个默认值为0.75f的常量存在,而在redis的dict这里,它是一个会动态变化的参数,等于哈希表的 used属性值/size属性值,也就是 实际节点数/哈希表数组大小。假如一个size为4的哈希表有4个哈希节点,那么此时它的负载因子就是1;size为8的哈希表有4个哈希节点,那么此时它的负载因子就是0.5。

 

满足下面任一条件,程序就会对哈希表进行rehash操作:

  • 扩容操作条件:
    • 服务器目前没有执行 BGSAVE 或者 BGREWRITEAOF 命令,负载因子大于等于1。
    • 服务器目前正在执行 BGSAVE 或者 BGREWRITEAOF 命令,负载因子大于等于5。
  • 收缩操作条件:
    • 负载因子小于0.1时。

 

BGSAVE 和 BGREWRITEAOF 命令可以统一理解为redis的实现持久化的操作。

  • BGSAVE 表示通过fork一个子进程,让其创建RDB文件,父进程继续处理命令请求。
  • BGREWRITEAOF 类似,不过是进行AOF文件重写。

 

渐进式rehash?rehash的过程是怎么样的?

首先我们知道redis是单线程,并且对性能的要求很高,但是rehash操作假如碰到了数量多的情况,比如需要迁移百万、千万的键值对,庞大的计算量可能会导致服务器在一段时间里挂掉!

为了避免rehash对服务器性能造成影响,redis会分多次、渐进式地进行rehash,即渐进式rehash。

(可以理解粗略地理解为程序有空闲再来进行rehash操作,不影响其他命令的正常执行)

 

对哈希表进行渐进式rehash的步骤如下:

  1. 首先为 ht[1] 哈希表分配空间,size的大小取决于要执行的操作,以及 ht[0] 当前的节点数量(即ht[0]的used属性值):
    • 扩展操作,ht[1]的size值为第一个大于等于ht[0].used属性值乘以2的 2^n
    • 收缩操作,ht[1]的size值为第一个小于ht[0].used属性值的 2^n

(有没有很熟悉,其实跟Java中的HashMap、ConcurrentHashMap操作类似)

  1. 将哈希表的rehashidx值从-1置为0,表示rehash工作开始。
  2. 节点转移,重新计算键的hash值和索引值,再将节点放置到ht[1]哈希表的对应索引位置上。
  1. 每次rehash工作完成后,程序会将rehashidx值加一。

(这里的每次rehash就指渐进式rehash)

  1. 当ht[0]的所有节点都转移到ht[1]之后,释放ht[0],将ht[1]设置为ht[0],并在ht[1]新创建一个空白的hash表,等待下次rehash再用到。(其实就是数据转移到ht[1]后,再恢复为 ht[0]储存实际数据,ht[1]为空白表的状态)
  2. 最后程序会将rehashidx的值重置为-1,代表rehash操作已结束。

 

 

进行渐进式rehash的时候会影响字典的其他操作吗?

因为在进行渐进式rehash的时候,字典会同时用到ht[0]和ht[1]这两个哈希表,所以在这期间,字典的删除(delete)、查找(find)、更新(update)等操作会在两个哈希表进行;而进行添加操作时,会直接插入到ht[1]。

 

比如查找一个键时,程序会先在ht[0]里面查找,没找到的话再去ht[1]里进行查找。

 

搜资料的时候还看到好多评论,都对逻辑产生了疑问,还举了例子说有问题,但我仔细看了下,其实都是忽略了删除和更新都会在两个哈希表进行的前提条件。

 

 

写在最后的最后

我是苏易困,大家也可以叫我易困,一名Java开发界的小学生,文章可能不是很优质,但一定会很用心。

 

距离上次更新都过去了好久,一是因为上海的疫情有点严重,一直没静下心来好好整理知识,还有就是发现自己得先很好地消化完知识才能够整理出来,不然其实各方面收获不大;所以后面也会自己先认真消化后再整理分享,不会追求速度,但会认真总结整理。

 

因为疫情要一直封到4月1号,我们小区还有1例阳性,更不知道到什么时候了,每天早上也要定闹钟抢菜,但还抢不到,因为没有绿叶菜的补给,我感觉已经得口腔溃疡了,还好买到了维C泡腾片,感觉可以稍微缓缓。

 

疫情掰扯这么多,其实我和大家一样,我有想吃的美食,有想去的地方,更有马上想见到的人,所以最后还是希望疫情能够赶紧好起来~

 

本网页由快兔兔AI采集器生成,目的为演示采集效果,若侵权请及时联系删除。

原文链接:https://www.cnblogs.com/yichkhun/p/16068410.html

更多内容