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满足2n >= dict.ht[0].used * 2

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

如下图:ht[0].used = 3,假定无bg相关任务,则h[1]大小需要计算:2n >= 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] 上元素此过程保持只减不增。