Redis Hashes 数据类型简述

Redis Hashes 是我们日常使用中比较高频的 Redis 数据类型，内部使用 Redis 字典结构存储，底层基于哈希表结构实现。

下面从哈希表节点，哈下表结构，Redis 字典，Redis 字典元素操作，Redis rehash 几点来简要概述。

一、Redis 哈希表节点

Redis 内部定义哈希表节点 dictEntry，用于存储具体的数据，其主要包括键 key，值 v，及外向指针。

1、dictEntry 具体定义

typedef struct dictEntry {

  void *key; 

  union{  

    void *val;

    uint64_t u64;

    int64_t s64;

  } v;

struct dictEntry *next; //下一个节点指针

} dictEntry;

key：键值对 key

v：键值对 value，可以是指向指针，或者具体的类型。

next：为指向下一个节点的指针，用于处理键哈希冲突问题。相同哈希值键的键值对会以链表的形式存在同一位置。

2、示例哈希表节点数据

如下，哈希表容量 size 为 4，掩码 sizemask 为 3 ，内部存储了两个键值对（k1、v1）、（k2、v2），已使用容量 used 为 2：

二、Redis 哈希表结构

Redis 内部定义哈希表结构 dictht，用于存储实际的（k、v）键值对，其主要包括哈希表数组，容量、已使用容量及掩码。

1、dictht 具体定义

typedef struct dictht {

  dictEntry **table; 

  unsigned long size; 

  unsigned long sizemask; 

  unsigned long used; 

} dictht

table：哈希表数组，为指向 dictEntry 类型数组的指针，存储具体的键值对元素。

size：哈希表容量，规划申请的容量

sizemask：哈希表大小掩码，用于索引计算，计算方式为 size - 1

used：已使用容量，实际存储的（k、v）键值对数

2、示例哈希表数据

如下，哈希表容量 size 为 4，掩码 sizemask 为 3 ，内部存储了一个键值对（k1、v1），已使用容量 used 为 1：

三、Redis 字典实现

Redis 字典基于上述的哈希表实现，其主要包括内部特定类型函数、私有数据、哈希表数组及 rehash 进度标识等数据。

1、dict：

typedef struct dict{

  dictType *type; 

  void *privdata; 

  dictht ht[2]; 

  int rehashidx; 

} dict

type：类型为dictType，保存了用于操作特定类型键的函数，和 privdata 共同服务于构建 Redis 多态字典。

privdate：和type协同使用，为需要传递给特定类型函数的可选参数。

ht：哈希表数组，类型为dictht，ht[0] 为实际存储数据使用，ht[1] 为 rehash 时使用。

ehashidx：rehash 进度标志，-1 代表当前不在 rehash 进程中。

2、Redis 字典示例数据

如下，包含两个元素的 Redis 字典：

四、Redis 字典添加元素

向字 Redis 典中添加元素主要涉及以下几步操作：

1、计算键值对键的哈希值

hash = dict->type->hashFunction(key)

上面第三节我们提到过 Redis 字典的属性 type，应用其内部的哈希函数得到键哈希值。

2、计算需要放入的位置索引

index = hash & dict->ht[0].sizemask

使用上一步计算得到的哈希值与哈希表的 sizemask 属性进行【与操作】得到需要放入的位置索引值

3、键冲突解决

没有完美的哈希函数，哈希冲突无法避免，实际应用中，多个键往往会被索引到同一个位置时，这种现象，我们称之为键冲突。

Redis 采用链地址法解决键冲突：也即将冲突的键值对组成一个链表放到同一个哈希位置上。

上面第二节我们介绍过 dictEntry 的结构，其中包含一个指向另一个节点的指针 next。

这里需要说明的一点是：冲突节点插入时，是插入到链表的头部，这样只需要执行操作一次操作即可，也即时间复杂度为 O(1)。

如下图：（k2，v2）与（k1，v1）发生冲突，直接将（k2，v2）插入到链表头部：

五、Redis rehash

Redis rehash 是指 Redis 字典重新规划哈希表空间占用的过程。Redis 字典往往伴随着元素的增删改等操作，随着元素的增多或减少，需要适时地进行 Redis 字典容量的重新规划。

1、负载因子

哈希表使用负载因子（load_factor）来标识当前哈希表的使用状态，计算公式为：已保存节点数量（dict.ht[0].used）/ 哈希表容量（dict.ht[0].size）。它需要保持在一个合理的范围，以保障资源的最优利用。通常需要适时的对哈希表进行扩展或者收缩来对负载因子进行维护。

这里涉及到一个问题，就是什么时候需要进行伸缩维护？

a）扩展时机：

触发 rehash 实际收到当前 Redis 服务器状态影响，即有无后台 bgsave 及 bgrewriteaop 操作：

无操作，则触发 load_factor 标准为 >= 1
当前有操作，则触发 load_factor 标准为 >= 5

Redis 服务器通过 fork 子进程形式执行 bgsave 及 bgrewriteaop 操作，此期间整个服务的资源耗费较大，为了避免可能发生的 rehash 带来额外的资源压力，服务器往往会调高触发执行 rehash 操作的负载因子界限，以降低触发 rehash 的频率。

b）收缩时机：

load_factor < 0.1

2、Redis rehash 基本过程

Redis rehash 过程主要包括空间分配、rehash 执行、重定向三个过程

a) 空间分配：

空间分配是指 为 dict.ht[1] 分配空间

所需要的空间大小计算如下：

扩展：最小n满足2ⁿ >= dict.ht[0].used * 2

收缩：最小n满足2ⁿ >= dict.ht[0].used

如下图：ht[0].used = 3，假定无bg相关任务，则h[1]大小需要计算：2ⁿ >= 3 * 2 = 6

n = 3，ht[1].size = 2³= 8

b) rehash 执行

此过程会逐一对 dict.ht[0] 中的元素，依据dict.ht[1] 特性（sizemask）重新计算索引值，并放置到 dict.ht[1] 中。

如下图：h[0] 中的元素以被完全 rehash 到 h[1] 中存储：

c) 重定向

当所有元素迁移完毕后，Redis 会释放调 dict.ht[0] 的空间占用，并将 dict.ht[1] 设置为 dict.ht[0]，并重新在 dict.ht[1] 上创建空的哈希表，以用于下次 rehash 使用。

如下图：重新指向完毕，并创建了新的 ht[1]：

六、Redis rehash 并非一蹴而就

针对实际存储中不同容量的字典数据，Redis 采用不同的措施进行 rehash 执行：对于数据量较小的字典可以直接一次性的执行rehash；而对于数据量较大的字典数据，直接一次性的执行 rehash 会导致服务资源的集中占用，影响正常的服务响应。因此需要进行分而治之，采用渐进式执行过程。

渐进式 rehash 会用到上面第三节我们介绍的 dict 字典结构中的 rehashidx 属性，用以标识当前 rehash 进度。

关于渐进式 rehash 过程中 rehashidx 操作如下：

首先将rehashidx置0，标示rehash开始
每次rehash一个元素，rehashidx值增加1
当最终所有元素rehash完成，将rehashidx置-1。

渐进式 rehash 进程中对正常的服务请求的处理如下：

1、删除、查找、更新：

会涉及到两个哈希表（ht[0]、ht[1]）操作，如查找元素，首先尝试在ht[0]上查找，找不到，则继续在h[1]上查找。

2、添加

添加元素只会在h[1]上操作，h[0] 上元素此过程保持只减不增。