Redis从精通到入门——数据类型Hash实现源码详解

Redis从精通到入门——数据类型Hash实现源码详解

Redis数据类型之Hash详解

Hash简介

Hash的常用 *** 作应用场景 Hash实现

Hash—ziplist实现

图解Hash—ziplist实现 Hash—字典dict实现

源码阅读图解dict渐进式rehash

Hash简介

Redis hash 是一个 string 类型的 field（字段） 和 value（值） 的映射表，hash 特别适合用于存储对象。
Redis 中每个 hash 可以存储 232 - 1 键值对（40多亿）。

优点：

同类数据归类整合储存，方便数据管理相比使用多个string *** 作消耗内存与cpu更小相比使用多个string储存更节省空间相比使用单个String转JSON存储，支持局部值的更新、查询 缺点：

过期功能不能使用在field上，只能用在key上

当Hash数据大小和元素数量阈值都没有超过设置的值时，此时底层使用 ziplist 去实现，那么会有一个有意思的场景：此时的数据存储是有序的按照插入顺序排序，且对已存在的Key修改其Value也不会影响数据顺序。这一点和JAVA有着较大的差距大家需要注意。
想了解ziplist可查阅历史博客，传输门：Redis从精通到入门——数据类型List实现源码详解

Hash的常用 *** 作

HSET key field value [field value …]：将一个或多个field/value插入到哈希表中；HGET key field ：返回key中指定 field 的 value 值；HMGET key field [field …] ：批量返回key中指定field 的 value 值；HKEYS key ：返回哈希表 key 中的所有field；HGETALL key ：返回哈希表 key 中，所有的field和value；HVALS key ：返回哈希表 key 中的所有value；HEXISTS key field ：查看哈希表 key 中，field 是否存在；HDEL key field [field …] ：删除哈希表 key 中的一个或多个field ；HINCRBY key field increment ：为哈希表 key 中 field 的值加上增量 increment类似String的INCRBY，同时也支持传递负数。此命令在使用Rrdis Hash实现购物车的场景下非常好用；HLEN key ：返回哈希表 key 中field的数量；HSETNX key field value ：将哈希表 key 中的域 field 的值设置为 value 仅当 field 不存在时才会set成功； 应用场景

购物车对象信息缓存希望大家不要再去把对象转JSON当String存进去了 Hash实现

Hash 数据结构底层实现为一个字典( dict ),也是RedisDB用来存储K-V的数据结构,当数据量比较小，或者单个元素比较小时，底层用 ziplist 存储，数据大小和元素数量阈值可以通过如下参数设置：

hash-max-ziplist-entries 512：ziplist 元素个数超过 指定个数时默认512个，将由ziplist 改为 hashtable 编码 ；hash-max-ziplist-value 64： 当ziplist 中单个元素大小超过 指定字节数默认64byte，将由ziplist 改为 hashtable 编码 ； Hash—ziplist实现

当Hash 的底层实现是 ziplist 时， ziplist 中的 entry 的个数永远是双数，是以 key value key value … key value 形式存储。进行hget *** 作时则不需要进行 hashCode 的计算，通过直接遍历ziplist，比对key的值来获取value。

此处不再额外对ziplist源码进行阅读，如需了解请通过文章上部分传送门查看ziplist具体实现。

图解Hash—ziplist实现

Hash—字典dict实现

    dict (dictionary 字典)，通常的存储结构是Key-Value形式的，通过Hash函数对key求Hash值来确定Value的位置，因此也叫Hash表，是一种用来解决算法中查找问题的数据结构，默认的算法复杂度接近O(1)。
    字典在Redis中的作用是非常巨大的，对Redis数据库的增删改查等 *** 作都构建在对字典的 *** 作之上，因此，了解字典的底层实现能让我们对Redis有更深的理解。

其实哪怕我们常规的get、set 都是基于dict字典实现的，Hash这里只是复用了Redis的字典实现。

源码阅读

咱们主要关注的数据结构有如下三个：

dict：是Redis中的字典结构，包含两个dictht；dictht：表示一个Hash表，包含一个或多个dictEntry；dictEntry： 表示一个Key-Value节点；

typedef struct dict {
    dictType *type;			
    void *privdata;			
    dictht ht[2];			
    long rehashidx; 		
    unsigned long iterators; 
} dict;


typedef struct dictht {
    dictEntry **table;		
    unsigned long size; 	
    unsigned long sizemask;	
    unsigned long used;		
} dictht;


typedef struct dictEntry {
    void *key;
    union {
        void *val;		
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    struct dictEntry *next;	
} dictEntry;

图解dict

由于dict字典并非只在Redis 的 hash数据结构中使用，所以下面的图解会画的尽量详细些

渐进式rehash

Redis 的字典可以看做 JAVA的Map 为了避免链表过长都需要进行hashTable的扩容 *** 作，redis默认正常情况下扩容的负载因子 = 1。
负载因子 = used / size。每次扩容后hashTable的大小 = size * 2也就是成倍扩容。

Redis rehash流程如下：为ht[1]分配空间，此时字典同时持有ht[0]和ht[1]；将rehashidx设为0，表示rehash正式开始；在rehash期间，每次对字典执行任意 *** 作时，程序除了执行对应 *** 作之外，还会顺带将ht[0]在rehashidx索引上的所有键值对rehash到ht[1]， *** 作完后将rehashidx的值 + 1；Redis本身也会有事件轮询，哪怕没有命令访问，也会通过轮询事件逐渐完成数据迁移；当rehashidx的值增加到 = ht[0].size，此时ht[0]的所有键值对都已经迁移到ht[1]了。程序会把ht[1]设置为ht[0]，并重新在ht[1]上新建一个空表。将rehashidx重新置为-1，以此表示rehash完成。

Redis为什么需要渐进式rehash？

哪怕Redis 6.0支持的客户端 *** 作的多线程，但是真正去执行 *** 作的还是只有一个主线程，所以当存在超大的hashTable进行扩容时，如果不去渐进式扩容，单次扩容时间太长且扩容期间Redis服务不可用，将导致大量的线程等待。

你的点赞就是我创作的最大动力，如果写的不错，来个三连行不行