【Redis】dict的渐进式rehash原理

1. 字典的实现

1.1 哈希表节点

hash表节点的定义如下

typedef struct dictEntry {
    // 键
    void *key;
    // 值
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
    } v;
    // 指向下个哈希表节点,形成链表
    struct dictEntry *next;
} dictEntry;

包含3个元素, key, v, next。 其中 v 的值可以是一个指针, uint64_t 整数, 或 int64_t 整数。next 属性是指向另一个hash表节点的指针。

【Redis】dict的渐进式rehash原理_第1张图片

 1.2 哈希表

hash表的定义如下

typedef struct dictht {
    // 哈希表数组
    dictEntry **table;
    // 哈希表大小
    unsigned long size;
    // 哈希表大小掩码,用于计算索引值
    // 总是等于 size - 1
    unsigned long sizemask;
    // 该哈希表已有节点的数量
    unsigned long used;
} dictht;
  • table 属性是一个数组, 数组中的每个元素都是一个指向 dict.h/dictEntry 结构的指针, 每个 dictEntry 结构保存着一个键值对。
  • size 属性记录了哈希表的大小, 也即是 table 数组的大小, 而 used 属性则记录了哈希表目前已有节点(键值对)的数量。
  • sizemask 属性的值总是等于 size - 1 , 这个属性和哈希值一起决定一个键应该被放到 table 数组的哪个索引上面。
  • used 属性记录了当前哈希表中已有节点的数量

【Redis】dict的渐进式rehash原理_第2张图片

【Redis】dict的渐进式rehash原理_第3张图片

 1.3 字典

字典的定义

typedef struct dict {
    // 类型特定函数
    dictType *type;
    // 私有数据
    void *privdata;
    // 哈希表
    dictht ht[2];
    // rehash 索引
    // 当 rehash 不在进行时,值为 -1
    int rehashidx; /* rehashing not in progress if rehashidx == -1 */
} dict;

ht 属性是一个包含两个项的数组, 数组中的每个项都是一个 dictht 哈希表, 一般情况下, 字典只使用 ht[0] 哈希表, ht[1] 哈希表只会在对 ht[0] 哈希表进行 rehash 时使用。 

【Redis】dict的渐进式rehash原理_第4张图片

2. 哈希算法与键冲突

2.1 哈希算法

当要将一个新的键值对添加到字典里面时,需要经过2步骤

  1. 根据键值对儿的键计算出哈希值
  2. 根据哈希值和sizemask计算出索引值

假设在一个hash表中添加一个新的键值对儿(k0, v0) 

① 先计算hash 值, hash = hash_function(k0) 

② 假设求出来的has值为 8. 计算索引  hash % sizemask = 8%3 = 2, 即索引为2. 

【Redis】dict的渐进式rehash原理_第5张图片

 2.2 键冲突

当有两个或以上数量的键被分配到了哈希表数组的同一个索引上面时, 即发生了键冲突。

hash表节点中的next属性正是为了解决键冲突而设计, 多个哈希表节点可以用 next 指针构成一个单向链表, 被分配到同一个索引上的多个节点可以用这个单向链表连接起来, 这就解决了键冲突的问题

假设上面的hash表,又新添加了一个键值对儿 (k1, v1), 经过哈希和计算索引后,得到的索引也是2. k1, 和 k0 发生了键冲突, 将k1和k0节点串成一个链表即可

【Redis】dict的渐进式rehash原理_第6张图片

3. rehash

随着插入数据的操作不断执行, 哈希表保存的键值对会逐渐地增多或者减少。如上例中的哈希表,如果数据达到40个,哈希表 table字段中每个指针都指向一个长度约为10的链表。降低数据的查询效率。

为了让哈希表的负载因子(load factor)维持在一个合理的范围之内, 当哈希表保存的键值对数量太多或者太少时, 程序需要对哈希表的大小进行相应的扩展或者收缩。

负载因子计算方式

# 负载因子 = 哈希表已保存节点数量 / 哈希表大小
load_factor = ht[0].used / ht[0].size

扩展或者收缩哈希表的过程就是rehash, 分为3步:

  1. 为字典的 ht[1] 哈希表分配空间, 这个哈希表的空间大小取决于要执行的操作, 以及 ht[0] 当前包含的键值对数量 (也即是 ht[0].used 属性的值):
    • 如果执行的是扩展操作, 那么 ht[1] 的大小为第一个大于等于 ht[0].used * 2 的 2^n (2 的 n 次方幂);
    • 如果执行的是收缩操作, 那么 ht[1] 的大小为第一个大于等于 ht[0].used 的 2^n 。
  2. 将保存在 ht[0] 中的所有键值对 rehash 到 ht[1] 上面: rehash 指的是重新计算键的哈希值和索引值, 然后将键值对放置到 ht[1] 哈希表的指定位置上。
  3. 当 ht[0] 包含的所有键值对都迁移到了 ht[1] 之后 (ht[0] 变为空表), 释放 ht[0] , 将 ht[1] 设置为 ht[0] , 并在 ht[1] 新创建一个空白哈希表, 为下一次 rehash 做准备。 

【Redis】dict的渐进式rehash原理_第7张图片

【Redis】dict的渐进式rehash原理_第8张图片

 【Redis】dict的渐进式rehash原理_第9张图片

【Redis】dict的渐进式rehash原理_第10张图片

4. 渐进式rehash

前面讲了rehash, 扩展或收缩哈希表需要将 ht[0] 里面的所有键值对 rehash 到 ht[1] 里面, 但是, 这个 rehash 动作并不是一次性、集中式地完成的, 而是分多次、渐进式地完成的。

因为如果哈希表里保存的键值对数量不是四个, 而是四百万、四千万甚至四亿个键值对, 那么要一次性将这些键值对全部 rehash 到 ht[1] 的话, 庞大的计算量可能会导致服务器在一段时间内停止服务。

因此, 为了避免 rehash 对服务器性能造成影响, 服务器不是一次性将 ht[0] 里面的所有键值对全部 rehash 到 ht[1] , 而是分多次、渐进式地将 ht[0] 里面的键值对慢慢地 rehash 到 ht[1] 。

以下是哈希表渐进式 rehash 的详细步骤:

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

【Redis】dict的渐进式rehash原理_第11张图片

 【Redis】dict的渐进式rehash原理_第12张图片

【Redis】dict的渐进式rehash原理_第13张图片

【Redis】dict的渐进式rehash原理_第14张图片

在进行渐进式 rehash 的过程中, 字典会同时使用 ht[0] 和 ht[1] 两个哈希表。

所以在渐进式 rehash 进行期间, 字典的删除(delete)、查找(find)、更新(update)等操作会在两个哈希表上进行: 比如说, 要在字典里面查找一个键的话, 程序会先在 ht[0] 里面进行查找, 如果没找到的话, 就会继续到 ht[1] 里面进行查找, 诸如此类。

另外, 在渐进式 rehash 执行期间, 新添加到字典的键值对一律会被保存到 ht[1] 里面, 而 ht[0] 则不再进行任何添加操作: 这一措施保证了 ht[0] 包含的键值对数量会只减不增, 并随着 rehash 操作的执行而最终变成空表。

总结:

  • Redis 中的字典使用哈希表作为底层实现, 每个字典带有ht[0], ht[1]两个hash表, ht[1]仅在 rehash 时使用。
  • 在对哈希表进行扩展或者收缩时, 程序需要将现有哈希表中所有键值对 rehash 到ht[1]中, 并且这个 rehash 过程是渐进式地完成的。

你可能感兴趣的:(redis,redis)