redis系列之------字典
前言
字典， 又称符号表（symbol table）、关联数组（associative array）或者映射（map）， 是一种用于保存键值对（key-value pair）的抽象数据结构。
在字典中， 一个键（key）可以和一个值（value）进行关联（或者说将键映射为值）， 这些关联的键和值就被称为键值对。
字典中的每个键都是独一无二的， 程序可以在字典中根据键查找与之关联的值， 或者通过键来更新值， 又或者根据键来删除整个键值对， 等等。
字典经常作为一种数据结构内置在很多高级编程语言里面， 但 redis 所使用的 c 语言并没有内置这种数据结构， 因此 redis 构建了自己的字典实现。
字典在 redis 中的应用相当广泛， 比如 redis 的数据库就是使用字典来作为底层实现的， 对数据库的增、删、查、改操作也是构建在对字典的操作之上的。
因此，了解字典对我们了解redis数据库有很大的帮助。同时可以跟java的hashmap进行对比，看看孰好孰坏。
字典的定义
1 typedef struct dict {
2
3 // 类型特定函数
4 dicttype *type;
5
6 // 私有数据
7 void *privdata;
8
9 // 哈希表
10 dictht ht[2];
11
12 // rehash 索引
13 // 当 rehash 不在进行时，值为 -1
14 int rehashidx; /* rehashing not in progress if rehashidx == -1 */
15
16 } dict;
主要看ht，和rehashidx两个参数。
ht 属性是一个包含两个项的数组， 数组中的每个项都是一个 dictht 哈希表， 一般情况下， 字典只使用 ht[0] 哈希表， ht[1] 哈希表只会在对 ht[0] 哈希表进行 rehash 时使用。
除了 ht[1] 之外， 另一个和 rehash 有关的属性就是 rehashidx ： 它记录了 rehash 目前的进度， 如果目前没有在进行 rehash ， 那么它的值为 -1 。
1 typedef struct dictht {
2
3 // 哈希表数组
4 dictentry **table;
5
6 // 哈希表大小
7 unsigned long size;
8
9 // 哈希表大小掩码，用于计算索引值
10 // 总是等于 size - 1
11 unsigned long sizemask;
12
13 // 该哈希表已有节点的数量
14 unsigned long used;
15
16 } dictht;
table 属性是一个数组， 数组中的每个元素都是一个指向 dict.h/dictentry 结构的指针， 每个 dictentry 结构保存着一个键值对。
size 属性记录了哈希表的大小， 也即是 table 数组的大小
sizemask 属性的值总是等于 size-1 ， 这个属性和哈希值一起决定一个键应该被放到 table 数组的哪个索引上面。(不是很清楚，为什么要单独定义一个mask，而不直接size-1)；
而 used 属性则记录了哈希表目前已有节点（键值对）的数量。
1 typedef struct dictentry {
2
3 // 键
4 void *key;
5
6 // 值
7 union {
8 void *val;
9 uint64_t u64;
10 int64_t s64;
11 } v;
12
13 // 指向下个哈希表节点，形成链表
14 struct dictentry *next;
15
16 } dictentry;
key 属性保存着键值对中的键， 而 v 属性则保存着键值对中的值， 其中键值对的值可以是一个指针， 或者是一个 uint64_t 整数， 又或者是一个 int64_t 整数。
next 属性是指向另一个哈希表节点的指针， 这个指针可以将多个哈希值相同的键值对连接在一次， 以此来解决键冲突（collision）的问题。
可以明显的看出来，redis是通过链表来解决hash冲突的。
因此，redis的字典大概如下：
rehash
随着操作的不断执行， 哈希表保存的键值对会逐渐地增多或者减少， 为了让哈希表的负载因子（load factor）维持在一个合理的范围之内， 当哈希表保存的键值对数量太多或者太少时， 程序需要对哈希表的大小进行相应的扩展或者收缩。
也就是我们常说的，扩容，再次hash。
redis rehash过程：
- 为字典的
ht[1]哈希表分配空间。一般为原字典的两倍，即 ht[0] * 2； - 将保存在
ht[0]中的所有键值对 rehash 到ht[1]上面 - 当
ht[0]包含的所有键值对都迁移到了ht[1]之后 （ht[0]变为空表）， 释放ht[0]， 将ht[1]设置为ht[0]， 并在ht[1]新创建一个空白哈希表， 为下一次 rehash 做准备。
但其实rehash是非常的耗时间的。假设ht[0]非常的大呢？ 40w，400w，甚至4000w呢？
一次rehash甚至可能导致redis宕机，所以出现了渐进式hash。
渐进式rehash
这个 rehash 动作并不是一次性、集中式地完成的， 而是分多次、渐进式地完成的。为了避免 rehash 对服务器性能造成影响， 服务器不是一次性将 ht[0] 里面的所有键值对全部 rehash 到 ht[1] ， 而是分多次、渐进式地将 ht[0] 里面的键值对慢慢地 rehash 到 ht[1] 。
- 为
ht[1]分配空间， 让字典同时持有ht[0]和ht[1]两个哈希表。 - 在字典中维持一个索引计数器变量
rehashidx， 并将它的值设置为0， 表示 rehash 工作正式开始。 - 在 rehash 进行期间， 每次对字典执行添加、删除、查找或者更新操作时， 程序除了执行指定的操作以外， 还会顺带将
ht[0]哈希表在rehashidx索引上的所有键值对 rehash 到ht[1]， 当 rehash 工作完成之后， 程序将rehashidx属性的值增一。 - 随着字典操作的不断执行， 最终在某个时间点上，
ht[0]的所有键值对都会被 rehash 至ht[1]， 这时程序将rehashidx属性的值设为-1， 表示 rehash 操作已完成。
扩容代码大致如下：
1 int dictrehash(dict *d, int n) {
2 int empty_visits = n*10; /* max number of empty buckets to visit. */
3
4 // 判断是否正在扩容
5 if (!dictisrehashing(d)) return 0;
6
7 while(n-- && d->ht[0].used != 0) {
8 dictentry *de, *nextde;
9
10 /* note that rehashidx can't overflow as we are sure there are more
11 * elements because ht[0].used != 0 */
12 assert(d->ht[0].size > (unsigned long)d->rehashidx);
13
14 // 找到一个不为空的桶，进行迁移
15 while(d->ht[0].table[d->rehashidx] == null) {
16 d->rehashidx++;
17 if (--empty_visits == 0) return 1;
18 }
19 // 找到这个桶第一个指针节点
20 de = d->ht[0].table[d->rehashidx];
21 // 将这个桶中的所有的key节点转移到新的数组中。while循环链表
22 while(de) {
23 uint64_t h;
24
25 nextde = de->next;
26 /* get the index in the new hash table */
27 h = dicthashkey(d, de->key) & d->ht[1].sizemask;
28 de->next = d->ht[1].table[h];
29 d->ht[1].table[h] = de;
30 d->ht[0].used--;
31 d->ht[1].used++;
32 de = nextde;
33 }
34 // 旧的桶节点置为null，并且rehashidx+1
35 d->ht[0].table[d->rehashidx] = null;
36 d->rehashidx++;
37 }
38
39 /* check if we already rehashed the whole table... */
40 if (d->ht[0].used == 0) {
41 zfree(d->ht[0].table);
42 d->ht[0] = d->ht[1];
43 _dictreset(&d->ht[1]);
44 d->rehashidx = -1;
45 return 0;
46 }
47
48 /* more to rehash... */
49 return 1;
50 }
在进行渐进式 rehash 的过程中， 字典会同时使用 ht[0] 和 ht[1] 两个哈希表， 所以在渐进式 rehash 进行期间， 字典的删除（delete）、查找（find）、更新（update）等操作会在两个哈希表上进行： 比如说， 要在字典里面查找一个键的话， 程序会先在 ht[0]里面进行查找， 如果没找到的话， 就会继续到 ht[1] 里面进行查找， 诸如此类。
另外， 在渐进式 rehash 执行期间， 新添加到字典的键值对一律会被保存到 ht[1] 里面， 而 ht[0] 则不再进行任何添加操作： 这一措施保证了 ht[0] 包含的键值对数量会只减不增， 并随着 rehash 操作的执行而最终变成空表。
所遇到问提
问题一：
要在字典里面查找一个键的话， 程序会先在 ht[0]里面进行查找， 如果没找到的话， 就会继续到 ht[1] 里面进行查找， 诸如此类。
这一点其实我比较有疑惑？为何要先去ht[0]中查找，找不到再去ht[1]中查找，这样岂不是效率低下，查找了两张表。不能根据hash值和rehashidx进行比较判断么？只查一张表不行么？
为此我翻阅了不少资料：
这是redis官方其他人的pull request：https://github.com/antirez/redis/pull/5692 暂时还没有merge
同时这是我和一位大佬的讨论：https://github.com/junnplus/blog/issues/35 最终得出结论
还是看源码：(源码真是一个好东西)
1 for (table = 0; table <= 1; table++) {
2 // 找到key的index
3 idx = h & d->ht[table].sizemask;
4 // 拿到key值对应的value
5 he = d->ht[table].table[idx];
6 while(he) {
7 if (key==he->key || dictcomparekeys(d, key, he->key))
8 return he;
9 he = he->next;
10 }
11 if (!dictisrehashing(d)) return null;
12 }
其实只有两种情况
- key在ht[0]，还没有迁移
- key在ht[1]，已经迁移了。
针对第一种情况，他在第一层的循环已经找到了key值，并且返回(第八行)，不再继续后面操作，因此不存在效率问题。
第二种情况，看第五行，he此时为null，根本不会循环链表。然后第二次循环才能找到key。而第一次是做了一次hash，复杂度为o(1)。效率几乎是没有损失，因此也不存在效率问题。
综上：我得出的结论是。可以拿idx和rehashidx进行对比，同时也可以像redis这样写，不会损失效率。redis可能为了代码的简洁以及统一，不想写那么多的判断条件，因此没有比较idx和rehashidx。
当我认为提前结束会更好，毕竟不用后续判断了，也比较清楚。类似这个request：
问题二：
假如在redis准备进行rehash的时候，他需要为ht[1]申请一块内存，这块内存可是ht[0]的两倍哦，那次是计算机内存不存会如何？
梳理一下哈希表大小和内存申请大小的对应关系：
正常状态下，redis为ht[1]分配完内存后，会持续一段时间进行rehash。rehash完毕后，就会释放ht[0]内存了。类似如下图：
内存先上升，后下降。
但此时内存不存的话，redis会进行大量的key驱逐，也就是会淘汰掉很久未使用的key，跟lru有点类似。
那么此时可能就会影响到了业务，这是非常大的问题呢。
那么针对在redis满容驱逐状态下，如何避免因rehash而导致redis抖动的这种问题。
- 我们在redis rehash源码实现的逻辑上，加上了一个判断条件，如果现有的剩余内存不够触发rehash操作所需申请的内存大小，即不进行resize操作；
- 通过提前运营进行规避，比如容量预估时将rehash占用的内存考虑在内，或者通过监控定时扩容。
参考文献：
《redis设计与实现》 http://redisbook.com/preview/dict/incremental_rehashing.html
《美团针对redis rehash机制的探索和实践》 https://tech.meituan.com/2018/07/27/redis-rehash-practice-optimization.html
《redis源码分析》 https://github.com/junnplus/blog/issues/35