redis数据结构存储Dict设计细节(redis的设计与实现笔记)

说到redis的Dict(字典),虽说算法上跟市面上一般的Dict实现没有什么区别,但是redis的Dict有2个特殊的地方那就是它的rehash(重新散列)和它的字典节点单向链表。

以下是dict用到的结构:

typedef struct dictEntry {//字典的节点
    void *key;
    union {//使用的联合体
        void *val;
        uint64_t u64;//这两个参数很有用
        int64_t s64;
    } v;
    struct dictEntry *next;//下一个节点指针
} dictEntry;  

typedef struct dictType {
    unsigned int (*hashFunction)(const void *key); //hash函数指针
    void *(*keyDup)(void *privdata, const void *key); //键复制函数指针
    void *(*valDup)(void *privdata, const void *obj); //值复制函数指针
    int (*keyCompare)(void *privdata, const void *key1, const void *key2); //键比较函数指针
    void (*keyDestructor)(void *privdata, void *key); //键构造函数指针
    void (*valDestructor)(void *privdata, void *obj); //值构造函数指针
} dictType;  

/* This is our hash table structure. Every dictionary has two of this as we
 * implement incremental rehashing, for the old to the new table. */
typedef struct dictht { //字典hash table
    dictEntry **table;//可以看做字典数组,俗称桶bucket
    unsigned long size; //指针数组的大小,即桶的层数
    unsigned long sizemask;
    unsigned long used; //字典中当前的节点数目
} dictht;  

typedef struct dict {
    dictType *type;
    void *privdata; //私有数据
    dictht ht[2];   //两个hash table
    int rehashidx; /* rehashing not in progress if rehashidx == -1 */ //rehash 索引
    int iterators; /* number of iterators currently running */ //当前该字典迭代器个数
} dict;   

由于楼主算法能力有限:所以对哈希算法没有太深的了解,所以在这里算法就不详写了,大家有兴趣可以百度。

当运用哈希算法计算出 k0的索引 ,redis就会插入到指定的位置

当k2和k1出现计算出键索引相同的情况下,这时候redis的dictEntry(字典节点)有一个next属性(单项链表),redis会把冲突键索引的元素排到后插入数据的前面,从而解决了这个问题

现在如果在插入2条元素,此时数据量已经超过dict的负载了,redis就会启用rehash,虽然是rehash操作但是redis是采用了渐进式操作,并不是一下子内存不够用了 就直接操作内存,然后全部转移数据,这样会导致操作很耗时,redis考虑到了这一点,然后

先把ht[1]另一张dict结构中扩容一个数量为ht[0].used*2的dictEntry数组,然后把2条数据通过哈希算法加入到这个数组中。

然后把上面的元素一个个异步渐渐移动到下面的数组中,在这个过程中如果客户端去操作元素时,如果在ht[0]中检查找不到建,就会去检查ht[1]中是否有指定的键,从而不影响数据的使用,而且可以避免一次性操作rehash带来的耗时问题,最后reshash完成了,就直接把ht[1]和ht[0]切换位置并且清空弃用的哈希节点数组,从而完成所有操作。

时间: 2024-12-19 08:09:39

redis数据结构存储Dict设计细节(redis的设计与实现笔记)的相关文章

Redis 数据结构之dict(2)

