Redis深度解析（三）：字典的实现与哈希冲突解决

字典是Redis中非常重要的数据结构之一，扮演着多样的角色。在本篇文章中，我们将探讨字典的实现细节，包括它是如何处理哈希冲突的，以及它的动态哈希表是如何扩展和收缩的。

1. 字典的实现

Redis的字典数据类型的实现主要分为两个部分：

typedef struct dict {
    dictType *type;
    void *privdata;
    dictht ht[2];
    long rehashidx; 
    unsigned long iterators; 
} dict;

其中，type属性表示字典的类型，而privdata属性表示字典的私有数据，它是一个指针类型，可以指向一个可选的私有数据结构。

值得注意的是，Redis中的字典使用了两个哈希表(dictht ht[2])，一个用于平时的读写操作，另一个仅在rehash过程中使用，用作新的哈希表。

2. 哈希算法

在Redis中，主要采用MurmurHash2这个非加密哈希算法。此算法的优点主要有三个：

• 速度快：MurmurHash算法的速度非常快，可以在很短的时间内计算出哈希值。
• 均匀性好：MurmurHash算法的哈希值分布均匀，因此冲突的概率较低。
• 易于实现：MurmurHash算法的实现非常简单。

3. 解决键冲突

为解决哈希冲突，Redis采用了“链地址法”：当两个键的哈希值相同时，会将它们链接在同一个哈希槽（slot）上，形成一个链表。

4. rehash

当哈希表的负载过高或过低时，需要执行rehash（重新哈希）来调整哈希表的大小。rehash的过程如下：

1. 创建一个新的哈希表；
2. 逐个将旧哈希表的元素移动到新哈希表中，此过程需重新计算每个元素的哈希值；
3. 所有元素迁移完毕后，新哈希表成为当前的哈希表，rehash完成。

这里要特别提到的是，Redis实施了“渐进式rehash”。这是为了避免在rehash过程中阻塞所有操作，每次只移动一个或者一部分哈希桶。同时，如果有新的写入请求，会直

接写入新的哈希表中。

5. 哈希表的扩展与收缩

当哈希表的元素数量超过哈希表大小和负载因子之积时，Redis会触发哈希表的扩展操作。当哈希表中的元素数量少于哈希表大小的1/4时，Redis会触发哈希表的收缩操作。

总结

Redis字典的实现充分考虑了性能和内存效率，采用了一系列优化策略来保证其高效的运行，包括使用了MurmurHash算法，采用链地址法处理哈希冲突，以及通过渐进式rehash避免操作的长时间阻塞等。

在我们接下来的文章中，我们将继续深入研究Redis的其他数据结构和实现细节，敬请期待！