Redis3:字典

最新推荐文章于 2020-11-11 22:36:16 发布

Yisnow.

最新推荐文章于 2020-11-11 22:36:16 发布

阅读量84

点赞数

分类专栏： redis

本文链接：https://blog.csdn.net/qq_37935909/article/details/108896689

版权

redis 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

在这里插入图片描述

1.1 哈希算法

先根据键值对的键计算出哈希值和索引值。

//根据字典设置的哈希函数计算key的哈希值
hash=dict->type->hashFunction(key);
//使用哈希表的sizemask属性和哈希值，计算索引值
index=hash&dict->ht[x].sizemask;

当字典被用于数据库的底层实现，Redis使用MurmurHash2算法计算键的哈希值。
Murmur可以计算字符串的hash code,基本思想就是把key分成n组，每组4个字符，把这4个字符看成是一个uint_32，进行n次运算，得到一个h，然会在对h进行处理，得到一个相对离散的hash code;

unsigned int dictGenHashFunction(const void *key, int len) {
    /* 'm' and 'r' are mixing constants generated offline.
     They're not really 'magic', they just happen to work well.  */
    uint32_t seed = dict_hash_function_seed;
    const uint32_t m = 0x5bd1e995;
    const int r = 24;

    /* Initialize the hash to a 'random' value */
    uint32_t h = seed ^ len;

    /* Mix 4 bytes at a time into the hash */
    const unsigned char *data = (const unsigned char *)key;

    while(len >= 4) {
        uint32_t k = *(uint32_t*)data;

        k *= m;
        k ^= k >> r;
        k *= m;

        h *= m;
        h ^= k;

        data += 4;
        len -= 4;
    }

    /* Handle the last few bytes of the input array  */
    switch(len) {
    case 3: h ^= data[2] << 16;
    case 2: h ^= data[1] << 8;
    case 1: h ^= data[0]; h *= m;
    };

    /* Do a few final mixes of the hash to ensure the last few
     * bytes are well-incorporated. */
    h ^= h >> 13;
    h *= m;
    h ^= h >> 15;

    return (unsigned int)h;
}

1.2 解决键冲突

使用链地址法解决键冲突，因为dictEntry节点组成的链表没有指向链表表尾的指针，为了速度考虑，总是将新节点添加到链表的表头位置。

1.3 rehash

为字典的ht[1]哈希表分配空间，这个哈希表的空间大小取决于要执行的操作以及ht[0]当前包含的键值对数量（ht[0].used属性的值）：

若是扩展操作，ht[1]的大小为第一个大于等于ht[0].used*2的2的n次方幂。
若是收缩操作，ht[1]的大小为第一个大于等于ht[0].used的2的n次方幂。

将保存在ht[0]的所有键值对rehash到ht[1]上面：

重新计算键的哈希值和索引值，然后将键值对放置到ht[1]哈希表指定位置上。

当ht[0]包含的所有键值对都迁移到ht[1]之后，释放ht[0]，将ht[1]设置为ht[0]，并在ht[1]新创建一个空白哈希表，为下一次rehash做准备。

1.4 扩展和收缩

扩展条件：

若是服务器目前没有执行BGSAVE或BGREWRITEAOF命令，哈希表的负载因子大于等于1；
正在执行BGSAVE或BGREWRITEAOF命令，哈希表的负载因子大于等于5；

在执行BGSAVE或BGREWRITEAOF命令的过程中，Redis需要创建当前服务器进程的子进程，而大多数操作系统都采取写时复制技术来优化子进程的使用效率，所以在子进程存在期间，服务器会提高执行扩展操作所需的负载因子，从而尽可能地避免在子进程存在期间进行哈希表扩展操作，可以避免不必要的写入操作，最大限度的节约内存。

收缩条件：
当哈希表的负载因子小于0.1时，自动开始对哈希表执行收缩操作。

1.5 渐进式哈希

扩展或者收缩哈希表需要将ht[0[的所有键值对rehash到ht[1]里面，但是这个rehash动作不是一次性地、集中式完成的，而是分多次、渐进式完成的。
如果哈希表保存的键值对数量很多，一次性将它们全部rehash到ht[1]的话，庞大的计算量可能会导致服务器在一段时间内停止服务。

渐进式rehash的步骤：

为ht[1]分配空间，让字典同时持有两个哈希表
字典中维持一个索引计数器变量rehashidx，将其值设为0，表示rehash工作正式开始；
在rehash进行期间，每次对字典执行添加、删除、查找、更新时，程序除了执行指定的操作之外，还会顺带将ht[0]哈希表在rehashidx索引上的所有键值对rehash到ht[1]上，当rehash完成之后，程序将rehashidx属性的值加1；
随着对字典操作的不断执行，最终在某个时间点上，ht[0]的所有键值对都会被rehash到ht[1]上，此时将rehashidx设为-1，表示rehash操作完成

渐进式rehash的好处在于它采取分而治之的方式，将rehash键值对的计算工作均摊到对字典的每个添加、删除、查找、更新操作上，避免了集中式rehash带来的庞大计算量。

渐进式rehash执行期间的哈希表操作

在渐进式rehash过程中，字典会同时使用ht[0]和ht[1]两个哈希表，在渐进式rehash期间，字典的delete 、find 、update会在两个哈希表上进行。例如要在字典查找一个键的话，现在ht[0]里面查找若没找到会继续到ht[1]里面进行查找；
新增的键值对一律保存到ht[1]，ht[0]不再进行任何添加操作，保证了ht[0]包含的键值对数量只减不多。