Redis字典实现、Hash键冲突以及渐进式rehash

本笔记参考《Redis设计与实现》 P24~ 37

Redis字典实现

哈希表节点结构

typedef struct dictEntry
{
	// 键
	void *key;

	// 值 : 可以是一个指针,或者是一个uint64/int64 的整数
	union {
		void *val;
		uint64_t u64;
		int64_t s64
	} v;

	// 指向下一个哈希表节点,形成链表 : 该指针可以将多个哈希值相同的键值对连接在一起,以此解决键冲突的问题。
	struct dictEntry *next;
} dictEntry;

哈希表结构

typedef struct dictht
{
	// 哈希表数据
	dictEntry **table;

	// 哈希表集合大小
	unsigned long size;

	// 哈希表大小掩码,用于计算索引值
	// 总是等于 size - 1
	unsigned long sizemask;

	// 哈希表已有节点数量
	unsigned long used;
} dictht;

字典

typedef struct dict 
{
	// 类型特定函数
	dicType *type;

	// 私有数据
	void *privdata;

	// 哈希表
	dictht ht[2];

	// rehash 索引
	// 当rehash不在进行时, 值为-1
	int rehashidx;
} dict;

type属性和privdata属性针对不同类型的键值对,为多态字典而设置。
ht是包含两个项的数组,每个元素都是一个dictht哈希表,一般情况下字典之是哟个ht[0],ht[1]会在对ht[0]进行rehash的时候使用。
rehashidx记录了rehash目前的进度,如果目前没有在进行rehash,值为-1。

哈希算法

  • 使用字典设置的哈希函数,计算key的hashvalue
    hash = dict->type->hashFunction(key);

  • 使用哈希表的sizemask属性和哈希值,计算出索引值

  • 根据不同的情况,ht[x]可以是ht[0]或ht[1]
    index = hash & dict->ht[x].sizemask;

redis使用的是MurmurHash算法,优点是:输入的键是有规律的时候,算法仍然能给出很好的随机分布性,计算速度也快。

解决hash冲突

当有两个或以上的key分配到了hash table数组的同一个index上,称为发生了collision。
Redis采用链地址法解决冲突,每个hash table节点都有一个next指针,多个hash table节点可以用next指针构成一个单向链表。为了速度考虑,程序总是会将新节点插入到链表头位置。

rehash

随着操作不断执行,哈希表保存的key value对会逐渐增加和减少。哈希表有一个统计参数load factor,即负载因子,公式如下:

# 负载因子 = 哈希表已经保存的节点数量 / 哈希表大小
load_factor = ht[0].used / ht[0].size;

为了维持负载因子在一个合理的范围,程序会对哈希表的大小进行相应的扩展或收缩,条件如下:

  • 1、服务器目前没有执行BGSAVE命令或者BGREWRITEAOF命令,并且哈希表的负载因子 >= 1
  • 2、服务器正在执行BGSAVE命令或者BGREWRITEAOF命令,且负载因子 >= 5
    在执行BGSAVE命令或者BGREWRITEAOF命令过程中,Redis需要创建当前服务器进程的子进程,大多的OS采用写时复制技术优化子进程的使用效率,所以子进程存在期间,**服务器会提高执行扩展操作的负载因子,避免在子进程存在期间进行哈希表的扩展操作,避免不必要的内存写入操作,最大限度节约内存。**当负载因子小于0.1时,程序自动对哈希表进行收缩操作。
    此时就会进行扩展收缩,规则如下:
    这里就是rehash(重新散列)操作了:
  • 1、为字典的ht[1]哈希表分配内存空间,空间大小取决于要执行的操作,以及ht[0]当前包含的键值对数量(ht[0].used)
    • 如果是扩展操作,ht[1]的大小为 >= ht[0].used * 2的 2的幂次方
    • 如果是收缩操作,ht[1]的大小为 >= ht[0].used 的 2的幂次方
  • 2、将保存在ht[0]中的所有键值对rehash到ht[1]上:即重新计算key的hashValue以及indexValue,然后将键值对放到ht[1]的指定位置
  • 3、当ht[0]包含的所有键值对都迁移到ht[1]之后,ht[0]变为空表,释放ht[0],将ht[1]置为ht[0],在ht[1]重新分配一个空白的哈希表,为下一次rehash做准备

渐进式hash

rehash的动作并不是一次性集中完成的,而是分多次渐进完成。
如果哈希表中村的键值对数量很多,一次性将键值对全部rehash到ht[1]的计算量十分庞大,可能会导致服务器在一段时间内停止服务。
渐进式rehash采取分而治之的方法,将rehash键值对所需要的计算工作分摊到每次对字典的CRUD操作上,从而避免了集中式rehash带来的庞大计算量。
详细步骤如下:
1、为ht[1]分配空间,让字典同时持有ht[0]和ht[1]两个哈希表
2、在字典中维护一个索引计数器:rehashidx,将值设置为0,表示rehash工作正式开始。
3、在rehash进行期间,每次对字典的CRUD操作,程序除了执行指定操作以外,顺带将ht[0]哈希表在rehashidx索引上的所有键值对rehash到ht[1]上,当rehash操作完成后,程序将rehashidx值++
4、重复迭代操作执行后,ht[0]的数据全部rehash到ht[1]上,将rehashidx设为-1,表明rehash操作已经完成

需要注意的地方
在rehash的过程中,对于字典的删除、查找、更新操作会在两个哈希表上执行。如想要查找一个键,现在ht[0]中找,没有找到再去ht[1]
对于insert操作来说,新添加到字典的键值对会一律保存到ht[1]中,不然还得多一次搬运。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
Redis渐进式rehash是一种在进行哈希表扩容或收缩时的一种渐进式处理方式。它避免了Redis阻塞的问题,但也带来了一些其他的问题。在进行渐进式rehash时,Redis需要分配一个新的哈希表,并为该哈希表分配新的大小的内存。这导致了Redis内存使用量瞬间增加,并且在Redis满容状态下,rehash操作会导致大量的Key被驱逐。 为了解决这个问题,Redis实现了辅助服务器来在读写操作时进行渐进式rehash操作。但是如果服务器比较空闲,Redis数据库将会长时间同时使用两个哈希表。为了处理这种情况,Redis周期函数在发现字典正在进行渐进式rehash操作时,会花费1毫秒的时间来帮助进行渐进式rehash操作。 总之,Redis渐进式rehash是一种有效避免阻塞的哈希表扩容或收缩方式,但在操作过程中可能会导致内存使用量增加和大量Key被驱逐的问题。为了处理这些问题,Redis使用辅助服务器和周期函数来优化渐进式rehash操作。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* *3* [Redis详解(六)渐进式rehash机制](https://blog.csdn.net/fedorafrog/article/details/104633237)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v92^chatsearchT0_1"}}] [.reference_item style="max-width: 100%"] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

拾牙慧者

欢迎请作者喝奶茶

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值