dict是Redis服务器中出现最为频繁的复合型数据结构,除hash使用dict之外,整个Redis数据库中所有的key和value也会组成一个全局字典,还有带过期时间的key集合也是一个字典。
zset集合中存储value和score的映射关系也是通过dict结构实现的。
dict内部是一个二维数组,包含两个hashtable。
通常情况下只有一个hashtable是有值的,但是在扩容、缩容时,需要分配新的hashtable,然后进行渐进式rehash,此时两个hashtable分别是旧的hashtable和新的hashtable。在rehash结束后,旧的hashtable被删除,新的hashtable取而代之。
从哈希表节点结构dictEntry中可以看到,每一个节点都有一个指向下一个dictEntry的指针,说明Redis中主要通过使用链表法解决哈希冲突,即每一个hashtable中存储的是一个链表,表中存储指向链表头部元素的指针。
假设字典中两个hashtable分别为h[0]和h[1],数据存储在h[0]中。
在执行rehash之前,需要为h[1]分配空间,这个hashtable的大小取决于需要执行的操作和当前h[0]包含键值对数量即h[0].used:
扩展操作:h[1]大小为第一个大于等于h[0].used*2的2的n次方幂
收缩操作:h[1]大小为第一个大于等于h[0].used的2的n次方幂
将保存在h[0]中的键值对rehash到h[1]上,rehash指重新计算键的hash值和索引值,然后将键值对放置在h[1]的指定索引位置上
所有键值对迁移完成之后,h[0]变成空表,此时释放h[0],然后将h[1]设置为h[0],最后在h[1]位置上新创建一个hashtable,为下一次rehash做准备
在进行rehash时,需要申请新数组,然后迁移所有键值对,这是一个时间复杂度为O(n)的操作,所以对于大字典的扩容需要耗费一定时间。
为避免阻塞,Redis使用渐进式rehash,多次、渐进地完成迁移,以避免集中式rehash带来的庞大计算量。
负载因子 = 已保存节点 / 哈希表大小即load_factor = ht[0].used / h[0].size
扩展时机
没有执行BGSAVE/BGREWRITEAOF时,负载因子大于等于1
执行BGSAVE/BGREWRITEAOF时,负载因子大于等于5
收缩时机
负载因子小于0.1
转载于:https://www.cnblogs.com/jeemzz/p/11440923.html
相关资源:JAVA上百实例源码以及开源项目