Redis中字典你了解吗？

偏执的太偏执、 2022-10-19 12:40 168阅读 0赞

## 一、字典 ##

> 1.1 字典简介  
> 1.2 字典的实现  
> 1.3 哈希算法  
> 1.4 解决键冲突  
> 1.5 rehash  
> 1.6 渐进式rehash

### 1.1 字典简介 ###

> 字典，又称符号表（symbol table）、关联数组（associative array）或映射（map），是一种用于保存键值对（key-value pair）的抽象数据结构。在字典中，一个键（key）可以和一个值（value）进行关联（或者说将键映射为值），这些关联的键和值就称为键值对，而字典中的键都是独一无二的，程序可以在字典中根据键查找与之关联的值，或通过键来更新值。  
> 字典经常作为一种数据结构内置在很多高级编程语言里面，但Redis所使用的C语言并没有内置这种数据结构，因些Redis构建了自己的字典实现。字典在Redis中应用相当广泛，比如Redis的数据库就是使用字典来作为底层实现的，还是Redis中的哈希键也是用字典来作为底层实现的等。

### 1.2 字典的实现 ###

> Redis的字典使用哈希表作为底层实现，一个哈希表里面可以有多个哈希表节点，而每个哈希表节点就保存了字典中的一个键值对。接下来将带大家学习Redis中的哈希表、哈希节点以及字典的实现。

#### 1.2.1 哈希表 ####

哈希表由dict.h/dictht结构定义如下：

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数组的哪个索引上面。

![image.png][]  
  
该图展示了一个大小为4的空哈希表（没有包含任何键值对）。

#### 1.2.2 哈希表节点 ####

哈希表节点使用dictEntry结构定义如下，每个dictEntry结构都保存着一个键值对：

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

1.  key属性保存着键值对中的键，而v属性则保存着键值对中的值，其中键值对的值可以是一个指针，或者是一个uint64\_t整数，又或者是一个int64\_t整数。
2.  next属性是指向另一个哈希表节点的指针，这个指针可以将多个哈希值相同的键值对连接在一起，以些来解决键冲突（collision）的问题。

#### 1.2.3 字典 ####

Redis中的字典dict.h/dict结构如下：

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

*  type属性是一个指向dictType结构的指针，每个dictType结构保存了一簇用于操作特定类型键值对的函数，Redis会为用途不同的字典设置不同的类型特定函数。
 *  而privdata属性则保存了需要传给那些类型特定函数的可选参数。  
    dictType结构定义如下：

typedef struct dictType { 
        // 计算哈希值的函数
        unsigned int (*hashFunction)(const void *key);
        // 复制键的函数
        void *(*keyDup)(void *privdata, const void *key);
        // 复制值的函数
        void *(*valDup)(void *privdata, const void *obj);
        // 对比键的函数
        int (*keyCompare)(void *pridata, const void *obj);
        // 销毁键的函数
        void (*keyDestructor)(void *privdata, void *key);
        // 销毁值的函数
        void (*valDestructor)(void *privdata, void *obj);
    } dictType;

*  ht属性是一个包含两个哈希表的数组，一般情况下，字典只使用ht\[0\]哈希表，ht\[1\]哈希表只会在对ht\[0\]哈希表进行rehash时使用。
 *  rehashidx属性，记录rehash目前的进度，如果目前没有在进行rehash，那么它的值为-1。  
    *下图展示了一个普通状态下（没有进行rehash）的字典。*

![image.png][image.png 1]

### 1.3 哈希算法 ###

> 当要将一个新的键值对添加到字典里面时，程序需要先根据键值对的键计算出哈希值和索引值，然后再根据索引值将哈希表节点放到哈希表数组的指定索引上面。  
> Redis计算哈希值和索引值的方法如下：

// 使用字典设置的哈希函数，计算键key的哈希值
    hash = dict->type->hashFunction(key);
    // 使用哈希表的sizemask属性和哈希值，计算出索引值
    // 根据情况不同，ht[x]可以是ht[0]或者ht[1]
    index = hash & dict->ht[x].sizemask;

比如，将一个键值对k0和v0添加到字典里面，那么程序会先使用语句：  
  
**hash = dict->type->hashFunction(k0);**  
  
假设计算得出的哈希值为8，那么程序会继续使用语句：  
  
