redis数据结构—哈希表

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: redis数据结构—哈希表

我在“redis存储结构”这篇文章中介绍了redis存储数据的方式——字典,redis的字典使用高效的hash table实现,这里详细介绍redis中哈希表的实现和工作原理

redis的哈希表结构
typedef struct dictht {
    //哈希表数组
    dictEntry **table;
    //哈希表大小
    unsigned long size;  
    //哈希表大小掩码,用于计算索引值
    unsigned long sizemask;
    //该哈希表已有的节点数量
    unsigned long used;
} dictht;

可以看到,redis的哈希表只是比我们常用的哈希表多了size、sizemask、used这三个额外字段,这三个字段是用来支持其它功能的,本文不详细介绍

redis的哈希表节点
typedef struct dictEntry {
    //键值对中的键
    void *key;
  
    //键值对中的值
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    //指向下一个哈希表节点,形成链表
    struct dictEntry *next;
} dictEntry;

1.next指针是用来解决哈希冲突的,没错,redis解决哈希冲突的方案是链地址法,也就是将哈希值相同的节点用链表组织起来,而redis使用rehash保证了这个链表的长度的不会太长,后面会详细介绍

2.key指向固定的对象string,这一点在“redis存储结构”文章中已经解释过

3.value使用union来实现保存不同类型值的功能,提供了较强的灵活性,且避免了全部使用指针的情况,节约了内存

哈希表的添加过程不再赘述,属于基础数据结构的范畴

解决哈希冲突

一、rehash

上文提到,redis使用链地址法解决哈希冲突,由于哈希表的数组长度在创建时就固定了,当节点数量过多时会造成链表长度过长,导致查询的时间复杂度降为O(N),导致性能降低的一个原因是数组长度,另一个是hash算法

redis的做法是,使用两个哈希表,一个为目前使用的,另一个为空,在当前使用的哈希表节点数等于数组长度时,即将发生哈希冲突,此时将另一个哈希表数组长度设置为当前的2倍,并将旧数组中的节点迁移到新数组中,这样一来,新的哈希表成为当前所使用的,并且数组的长度得到了增长,缓解了数组空间不足造成的哈希冲突

所以redis在使用哈希表时,实际上有两个哈希表,一个供当前使用,另一个供rehash使用

typedef struct dict {
    //两个Hash表,交替使用,用于rehash操作
    dictht ht[2]; 
} dict;

当旧哈希表的数据全部迁移到新哈希表后,旧哈希表的空间会被释放

rehash的过程可以进行多次,基于两个哈希表的交替使用来实现

一次性rehash的缺陷

按照我们的想法,当旧哈希表的节点数等于数组长度时,考虑进行rehash

1.rehash是一次性进行的吗?

2.rehash的过程中如果有新的数据添加进来,该怎么处理?

3.rehash的过程中如果要进行数据查找,去哪找?

当旧哈希表中的节点数量比较庞大时,一次性rehash会造成redis阻塞较长时间,无法响应其他请求,这显然不是redis的风格

渐进式rehash

既然一次性rehash会造成性能下降,那么分批次进行不就好了,

redis的方案是在 rehash 进行期间,每次哈希表元素进行新增、删除、查找或者更新操作时,Redis 除了会执行对应的操作之外,还会顺序将「旧哈希表」中索引位置上的所有 key-value 迁移到「新哈希表」 上

回到上面的问题

分次rehash的过程中会出现数据分布的情况,也就是一些数据在新哈希表中,另一些数据在旧哈希表中:

Q:

1.rehash的过程中如果有新的数据添加进来,该怎么处理?

2.rehash的过程中如果要进行数据查找,去哪找?

A:

1.如果有新的数据添加进来,将添加到新哈希表中,保证了旧哈希表的节点数只会减少,最终为空

2.先查找旧哈希表,如果没有,再查找新哈希表

rehash触发条件

在上文简单提到,当哈希节点数等于数组长度时,我们认为即将发生哈希冲突(实际上有可能已经发生),那么rehash的具体时机是怎么确定的?

