深度图解 Redis Hash（散列表）实现原理

傷城~ 2023-10-11 22:12 67阅读 0赞

## 1. 是什么 ##

Redis Hash（散列表）是一种 field-value pairs（键值对）集合类型，类似于 Python 中的字典、Java 中的 HashMap。一个 field 对应一个 value，你可以通过 field 在 O(1) 时间复杂度查 field 找关联的 field，也可以通过 field 来更新或者删除这个键值对。

Redis 的散列表 dict 由**数组 + 链表**构成，数组的每个元素占用的槽位叫做**哈希桶**，当出现散列冲突的时候就会在这个桶下挂一个链表，用“**拉链法”解决散列冲突的问题**。

简单地说就是将一个 key 经过散列计算均匀的映射到散列表上。

![26371b777a0fb4fd6f08e5719a818315.png][]

图 2-18

## 2. 修炼心法 ##

Hash 数据类型底层存储数据结构实际上有两种。

1.  dict 结构。
2.  在 7.0 版本之前使用 ziplist，之后被 listpack 代替。

通常情况下使用 dict 数据结构存储数据，每个 `field-value pairs` 构成一个 dictEntry 节点来保存。

只有同时满足以下两个条件的时候，才会使用 listpack（7.0 版本之前使用 ziplist）数据结构来代替 dict 存储， **把 key-value 键值对按照 field 在前 value 在后，紧密相连的方式放到一次把每个键值对放到列表的表尾**。

*  每个键值对中的 field 和 value 的字符串字节大小都小于`hash-max-listpack-value` 配置的值（默认 64）。
 *  field-value pairs 键值对数量小于 `hash-max-listpack-entries`配置的值（默认 512）。

每次向散列表写数据的时候，都会调用 `t_hash.c` 中的`hashTypeConvertListpack()`函数来判断是否需要转换底层数据结构。

当插入和修改的数据不满足以上两个条件时，就把散列表底层存储结构转换成 `dict`结构。需要注意的是，**不能由 dict 退化成 listpack**。

虽然使用了 listpack 就无法实现 O(1) 时间复杂度操作数据，但是**使用 listpack 能大大减少内存占用，而且数据量比较小，性能并不是有太大差异。**

**为了对上层屏蔽散列表底层使用了不同数据结构存储，所以抽象了一个 hashTypeIterator 迭代器来实现散列表的查询。**

Hashes 数据类型使用 listpack 作为存储数据时的情况，如图 2-19 所示。

![68524d2487084bcf8286bec9463427bc.png][]

图 2-19

listpack 数据结构在之前的已经介绍过， 接下来带你揭秘 dict 到底长啥样。

**Redis 数据库就是一个全局散列表**。正常情况下，我只会使用 `ht_table[0]`散列表，图 2-20 是一个没有进行 rehash 状态下的字典。

![08852e2ea83543312586d7d0511f16c6.png][]

图 2-20

dict 字典在源代码 `dict.h`中使用 dict 结构体表示。

struct dict {
        dictType *type;
      // 真正存储数据的地方，分别存放两个指针
        dictEntry **ht_table[2];
        unsigned long ht_used[2];
    
        long rehashidx;
    
        int16_t pauserehash;
        signed char ht_size_exp[2];
    };

*  `dictType *type`，存放函数的结构体，定义了一些函数指针，可以通过设置自定义函数，实现 dict 的 key 和 value 存放任何类型的数据。
 *  重点看 `dictEntry **ht_table[2]`，存放了两个 dictEntry 的二级指针，指针分别指向了一个 dictEntry 指针的数组。
 *  `ht_used[2]`，记录每个散列表使用了多少槽位（比如数组长度 32，使用了 12）。
 *  `rehashidx`，用于标记是否正在执行 rehash 操作，-1 表示没有进行 rehash。如果正在执行 rehash，那么其值表示当前 rehash 操作执行的 ht\_table\[0\] 散列表 dictEntry 数组的索引。
 *  `pauserehash` 表示 rehash 的状态，大于 0 时表示 rehash 暂停了，小于 0 表示出错了。

继续看 **dictEntry**，数组中每个元素都是 dictEntry 类型，就是这玩意存放了键值对，表示字典的一个节点。

typedef struct dictEntry {
        void *key;
        union {
            void *val;
            uint64_t u64;
            int64_t s64;
            double d;
        } v;
        struct dictEntry *next;
    } dictEntry;

*  `*key`指针指向键值对中的键，实际上指向一个 SDS 实例。
 *  `v`是一个 union 联合体，表示键值对中的值，同一时刻只有一个字段有值，用联合体的目是节省内存。
    
     *  `*val` 如果值是非数字类型，那就使用这个指针存储。
     *  `uint64_t u64`，值是无符号整数的时候使用这个字段存储。
     *  `int64_t s64`，值是有符号整数时，使用该字段存储。
     *  `double d`，值是浮点数是，使用该字段存储。
 *  `*next`指向下一个节点指针，当散列表数据增加，可能会出现不同的 key 得到的哈希值相等，也就是说多个 key 对应在一个哈希桶里面，这就是哈希冲突。Redis 使用拉链法，也就是用链表将数据串起来。

