redis底层结构-Dict

前言

我们知道 redis 是一个键值型（Key-Value Pair）的数据库，我们可以根据键实现快速的增删改查。而键与值得映射关系正是通过Dict来实现的

Dict由三部分组成，分别是：哈希表(DIctHashTable)、 哈希节点(DictEntry)、字典(Dict)
其中字典为

typedef struct dict {
    dictType *type; // dict类型，内置不同的hash函数
    void *privdata;     // 私有数据，在做特殊hash运算时用
    dictht ht[2]; // 一个Dict包含两个哈希表，其中一个是当前数据，另一个一般是空，rehash时使用
    long rehashidx;   // rehash的进度，-1表示未进行
    int16_t pauserehash; // rehash是否暂停，1则暂停，0则继续
} dict;

• 其中 rehashidx 和 pauserehash 均是标识着哈希表在更新状态、在更新过程中使用。
• 而ht[0]时当前数据存放的表、在做扩容和收缩(即rehash)时会将数据复制到ht[1]中，让后将ht[1]变为ht[0]，原本的ht[0]释放。

其中哈希表为：

typedef struct dictht {
    // entry数组
    // 数组中保存的是指向entry的指针
    dictEntry **table; 
    // 哈希表大小
    unsigned long size;     
    // 哈希表大小的掩码，总等于size - 1
    unsigned long sizemask;     
    // entry个数
    unsigned long used; 
} dictht;

• 其中sizemask为size - 1，是为了方便插入节点时计算对应的hash值
• used表示其中存在的键值对个数、而size表示表中含有的节点个数（因为不同key获取的hash对应节点可能相同，即一个节点可能含有多个键值对组成的链表）

哈希节点为：

typedef struct dictEntry {
    void *key; // 键
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v; // 值
    // 下一个Entry的指针
    struct dictEntry *next; 
} dictEntry;

• 其中union 是对应的val值。满足联合体union中任意一个即可。

插入键值对

当我们向 Dict 中添加键值对时，redis首先根据 key 计算出对应的 hash 值（h），然后利用 h & sizemask 来计算元素应该存储到数组中哪个索引位置。

• 例如存储一个键值对k1 = v1，假设k1的哈希值h = 1，则1 & 3 = 1，因此k1 = v1要存储到数据角标为1的位置

哈希冲突：由于哈希算法被计算的数据是无限的，而计算后的结果范围有限，因此总会存在不同的数据经过计算后得到的值相同，这就是哈希冲突

• 而如果接着插入一个键值对k2 = v2，如果k2的哈希值仍等于1就会造成哈希冲突，则k2 = v2也要储存到数据角标为1的位置。为了解决这个问题，dict中采用了链表的形式：即角标为1的指针指向k2所在的dictEntry，而dictEntry的next指针指向原来的k1.

这里就可以讲一下为什么在dictht中有sizemask属性的存在？
原本hash的算法是由对应的哈希值h对节点大小取余数。而位运算的性能远大于%。而由于是二进制的存储。h%size 的值和 h & sizemask（size - 1）相同的同时，使用 & 位运算则可以大大提升性能。

Dict的扩容和收缩

由于Dict中的HashTable就是有数组结合单项链表的实现，当集合中元素过多时，必然会导致哈希冲突
增多，链表不断加长，则查询的效率就会大大降低。

为了解决上述问题，Dict中有了一个概念叫做负载因子（loadFactor = used / size），而 Dict 每次新增键值对的时候都会检查负载因子，满足以下两种情况时会触发哈希表扩容。

• 哈希表的 LoadFactor >= 1，并且服务器没有执行 BGSAVE 或者 BGREWRITEAOF 等后台进程
• 哈希表的 LoadFactor >= 5。

其更新的源码如下