本文及后续文章,Redis版本均是v3.2.8 上篇文章<Redis 数据结构之dict>,我们对dict的结构有了大致的印象.此篇文章对dict是如何维护数据结构的做个详细的理解. 老规矩还是打开Redis的源码,文件dict.c 一.dict数据结构的维护 1.dictCreate - 创建一个新的哈希表 /* Reset a hash table already initialized with ht_init(). * NOTE: This function should only b

redis数据结构存储Linked List设计细节(redis的设计与实现笔记)

redis里拥有一个灵活扩展且获取表头表尾复杂度为O(1)的双端列表,分为list和listNode2部分组成. list: 1 typedef struct list {//链表 2 listNode *head;//链表头 3 listNode *tail;//链表尾 4 void *(*dup)(void *ptr); //复制函数指针 5 void (*free)(void *ptr); //释放内存函数指针 6 int (*match)(void *ptr, void *key); /

redis学习(二) redis数据结构介绍以及常用命令

redis数据结构介绍 我们已经知道redis是一个基于key-value数据存储的数据结构数据库,这里的key指的是string类型,而对应的value则可以是多样的数据结构.其中包括下面五种类型: 1.string 字符串 string字符串类型是redis最基础的数据存储类型.string是最基础的一种数据类型,其可以拓展为某种特定类型,例如普通文本,json字符串,二进制数据等等.就本质上来说,接下来要介绍的hash,list,set等其内部最基础的组成单位依然是string,只不过re

Ubuntu上使用Redis数据库存储SessionID并实现Session共享

p { margin-bottom: 0.1in; direction: ltr; color: #00000a; line-height: 120%; text-align: left; orphans: 2; widows: 2 } p.western { font-family: "Liberation Serif", serif; font-size: 12pt } p.cjk { font-family: "Noto Sans CJK SC Regular"

redis底层数据结构之dict 字典1

最近,我想通过redis的源码来学习redis.虽然平时工作中用得不多,不过对redis还是比较感兴趣的,毕竟它的性能是不错的.redis是一个 开源的项目,我们可以通过源代码去了解redis.我后面会通过自己的学习,写一些关于redis源码的帖子.帖子的主要内容是分析代码设计,而并不会对 源码进行详细解说.如果有不对的地方,请指正.源码是reids 3.0.3版本. dict 字典 一.数据结构 //字典条目 typedef struct dictEntry {     void *key;

架构设计:系统存储(16)——Redis事件订阅和持久化存储

接上文<架构设计:系统存储(15)--Redis基本概念和安装使用> 3-4.事件功能和配置项 Redis从2.X版本开始,就支持一种基于非持久化消息的.使用发布/订阅模式实现的事件通知机制.所谓基于非连接保持,是因为一旦消息订阅者由于各种异常情况而被迫断开连接,在其重新连接后,其离线期间的事件是无法被重新通知的(一些Redis资料中也称为即发即弃).而其使用的发布/订阅模式,意味着其机制并不是由订阅者周期性的从Redis服务拉取事件通知,而是由Redis服务主动推送事件通知到符合条件的若干订

架构设计:系统存储(18)——Redis集群方案:高性能

1.概述 通过上一篇文章(<架构设计:系统存储(17)--Redis集群方案:高可用>)的内容,Redis主从复制的基本功能和进行Redis高可用集群监控的Sentinel基本功能基本呈现给了读者.虽然本人并不清楚上一篇根据笔者实际工作经验所撰写的文章有什么重大问题,导致那么多朋友集体点踩而且截止目前又没有任何人愿意为笔者指出这些问题,但是这不会影响笔者继续学习.总结技术知识的热情.从这篇文章开始我们一起来讨论Redis中两种高性能集群方案,并且在讨论过程中将上一篇文章介绍的高可用集群方案结合

架构设计:系统存储(17)——Redis集群方案:高可用

1.概述 从本篇文章开始,我们将向读者介绍几种Redis的高可用高负载集群方案.除了介绍Redis 3.X版本中推荐的原生集群方案外,还会介绍使用第三方组件搭建Redis集群的方法.本文我们会首先介绍Redis的高可用集群方案. 2.Redis高可用方案 Redis提供的高可用方案和我们介绍过的很多软件的高可用方案类似,都是使用主从节点的思路.即是有一个Master节点在平时提供服务,另外一个或多个Slave节点在平时不提供服务(或只提供数据读取服务).当Master节点由于某些原因停止服务后,

Redis的字典(dict)rehash过程源代码解析

Redis的内存存储结构是个大的字典存储,也就是我们通常说的哈希表.Redis小到能够存储几万记录的CACHE,大到能够存储几千万甚至上亿的记录(看内存而定),这充分说明Redis作为缓冲的强大.Redis的核心数据结构就是字典(dict),dict在数据量不断增大的过程中.会遇到HASH(key)碰撞的问题,假设DICT不够大,碰撞的概率增大,这样单个hash 桶存储的元素会越来愈多,查询效率就会变慢.假设数据量从几千万变成几万,不断减小的过程.DICT内存却会造成不必要的浪费.Redis的d