vlambda博客
学习文章列表

Redis-dict字典底层实现

小闭环,正反馈,持续输出第 10/100 天 | 深度 | 实践


正在晒太阳的【小鱼丸】,可太好撸了。


下面步入正题。

概览

Redis 本质是 K-V 键值对数据库,底层通过字典 dict 存储键值映射关系,除此之外,dict 还作为 Redis hash 结构底层的实现之一。

讨论 Redis 的数据结构,可以从两个层面出发。

第一个层面从使用者角度出发,即 Redis 暴露给外部调用的 Api:

stringlisthashsetsorted set

第二个层面是 Redis 的内部实现角度出发,是更为底层的数据结构实现:

dictsdsziplistquicklistskiplist

Redis 这么做的目的还是基于高性能的考虑,在不同的场景下使用不同的底层数据结构实现,最大程度提升内存操作的效率。

例如当 sorted set,hash 存储的数据规模较小时,底层都是通过 ziplist 实现,而当数据规模达到一定量时,sorted set 会转换成 dict + skiplist 的底层实现,hash 会转换成 dict 的底层实现。

本文主要讨论是 Redis 关于 dict 这一底层数据结构的实现原理。

实现

dict 的实现与 java jdk 中 hashmap 的实现有许多相似之处:

dict 在扩缩容的情况下,采用的是渐进式的 rehash 方式,这是它的特殊之处,下文会主要讲到。

dict 的数据结构如下:

type属性是一个指向dictType结构的指针,每个dictType结构保存了一簇用于操作特定类型键值对的函数,Redis会为用途不同的字典设置不同的类型特定函数privdata属性则保存了需要传给那些类型特定函数的可选参数ht[2] 数组中存放了两张哈希表,只有在 rehash 的过程中,ht[0] ht[1] 才都有效;正常情况下只有 ht[0] 有效,ht[1] 中没有任何数据rehashidx 用来表示 rehash 过程到了哪一个索引位置,正常情况下 rehashidx = -1,表示当前没有进行 rehash

Redis-dict字典底层实现

dictht 的数据结构如下:

dictEntry 数组,用来存放键值对size 表示当前 dictEntry 数组的大小sizemask,值为 size - 1,在计算 key 的索引位置时用到, index = hash & sizemaskused 记录现有 dict 的数据个数

Redis-dict字典底层实现

正常情况下,dict 整体的数据结构如下图所示:Redis-dict字典底层实现

rehash

随着操作不断执行,哈希表中的键值对会逐渐增加或减少,为了让哈希表的负载因子(负载因子 = 已保存节点数量/哈希表大小)维持在一个合理的范围内,当哈希表中节点数量过多或者过少时,Redis 会对哈希表进行相应的扩容或缩容,这一过程称为 rehash。

在 rehash 操作开始前,首先要为哈希表 ht[1] 分配内存,ht[1] 之前一直是空闲状态,终于要派上用场了,具体内存分配策略如下:

如果是扩容操作,ht[1]的大小为第一个大于等于ht[0].used*2的2^n(2的n次方幂),举个例子 ht[0].used = 5,触发了扩容操作,即 ht[1].size = 5 * 2 = 10,但 10 不符合 2^n 要求,则继续往下找到第一个符合要求的数 16,即 ht[1].size = 16如果是缩容操作,ht[1]的大小为第一个大于等于ht[0].used的2^n(2的n次方幂),举个例子 ht[0].used = 5,触发了缩容操作,则 ht[1].size = 8

ht[1] 分配完内存之后,接着进行如下操作:

将 ht[0] 的中的节点重新计算哈希值和索引值,映射到 ht[1] 上当ht[0]包含的所有键值对都迁移到了ht[1]之后(ht[0]变为空表),释放ht[0],将ht[1]设置为ht[0],并在ht[1]新创建一个空白哈希表,为下一次rehash做准备

哈希表触发扩容的时机如下:

服务器目前没有在执行BGSAVE命令或者BGREWRITEAOF命令,并且哈希表的负载因子大于等于1服务器目前正在执行BGSAVE命令或者BGREWRITEAOF命令,并且哈希表的负载因子大于等于5,这么做的原因是避免在子进程存在期间进行哈希表扩容操作,从而避免不必要的内存写入操作,最大限度节省内存

负载因子的计算公式:

Redis-dict字典底层实现

当负载因子小于 0.1 时,触发缩容操作。

渐进式rehash

值得注意的是 rehash 的过程,Redis 并不是一次性将所有元素集中式地 rehash 到 ht[1] 中,而是分多次,渐进式地完成。

这么做的原因是如果当哈希表中存放的键值对数量如果是千万级,甚至亿级,一次性完成所有键值的 rehash 操作,可能会导致 Redis 一段时间内对外不可用。

以下是渐进式 rehash 的具体步骤:

为ht[1]分配空间,让字典同时持有ht[0]和ht[1]两个哈希表在字典中维持一个索引计数器变量rehashidx,并将它的值设置为0,表示rehash工作正式开始在rehash进行期间,每次对字典执行添删改查操作时,程序除了执行指定的操作以外,还会顺带将ht[0]哈希表在rehashidx索引上的所有键值对rehash到ht[1],当rehash工作完成之后,程序将rehashidx属性的值增一随着字典操作的不断执行,最终在某个时间点上,ht[0]的所有键值对都会被rehash至ht[1],这时程序将rehashidx属性的值设为-1,表示此次rehash操作已完成

下面展示一次完整 rehash 的过程,首先初始化 dict,准备开始 rehash;

Redis-dict字典底层实现

rehashidx = 0,rehash 索引0对应的键值对,rehashidx + 1;Redis-dict字典底层实现

rehashidx = 1,rehash 索引1对应的键值对,rehashidx + 1;

Redis-dict字典底层实现

rehashidx = 2,rehash 索引2对应的键值对,rehashidx + 1;Redis-dict字典底层实现

最终完成 rehash 过程。




推荐阅读