**index = hash&dict->ht\[0\].sizemask = 8&3 = 0;**  
  
计算出键k0的索引值0，这表示包含键值对k0和v0的节点会被放置到哈希表数组的索引0位置上。

> 当字典被用作数据库的底层实现，或者哈希键的底层实现时，Redis使用MurmurHash2算法来计算键的哈希值。  
> MurmurHash算法最初由Austin Appleby于2008年发明，这种算法的优点在于，即使输入的键是有规律的，算法仍能给出一个很好的随机分布性，并且算法的计算速度也非常快。MurmurHash算法目前的最新版本为MurmurHash3。

### 1.4 解决键冲突 ###

> 当有两个或以上数量的键被分配到了哈希表数组的同一个索引上面时，我们称这些键发生了冲突（collision）。而Redis的哈希表使用链地址法（separate chaining）来解决键冲突，每个哈希表节点都有一个next指针，多个哈希表节点可以用next指针构成一个单向链表，被分配到同一个索引上的多个节点可以用这个单向链表连接起来，这样就解决了冲突的问题。

![image.png][image.png 2]  
   上图使用链表解决K2和k1的冲突

> 因为dictEntry节点组成的链表没有指向链表表尾的指针，所以为了速度考虑，程序总是将新节点添加到链表的表头位置（复杂度为O(1)),排在其他已有节点的前面。

### 1.5 rehash ###

> 随着操作的不断执行，哈希表保存的键值对会逐渐地增加或者减少，为了让哈希表的负载因子（load factor）维持在一个合理的范围之内，只哈希表保存的键值对数量太多或者太少时，程序需要对哈希表的大小进行相应的扩展或者收缩。扩展和收缩哈希表的工作可以通过执行rehash（重新散列）操作来完成，其中rehash流程如下：

![image.png][image.png 3]

**哈希表的扩展与收缩**

> 当以下条件中的任意一个被满足时，程序会自动开始对哈希表执行扩展操作：

1.  服务器目前没有在执行BGSAVE命令或者BGREWRITEAOF命令，并且哈希表的负载因子大于等于1。
2.  服务器目前正在执行BGSAVE命令或者BGREWITEAOF命令，并且哈希表的负载因子大于等于5。  
    其中哈希表的负载因子可以通过以下公式：

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

> 根据BGSAVE命令或BGREWRITEAOF命令是否正在执行，服务器执行扩展操作所需的负载因子并不相同，这是因为在执行BGSAVE命令或BGREWRITEAOF命令的过程中，Redis需要创建当前服务器进程的子进程，而大多数操作系统都采用写时复制(copy-on-write)技术来优化子进程的使用效率，所以在子进程存在期间，服务器会提高执行扩展操作所需的负载因子，从而尽可能地避免在子进程存在期间进行哈希表扩展操作，这可以避免不必要的内存写入操作，最大限度的节约内存。  
> **另一方面，当哈希表的负载因子小于0.1时，程序自动开始对哈希表执行收缩操作。**

### 1.6 渐进式rehash ###

> 扩展或收缩哈希表需要将ht\[0\]里面的所有键值对rehash到ht\[1\]里面，但是这个rehash动作并不是一次性、集中式地完成的，而是分多次、渐进式地完成的。  
> 这样做的原因在于，当哈希表里保存的键值对数量上百万、上千万、上亿键值对时，那么要一次性将这些键值对全部rehash到ht\[1\]的话，庞大的计算量可能会导致服务器在一段时间内停止服务。  
> **因此,为了避免rehash对服务器性能造成影响，redis采用分多次、渐进式地将ht\[0\]里面的键值对慢慢地rehash到ht\[1\]。**  
>   
> 以下是哈希表渐进式rehash的详细流程：

![image.png][image.png 4]

[image.png]: /images/20221005/bce37e2e1dfd4675a2c8f7f69a38b373.png
[image.png 1]: /images/20221005/3bfecd51e6b9410da8e57200569b96f4.png
[image.png 2]: /images/20221005/79d0b4a90d554b6f9fa79916285bba70.png
[image.png 3]: /images/20221005/b1b6fbd72c2b49ab8462b3ac91074a97.png
[image.png 4]: /images/20221005/63a278dcabd340eea37c8b74fd509683.png