redis面试（三）Hash数据结构

HASH

哈希，在redis底层实现的时候，数据的结构叫做dict

这个Dict就是一个用于维护key和value映射关系的数据结构，与很多语言中的Map类型相似。

本质上也是一个数组+链表的形式存在，不同的点在于，每个dict中是可以存在两个（数组+链表）形式的哈希表。

就是为了在扩容的时候避免一次性对所有的key进行重哈希计算操作，而是将重哈希操作分散到之后每次的增删改查中。 这样一来，每次重哈希的时候也不影响单个请求，与redis“快速相响应时间”的设计原则是相符的。

结构

dict为了实现增量式重哈希，在数据结构里面包含两个哈希表。重哈希期间，也就是扩容时候，将数据从第一个哈希表向第二个哈希表迁移。

包含的结构类型有三种，从大到小的结构类型依次是：
dict -> dictht -> dictEntry

具体的结构定义如下：

dict

哈希本身的包装类，也就是我们操作的Hash

typedef struct dict {dictType *type; // 类型特性的函数，保存了操作特定类型kv的函数void *privdata;	// 私有数据，传递给类型特定函数的可选的参数dictht ht[2];	// 哈希表，两个dictht哈希表，默认就用一个，另外一个是在rehash(扩容)的时候用的，ht[0]->在使用的hashtable，ht[1]->备用的hashtableint trehashidx;	// rehash索引，默认是-1，因为没有进行rehash
}

dictht

真正的hash表

typedef struct dictht {dictEntry **table;	// 数组，放我们的一个一个的key-value对，就是放在数组里unsigned long size; // 数组大小unsigned long sizemask; // 掩码，根据key hash计算数组里面的索引值，size-1unsigned long used; // 已有的节点数量
} dictht;

dictEntry

key-value 键值结构对，并且里面包含链表的指针

typedef struct dictEntry {void *key; // key值union { // value值void *val;uint64_tu64;int64_ts64;
} v;struct dictEntry *next; // 指向下一个节点，单向链表结构，解决hash冲突问题的
} dictEntry;

dictType

这个结构严格上来说，并不是dict本身数据结构的一部分，而是一些封装好的操作方法

typedef struct dictType {// hash方法，根据关键字计算哈希值unsigned int (*hashFunction)(const void *key);// 复制keyvoid *(*keyDup)(void *privdata, const void *key);// 复制valuevoid *(*valDup)(void *privdata, const void *obj);// 关键字比较方法int (*keyCompare)(void *privdata, const void *key1, const void *key2);//  销毁keyvoid (*keyDestructor)(void *privdata, void *key);// 销毁valuevoid (*valDestructor)(void *privdata, void *obj);} dictType;

结构总结

• 一个dict中，会包含两个dictht（dict hash table）
• dictht中会包含所有的 dictEntry(键值对)
• 两个dictht在扩容的时候会用到第二个

hash计算

hash = dict->tpe->hashFunction(key); // Mermerhash2，是hash值的计算算法
index = hash & dict->ht[0].sizemask; // hash值跟hashtable的sizemask掩码，做一个二进制与运算，算出来的结果，一定是数组->size->范围内的一个数字，掩码=size-1，算出来一定是最大也就是size-1

hash冲突

冲突是hash表常见的一个问题，数组大小是固定的，不同的key，key多个，不同的，但是不同的key算出来的hash值也是不同的，不同的hash值算出来的数组里的index位置，有可能是一样的

但是一直往里面写入key的时候，很可能会有一个问题，那就是不同的key，但是算出来的index索引是一样的，这就是key冲突问题了，这个时候就得基于dictEntry的单向链表，来挂载一个位置的多个key了

数组扩容

如果要是放的数据太多了，数组放不下了，这就得扩容，扩容的时候，每个key都得重新计算索引位置了，这就是rehash，扩容的时候，ht[1]就是新的一个哈希表，他的大小是第一个大于等于ht[0].used * 2的2n次方，如果是缩容，那就是第一个大于等于ht[0].used的2n次方

ht[0].used = 15 * 2 = 30，找到第一个大于等于30的2n次方，2的5次方=32，32就是我们的下一次要扩容的数组大小

搞了一个新hash表以后，就可以把ht[0]里的所有key都rehash到ht[1]里了，崇安计算索引值，解决key冲突问题，全部迁移完毕之后，就会释放掉ht[0]了，把ht[1]设置为ht[0]，然后在ht[1]创建空的hash表

rehash扩容缩容的触发

如果说同一个位置，他的元素的个数实在是太多了，单向链表太长了，hget的时候，key，hash，index，一下子发现这个数组那里，那个位置，单向链表实在是太长了，O(n)时间复杂度，去遍历单向链表，一个一个去寻找这个key

老hashtable放的数据太多了，多到一定程度了，就会触发rehash，多到多少才会去触发rehash呢？
触发rehash是跟负载因子有关系的，这个负载因子计算公式是，已有节点数量/哈希表数组大小，就是load_factor = ht[0].used / ht[0].size，当我们的负载因子达到一定的程度的时候，就会触发rehash动作

如果要是redis没有执行rdb和aof的持久化动作，redis负载不会太高，可控一些，此时一直到负载因子为1，就进行rehash扩容，也就是数组满了再说；但是如果rdb和aof再执行动作，这个时候只要负载因子超过5，这意思就是说，rdb和aof执行的过程中，你就别扩容了

rdb和aof执行的时候，是要开子进程来执行的，很耗费内存和cpu，所以这个时候，就要避免进行hash表扩容了，此时无非就是说，很多写入都是用单向链表挂再一个位置就行了，没问题的

渐进式迁移

如果负载因子小于0.1了，就要对hash表进行收缩操作，扩容也好，缩容也把，对于ht[1]的新size的计算公式，都给大家讲过了，当你创建好了一个ht[1]之后，迁移，渐进式的迁移机制来做的

另外就是说，在rehash的时候，如果hash表里数据太多了，你要一下子执行rehash，会导致负载太高，对性能有影响，所以此时不是一下子全部进行rehash的，一下子rehash的数量太多了，会导致负载很高，redis服务器的性能，不对的，是渐进式的，分批次，逐步的执行rehash动作

hashidx默认是-1，改为0以后就开始rehash了，每次执行hash表操作，就会把index=n的所有元素迁移到ht[1]里去，然后hashidx++，这样随着你不停的执行hash表操作，就会逐步的把ht[0]各个索引位置的元素迁移到ht[1]里去了，一直到所有元素都迁移完毕，然后就会把rehashidx改为-1

在rehash期间，新的hash操作，都是针对ht[1]写入的，同时迁移ht[0]，在读取的时候，会在ht[0]里找一下，找不到再去ht[1]里找，这就ok了

负载因子触发rehash，新数组的size计算公式，rehashidx渐进式迁移