> MySQL：“为啥 ht\_table\[2\] 存放了两个指向散列表的指针？用一个散列表不就够了么。”

默认使用 `ht_table [0]` 进行读写数据，当散列表的数据越来越多的时候，哈希冲突严重会出现哈希桶的链表比较长，导致查询性能下降。

我为了唯快不破想了一个法子，当散列表保存的键值对太多或者太少的时候，需要通过 rehash（重新散列）对散列表进行扩容或者缩容。

**扩容和缩容**

1.  为了高性能，减少哈希冲突，我会创建一个大小等于 `ht_used[0] * 2`的散列表 `ht_table[1]`，也就是每次扩容时根据散列表 `ht_table [0]`已使用空间扩大一倍创建一个新散列表`ht_table [1]`。反之，如果是缩容操作，就根据`ht_table [0]`已使用空间缩小一倍创建一个新的散列表。
2.  重新计算键值对的哈希值，得到这个键值对在新散列表 `ht_table [1]`的桶位置，将键值对迁移到新的散列表上。
3.  所有键值对迁移完成后，修改指针，释放空间。具体是把 `ht_table[0]`指针指向扩容后的散列表，回收原来小的散列表内存空间，`ht_table[1]`指针指向`NULL`，为下次扩容或者缩容做准备。

> MySQL：“什么时候会触发扩容？”

1.  当前没有执行 `BGSAVE`或者 `BGREWRITEAOF`命令，同时负载因子大于等于 1。也就是当前没有 RDB 子进程和 AOF 重写子进程在工作，毕竟这俩操作还是比较容易对性能造成影响的，就不扩容火上浇油了。
2.  正在执行 `BGSAVE`或者 `BGREWRITEAOF`命令，负载因子大于等于 5。（这时候哈希冲突太严重了，再不触发扩容，查询效率太慢了）。

`负载因子 = 散列表存储 dictEntry 节点数量 / 散列表桶个数`。完美情况下，每个哈希桶存储一个 dictEntry 节点，这时候负载因子 = 1。

> MySQL：“需要迁移数据量很大，rehash 操作岂不是会长时间阻塞主线程？”

**为了防止阻塞主线程造成性能问题，我并不是一次性把全部的 key 迁移，而是分多次，将迁移操作分散到每次请求中，避免集中式 rehash 造成长时间阻塞，这个方式叫渐进式 rehash**。

在执行渐进式 rehash 期间，dict 会同时使用 `ht_table[0]` 和 `ht_table[1]`两个散列表，rehash 具体步骤如下。

1.  将 `rehashidx`设置成 0，表示 rehash 开始执行。
2.  在 rehash 期间，服务端每次处理客户端对 dict 散列表执行添加、查找、删除或者更新操作时，除了执行指定操作以外，还会检查当前 dict 是否处于 rehash 状态，是的话就把散列表`ht_table[0]`上索引位置为 `rehashidx` 的桶的链表的所有键值对 rehash 到散列表 `ht_table[1]`上，这个哈希桶的数据迁移完成，就把 `rehashidx` 的值加 1，表示下一次要迁移的桶所在位置。
3.  当所有的键值对迁移完成后，将 `rehashidx`设置成 -1，表示 rehash 操作已完成。

> MySQL：“rehash 过程中，字典的删除、查找、更新和添加操作，要从两个 ht\_table 都搞一遍么？”

删除、修改和查找可能会在两个散列表进行，第一个散列表没找到就到第二个散列表进行查找。但是增加操作只会在新的散列表上进行。

> MySQL：“如果请求比较少，岂不是会很长时间都要使用两个散列表。”

好问题，在 Redis Server 初始化时，会注册一个时间事件，定时执行 `serverCron` 函数，其中包含 rehash 操作用于辅助迁移，避免这个问题。

`serverCron` 函数除了做 rehash 以外，主要处理如下工作。

*  过期 key 删除。
 *  监控服务运行状态。
 *  更新统计数据。
 *  渐进式 rehash。
 *  触发 BGSAVE / AOF rewrite 以及停止子进程。
 *  处理客户端超时。
 *  ......

是不是很贴心，既能保证性能，又能避免内存浪费。好了，今天散列表底层数据结构实现原理就到这里。后面我将给大家分享如何使用 Hash 实现购物车功能。

[26371b777a0fb4fd6f08e5719a818315.png]: https://img-blog.csdnimg.cn/img_convert/26371b777a0fb4fd6f08e5719a818315.png
[68524d2487084bcf8286bec9463427bc.png]: https://img-blog.csdnimg.cn/img_convert/68524d2487084bcf8286bec9463427bc.png
[08852e2ea83543312586d7d0511f16c6.png]: https://img-blog.csdnimg.cn/img_convert/08852e2ea83543312586d7d0511f16c6.png