触发 rehash 操作的条件,主要有两个:

  • 当负载因子大于等于 1 ,并且 Redis 没有在执行 bgsave 命令或者 bgrewiteaof 命令,也就是没有执行 RDB 快照或没有进行 AOF 重写的时候,就会进行 rehash 操作。
  • 当负载因子大于等于 5 时,此时说明哈希冲突非常严重了,不管有没有有在执行 RDB 快照或 AOF 重写,都会强制进行 rehash 操作。
  • 当负载因子小于0.1时,程序自动进行缩容操作

负载因子 = 哈希表中当前节点数 / 哈希表数组大小

推荐学习 https://xxetb.xetslk.com/s/p5Ibb

目录
相关文章
|
3月前
|
存储 缓存 NoSQL
【📕分布式锁通关指南 12】源码剖析redisson如何利用Redis数据结构实现Semaphore和CountDownLatch
本文解析 Redisson 如何通过 Redis 实现分布式信号量(RSemaphore)与倒数闩(RCountDownLatch),利用 Lua 脚本与原子操作保障分布式环境下的同步控制,帮助开发者更好地理解其原理与应用。
240 6
|
2月前
|
消息中间件 缓存 NoSQL
Redis各类数据结构详细介绍及其在Go语言Gin框架下实践应用
这只是利用Go语言和Gin框架与Redis交互最基础部分展示;根据具体业务需求可能需要更复杂查询、事务处理或订阅发布功能实现更多高级特性应用场景。
261 86
|
4月前
|
存储 缓存 NoSQL
Redis核心数据结构与分布式锁实现详解
Redis 是高性能键值数据库,支持多种数据结构,如字符串、列表、集合、哈希、有序集合等,广泛用于缓存、消息队列和实时数据处理。本文详解其核心数据结构及分布式锁实现,帮助开发者提升系统性能与并发控制能力。
|
2月前
|
存储 消息中间件 NoSQL
Redis数据结构:别小看这5把“瑞士军刀”,用好了性能飙升!
Redis提供5种基础数据结构及多种高级结构,如String、Hash、List、Set、ZSet,底层通过SDS、跳表等实现高效操作。灵活运用可解决缓存、计数、消息队列、排行榜等问题,结合Bitmap、HyperLogLog、GEO更可应对签到、UV统计、地理位置等场景,是高性能应用的核心利器。
|
2月前
|
存储 缓存 NoSQL
Redis基础命令与数据结构概览
Redis是一个功能强大的键值存储系统,提供了丰富的数据结构以及相应的操作命令来满足现代应用程序对于高速读写和灵活数据处理的需求。通过掌握这些基础命令,开发者能够高效地对Redis进行操作,实现数据存储和管理的高性能方案。
111 12
|
2月前
|
存储 消息中间件 NoSQL
【Redis】常用数据结构之List篇:从常用命令到典型使用场景
本文将系统探讨 Redis List 的核心特性、完整命令体系、底层存储实现以及典型实践场景,为读者构建从理论到应用的完整认知框架,助力开发者在实际业务中高效运用这一数据结构解决问题。
|
2月前
|
存储 缓存 NoSQL
【Redis】 常用数据结构之String篇:从SET/GET到INCR的超全教程
无论是需要快速缓存用户信息,还是实现高并发场景下的精准计数,深入理解String的特性与最佳实践,都是提升Redis使用效率的关键。接下来,让我们从基础命令开始,逐步揭开String数据结构的神秘面纱。
|
6月前
|
存储 NoSQL 算法
Redis设计与实现——数据结构与对象
Redis 是一个高性能的键值存储系统,其数据结构设计精妙且高效。主要包括以下几种核心数据结构:SDS、链表、字典、跳跃表、整数集合、压缩列表。此外,Redis 对象通过类型和编码方式动态转换,优化内存使用,并支持引用计数、共享对象和淘汰策略(如 LRU/LFU)。这些特性共同确保 Redis 在性能与灵活性之间的平衡。
|
存储 消息中间件 NoSQL
Redis 数据结构与对象
【10月更文挑战第15天】在实际应用中,需要根据具体的业务需求和数据特点来选择合适的数据结构,并合理地设计数据模型,以充分发挥 Redis 的优势。
244 64
|
存储 NoSQL 算法
「Redis」数据结构与对象
Redis数据结构与对象介绍
144 0

热门文章

最新文章