Redis服务器通过fork子进程形式执行bgsave及bgrewriteaop操作，此时整个服务的资源耗费较大，为了避免可能发生的rehash带来额外的资源压力，此期间，服务器会调高触发执行扩展操作的负载因子界限。
2、收缩时机：load_factor < 0.1
3、rehash 基本操作：a) 为dict.ht[1]分配空间：
空间大小计算如下：
扩展：最小n满足2n >= dict.ht[0].used * 2
收缩：最小n满足2n >= dict.ht[0].used
如下图：ht[0].used = 3，假定无bg相关任务，则h[1]大小需要计算：2n >= 3 * 2 = 6
n = 3，ht[1].size = 23 = 8
b) rehash
对于dict.ht[0] 中的元素，依据dict.ht[1]特性（sizemask）重新计算索引值，并放置到dict.ht[1]中。
c) 当所有元素迁移完毕，释放dict.ht[0]，并将dict.ht[1]设置为dict.ht[0]，重新在dict.ht[1]上创建空的哈希表。
所谓渐进式，是针对大数据量字典数据。直接一次性的执行rehash会导致服务资源的集中占用，影响正常的服务响应。因此需要进行分而治之。
这里会用到上面我们介绍的dict字典结构中的 rehashidx属性，用以标识当前rehash进度。
首先将rehashidx置0，标示rehash开始，每次rehash一个元素，rehashidx值增加1，当最终所有元素rehash完成，将rehashidx置-1。
这里需要说明下rehash中对正常的服务请求的处理：
1、删除、查找、更新：会涉及到两个哈希表（ht[0]、ht[1]）操作，如查找元素，首先尝试在ht[0]上查找，找不到，则继续在h[1]上查找。
2、添加添加元素只会在h[1]上操作，h[0]上只减不增。