Redis哈希表总结

本文及后续文章,Redis版本均是v3.2.8

在文章《Redis 数据结构之dict》《Redis 数据结构之dict(2)》中,从代码层面做了简单理解。总感觉思路的不够条理性,特开一篇文章把哈希表中几个知识点串联下。

一、先来回顾下哈希表结构定义

/**

* 哈希表

*/

typedef struct dictht {

// 哈希表节点指针数组(俗称桶,bucket)

dictEntry **table;

// 指针数组的大小

unsigned long size;

// 指针数组的长度掩码,用于计算索引值

unsigned long sizemask;

// 哈希表现有的节点数量

unsigned long used;

} dictht;

table属性是一个数组,数组中的每个元素都是一个指向dict.h/dictEntry结构的指针,每个dictEntry结构保存着一个键值对。size属性记录了哈希表的大小,也即是table数组的大小,而used属性则记录了哈希表目前已有节点(键值对)的数量。sizemask属性的值总是等于size-1,这个属性和哈希值一起决定一个键应该被放到table数组的哪个索引上面。

一个大小为4的空哈希表结构:

图1-1 大小为4的空哈希表

哈希表节点结构定义

/**

* 哈希表节点

*/

typedef struct dictEntry {

// 键

void *key;

// 值

union {

void *val;

uint64_t u64;

int64_t s64;

} v;

// 链往后继节点

struct dictEntry *next;

} dictEntry;

哈希表节点使用dictEntry结构表示,每个dictEntry结构都保存着一个键值对。

key属性保存着键值对中的键,而v属性则保存着键值对中的值,其中键值对的值可以是一个指针,或者是一个uint64t整数,又或者是一个int64t整数。

next属性是指向另一个哈希表节点的指针,这个指针可以将多个哈希值相同的键值对连接在一次,以此来解决键冲突(collision)的问题。

二、哈希算法

当要将一个新的键值对添加到字典里面时,程序需要先根据键值对的键计算出哈希值和索引值,然后再根据索引值,将包含新键值对的哈希表节点放到哈希表数组的指定索引上面。

Redis计算哈希值和索引值的方法如下:

  • 使用字典设置的哈希函数.计算键key的哈希值

hash=dict->type->hashFunction(key);

  • 使用哈希表的sizemask属性和哈希值,计算出索引值
  • 根据情况不同,ht[x]可以是ht[0]或者ht[1]

index=  hash&dict->ht[x].sizemask

举个例子,对于空的字典来说,如果我们要将一个键值对k0和v0添加到字典里面。

那么程序会先使用语句:

hash=dict->type->hashFunction(k0);

计算键k0的哈希值。

假设计算得出的哈希值为8,那么程序会继续使用语句:

index = hash&dict->ht[0] .sizemask = 8 & 3 = 0;

计算出键k0的索引值0,这表示包含键值对k0和v0的节点应该被放置到哈希表数组的索引0位置上。

空的字典、添加键值对k0和v0的结构,如下图所示。

图1-2空字典

图1-3 添加键值对K0和V0之后的字典

三、解决键冲突

当有两个或以上数量的键被分配到了哈希表数组的同一个索引上面时,我们称这些键发生了冲突(collision)。

Redis的哈希表使用链地址法(separatechaining)来解决键冲突,每个啥希表节点都有一个next指针,多个哈希表节点可以用next指针构成一个单向链表,被分配到同一个索 引上的多个节点可以用这个单向链表连接起来,这就解决了键冲突的问题 。

举个例子,假设程序要将键值对k2和v2添加到图1-4所示的哈希表里面,并且计算得出k2的索引值为2,那么键k1和k2将产生冲突,而解决冲突的办法就是使用next指针将键k2和k1所在的节点连接起来,如图1-5所示。

因为dictEntry节点组成的链表没有指向链表表尾的指针,所以为了速度考虑,程序总是将新节点添加到链表的表头位置(复杂度为0(1)),排在其他已有节点的前面。

图1-4 一个包含两个键值对的哈希表

图1-5 使用链表解决k1和k2的冲突

四、Rehash

上两篇文章提到dict结构中ht属性是一个包含两个项的数组,数组中的每个项都是一个dictht晗希表,一般情况下,字典只使用ht[0)哈希表,ht[1]哈希表只会在对ht[0]哈希表进行rehash时使用。除了ht[1]之外,另一个和rehash有关的属性就是rehashidx,它记录了rehash目前的进度,如果目前没有在进行rehash,那么它的值为-1。

我们看下一个普通状态下的字典即没有进行rehash的字典:

图1-6 没有进行rehash的字典