static int _dictExpandIfNeeded(dict *d){
    // 如果正在rehash，则返回ok
    if (dictIsRehashing(d)) return DICT_OK;    // 如果哈希表为空，则初始化哈希表为默认大小：4
    if (d->ht[0].size == 0) return dictExpand(d, DICT_HT_INITIAL_SIZE);
    // 当负载因子（used/size）达到1以上，并且当前没有进行bgrewrite等子进程操作
    // 或者负载因子超过5，则进行 dictExpand ，也就是扩容
    if (d->ht[0].used >= d->ht[0].size &&
        (dict_can_resize || d->ht[0].used/d->ht[0].size > dict_force_resize_ratio){
        // 扩容大小为used + 1，底层会对扩容大小做判断，实际上找的是第一个大于等于 used+1 的 2^n
        return dictExpand(d, d->ht[0].used + 1);
    }
    return DICT_OK;
}

同样，如果扩容后的dict有了极多的节点数，但其中包含的元素又被大量删除。那么会导致dict的负载因子极小，造成			了空间的大量浪费。

因此dict中也同样设计了缩容的策略。

• 即每次删除元素的时候，也会对负载因子进行检查，当LoadFactor < 0.1时，会做哈希表收缩

源码如下：

// t_hash.c # hashTypeDeleted() 
...
if (dictDelete((dict*)o->ptr, field) == C_OK) {
    deleted = 1;
    // 删除成功后，检查是否需要重置Dict大小，如果需要则调用dictResize重置    /* Always check if the dictionary needs a resize after a delete. */
    if (htNeedsResize(o->ptr)) dictResize(o->ptr);
}
...

// server.c 文件
int htNeedsResize(dict *dict) {
    long long size, used;
    // 哈希表大小
    size = dictSlots(dict);
    // entry数量
    used = dictSize(dict);
    // size > 4（哈希表初识大小）并且 负载因子低于0.1
    return (size > DICT_HT_INITIAL_SIZE && (used*100/size < HASHTABLE_MIN_FILL));
}

int dictResize(dict *d){
    unsigned long minimal;
    // 如果正在做bgsave或bgrewriteof或rehash，则返回错误
    if (!dict_can_resize || dictIsRehashing(d)) 
        return DICT_ERR;
    // 获取used，也就是entry个数
    minimal = d->ht[0].used;
    // 如果used小于4，则重置为4
    if (minimal < DICT_HT_INITIAL_SIZE)
        minimal = DICT_HT_INITIAL_SIZE;
    // 重置大小为minimal，其实是第一个大于等于minimal的2^n
    return dictExpand(d, minimal);
}

Dict的rehash

不管是扩容还是收缩，必定会创建新的哈希表，导致哈希表的size和sizemask变化，而key的查询与sizemask有关。因此必须对哈希表中的每一个key重新计算索引，插入新的哈希表，这个过程称为rehash。

过程如下：

1. 计算新hash表的realeSize，值取决于当前要做的是扩容还是收缩：
   • 如果是扩容 ，则新size为第一个大于等于dict.ht[0].used + 1的2^n
   • 如果是收缩，则新size为第一个大于等于dict.ht[0].used的2^n （不得小于4）
2. 按照新的realeSize申请内存空间，创建dictht，并赋值给dict.ht[1]
3. 设置dict.rehashidx = 0，标示开始rehash
4. 将dict.ht[0]中的每一个dictEntry都rehash到dict.ht[1]
5. 将dict.ht[1]赋值给dict.ht[0]，给dict.ht[1]初始化为空哈希表，释放原来的dict.ht[0]的内存

如图：

渐进式rehash

试想如果dict中含有数百万的entry，要在一次rehash中完成，有极大的可能造成。因此dict中的rehash并不是一次完成的，而是分多次、渐进式的完成的，因此称为渐进式rehash。流程如下：

1. 计算新hash表的realeSize，值取决于当前要做的是扩容还是收缩：
   • 如果是扩容 ，则新size为第一个大于等于dict.ht[0].used + 1的2^n
   • 如果是收缩，则新size为第一个大于等于dict.ht[0].used的2^n （不得小于4）
2. 按照新的realeSize申请内存空间，创建dictht，并赋值给dict.ht[1]
3. 设置dict.rehashidx = 0，标示开始rehash
4. 每次执行新增、查询、修改、删除操作时，都检查一下dict.rehashidx是否大于-1，如果是则将dict.ht[0].table[rehashidx]的entry链表rehash到dict.ht[1]，并且将rehashidx++。直至dict.ht[0]的所有数据都rehash到dict.ht[1]
5. 将dict.ht[1]赋值给dict.ht[0]，给dict.ht[1]初始化为空哈希表，释放原来的dict.ht[0]的内存
6. 将rehashidx赋值为-1，代表rehash结束
7. 在rehash过程中，新增操作，则直接写入ht[1]，查询、修改和删除则会在dict.ht[0]和dict.ht[1]依次查找并执行。这样可以确保ht[0]的数据只减不增，随着rehash最终为空

总结

Dict的结构：

• 类似于Java的HashTable，底层是数据加链表来解决哈希冲突
• Dict 包含两个哈希表。ht[0]放置平时数据、ht[1]在rehash时使用

Dict的伸缩：

• 当LoadFactor大于5或者LoadFactor大于1并且没有子进程任务时，Dict扩容
• 当LoadFactor小于0.1时，Dict收缩
• 扩容大小为第一个大于等于used + 1的2^n
• 收缩大小为第一个大于等于used 的2^n
• Dict采用渐进式rehash，每次访问Dict时执行一次rehash
• rehash时ht[0]只减不增，新增操作只在ht[1]执行，其它操作在两个哈希表