随着操作的不断执行,哈希表中保存的键值对会逐渐地增多或者减少,为了让哈希表的负载因子(loadfactor)维持在一个合理的范围之内,当哈希表保存的键值对数量太多或者太少时,程序需要对哈希表的大小进行相应的扩展或者收缩 。如果节点数量比哈希表的大小要大很多的话,那么哈希表就会退化成多个链表,哈希表本身的性能优势便不复存在。这个就是我们上篇文章中说到的哈希表扩展和收缩策略。

扩展和收缩哈希表的工作可以通过执行   rehash  (重新散列)操作来完成, Redis对字典的哈希表执行rehash的步骤如下:

  • 为字典的ht[1]哈希表分配空间,这个哈希表的空间大小取决于要执行的操

    作,以 及ht[0]当前包含的键值对数量(也即是ht[0].used属性的值):

1、如果执行的是扩展操作,那么ht[1]的大小为第一个大于等于ht[0].used*2

的2"(2的n次方幕)。

2、如果执行的是收缩操作,那么ht[1]的大小为第一个大于等于ht[0].used的2"(2的n次方幕)。

  • 将保存在ht[0]中的所有键值对rehash到ht[1]上面:  rehash指的是重新计

算键的哈希值和索引值,然后将键值对放置到ht[1]晗希表的指定位置上。

  • 当ht[0]包含的所有键值对都迁移到了ht[1)之后(ht[0]变为空表),释放ht[0],将ht[1]设置为ht[0],并在ht[1]新创建一个空白哈希表,为下一次rehash做准备。

举个例子,我们对下图1-7所示字典的ht[0]进行扩展操作,那么程序执行的过程是怎么样一个过程哪?

图1-7 执行rehash之前的字典

1、ht[0].used当前的值为4,4*2=8,而8(23)恰好是第一个大于等于4的2的n次方,所以程序会将ht[l]晗希表的大小设置为8。图1-8展示了ht[1]在分配空间之后,字典的样子。

图1-8

2)将ht[0]包含的四个键值对都rehash到ht[1],如图1-9所示

图1-9

3)释放ht[0],并将ht[l]设置为ht[0],然后为ht[l]分配一个空白哈希表,如

图1-10所示。至此,对哈希表的扩展操作执行完毕,程序成功将哈希表的大小从原来的 4改为了现在的8。

图1-10

四、渐进式rehash

扩展或收缩哈希表需要将ht[0]里面的所有键值对rehash到ht[1] 里面,但是,这个rehash动作并不是一次性、集中式地完成的,而是分多次、渐进式地完成的。

这样做的原因在于,如果  ht[0]里只保存着四个键值对,那么服务器可以在瞬间就将这些键值对全部rehash到ht[1]。但是,如果哈希表里保存的键值对数量几千甚至上万百万个键值对,那么要一次性将这些键值对全部rehash到ht[1]的话,庞大的计算量可能会导致服务器在一段时间内停止服务。

因此,为了避免rehash对服务器性能造成影响,服务器不是一次性将ht[0]里面的所有键值对全部rehash到ht[1],而是分多次、渐进式地将ht[0]里面的键值对慢慢地rehash到ht[1]。

以下是哈希表渐进式rehash的详细步骤:

1、为ht[1]分配空间,让字典同时持有ht[0]和ht[1]两个哈希表。

2、在字典中维持一个索引计数器变量rehashidx,并将它的值设置为0 ,表示rehash工作正式开始。

3、在rehash进行期间,每次对字典执行添加、删除、查找或者更新操作时,程序除了执行指定的操作以外,还会顺带将ht[0]哈希表在rehashidx索引上的所有键值对rehash到ht[1]。当rehash工作完成之后,程序将rehashidx属性的值增加1。

4、随着字典操作的不断执行,最终在某个时间点上,ht[0]的所有键值对都会被rehash至ht[1],这时程序将rehashidx属性的值设为-1,表示rehash操作已完成。

渐进式rehash的好处在于它采取分而治之的方式,将 rehash键值对所需的计算工作均摊到对字典的每个添加、删除、查找和更新操作上,从而避免了集中式  rehash而带来的庞大计算量。

因为在进行渐进式rehash的过程中,字典会同时使用ht[0]和ht[l]两个哈希表,所以在渐进式rehash进行期间,字典的删除(delete)、查找(find)、更新(update)等操作会在两个哈希表上进行。例如,要在字典里面查找一个键的话,程序会先在ht[0]里面进行查找,如果没找到的话,就会继续到ht[l]里面进行查找,诸如此类。

另外,在渐进式rehash执行期间,新添加到字典的键值对一律会被保存到ht[1]里面,而ht[0]则不再进行任何添加操作,这一措施保证了ht[0]包含的键值对数量会只减不增,并随着rehash操作的执行而最终变成空表。

图1-11至图1-16展示了一次完整的渐进式rehash过程,注意观察在整个rebash过程中,字典的 rehashidx属性是如何变化的?

图1-11 准备开始rehash

图1-12 rehash索引0上的键值对

图1-13 rehash索引1上的键值对

图1-14 rehash索引2上的键值对

图1-15 rehash索引3上的键值对

图1-16 rehash执行完毕

参考:《Redis设计与实践》

-EOF-

时间: 2024-10-11 00:02:39

Redis哈希表总结的相关文章

(四)Redis哈希表Hash操作

Hash的全部操作如下: hset key field value # 将哈希表key中的字段field的值设为value hget key field # 返回哈希表key中的字段field的值value hmset key field1 value1 field2 value2 ... # 将多个field-value对设置到哈希表key中 hmget key field1 field2 ... # 返回哈希表key中字段field1,field2,...的值 hgetall key # 返

Redis源码研究—哈希表

Redis源码研究-哈希表 Category: NoSQL数据库 View: 10,980 Author: Dong 作者:Dong | 新浪微博:西成懂 | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明 网址:http://dongxicheng.org/nosql/redis-code-hashtable/ 本博客的文章集合:http://dongxicheng.org/recommend/ 本博客微信公共账号:hadoop123(微信号为:hadoop-123),分享

Redis源码研究:哈希表 - 蕫的博客

[http://dongxicheng.org/nosql/redis-code-hashtable/] 1. Redis中的哈希表 前面提到Redis是个key/value存储系统,学过数据结构的人都知道,key/value最简单的数据结果就是哈希表(当然,还有其他方式,如B-树,二叉平衡树等),hash表的性能取决于两个因素:hash表的大小和解决冲突的方法.这两个是矛盾的:hash表大,则冲突少,但是用内存过大:而hash表小,则内存使用少,但冲突多,性能低.一个好的hash表会权衡这两个

redisTemplate写哈希表遇到的坑

在使用spring的redisTemplate进行redis哈希表的相关操作时,遇到了下面比较奇怪的情况: 1.删掉哈希表所属的key之后,重新get这个key的值,得到的不是null,而是一个空的map 2.直接get一个不存在的key,得到的不是null,而是一个空的map 3.set进去一个null值值后,重新set一个非空的map,这个key对应的仍然是一个null 那先看一下我写的setHash和getHashTable这两个方法: 1.首先setHashTable public vo

Redis源码解析(四):redis之数据类型哈希表、列表、集合和有序集合

哈希表也是redis支持的数据结构之一,它使用REDIS_ENCODING_ZIPLIST(压缩列表) 和REDIS_ENCODING_HT(数据字典) 两种编码方式. 当哈希表使用压缩列表时,它使用如下的结构存储数据(详见ziplist.c): +---------+------+------+------+------+------+------+------+------+---------+ | ZIPLIST | | | | | | | | | ZIPLIST | | ENTRY |

Redis学习笔记09Redis数据类型之(2) 哈希表类型

1.1.1. hset 向hash中添加键值对. 语法: HSET key field value 参数: key :键名称,键值为一个hash表对象. field:hash表中的键名. value:hash表中的键值. 返回值: 整数:1,成功添加了一个原来不存在的新的键对应的键值对. 0,成功的更新了一个原来存在的键对应的键值对. ERROR:key对应的对象存在,但是并不是哈希表类型. 例子: redis.coe2coe.me:6379> hset myhash  host redis.c

Redis命令学习—Hash(哈希表)操作

HDEL HDEL key field [field...]:删除Hash key中的一个或多个域, 不存在的域会被忽略. 返回值:被成功删除的key的数量. # 测试数据 redis> HGETALL abbr 1) "a" 2) "apple" 3) "b" 4) "banana" 5) "c" 6) "cat" 7) "d" 8) "dog&qu

Redis常用操作-------Hash(哈希表)

1.HDEL key field [field ...] 删除哈希表 key 中的一个或多个指定域,不存在的域将被忽略. 在Redis2.4以下的版本里, HDEL 每次只能删除单个域,如果你需要在一个原子时间内删除多个域,请将命令包含在 MULTI / EXEC块内. 可用版本: >= 2.0.0 时间复杂度: O(N), N 为要删除的域的数量. 返回值: 被成功移除的域的数量,不包括被忽略的域. # 测试数据 redis> HGETALL abbr 1) "a" 2)

深入理解哈希表

有两个字典,分别存有 100 条数据和 10000 条数据,如果用一个不存在的 key 去查找数据,在哪个字典中速度更快? 有些计算机常识的读者都会立刻回答: “一样快,底层都用了哈希表,查找的时间复杂度为 O(1)”.然而实际情况真的是这样么? 答案是否定的,存在少部分情况两者速度不一致,本文首先对哈希表做一个简短的总结,然后思考 Java 和 Redis 中对哈希表的实现,最后再得出结论,如果对某个话题已经很熟悉,可以直接跳到文章末尾的对比和总结部分. 哈希表概述 Objective-C 中