Redis源码分析(八)--- t_hash哈希转换

在上次的zipmap分析完之后,其实关于redis源代码结构体部分的内容其实已经全部结束了,因为下面还有几个和结构体相关的操作类,就页把他们归并到struct包下了。这类的文件有:t_hash.c,z_list,z_set.c,t_string.c,t_zset.c,这些文件的功能其实都差不多,就是用来实现Client和Server之间的命令处理的操作类,通过robj的形式,把dict,ziplist等存入robj中,进行各个转换,实现命令操作。避开了结构体原先的复杂结构,相当于是封装了结构体的操作类,今天我所讲的是t_hash,是dict哈希字典,ziplist压缩列表与robj之间的转换。统称hashType类型。由于此文件无头文件,只有.c文件,所以为了方便学习,我把方法拉了出来。

/* 下面是方法的归类 */
void hashTypeTryConversion(robj *o, robj **argv, int start, int end) /* 当hashType为ziplist时,判断对象长度是否超出了服务端可接受的ziplist最大长度,超过则转成哈希字典类型*/
void hashTypeTryObjectEncoding(robj *subject, robj **o1, robj **o2) /* 当robj用的是字典的编码方式的时候,则经过编码转换 */
int hashTypeGetFromZiplist(robj *o, robj *field,unsigned char **vstr,unsigned int *vlen,long long *vll) /* 获取ziplist压缩列表中的某个索引位置上的值 */
int hashTypeGetFromHashTable(robj *o, robj *field, robj **value) /* 获取哈希字典中的某个值 */
robj *hashTypeGetObject(robj *o, robj *field) /* 获取某个key对应的对象类型 */
int hashTypeExists(robj *o, robj *field)   /* hastType类型判断某个键是否存在 */
int hashTypeSet(robj *o, robj *field, robj *value) /* hashType设置操作,分2种情况,ziplist,和字典hashtable */
int hashTypeDelete(robj *o, robj *field)  /* hashType删除操作,分为ziplist的删除操作,和hashtable的删除操作 */
unsigned long hashTypeLength(robj *o)   /* hashType求长度操作 */
hashTypeIterator *hashTypeInitIterator(robj *subject)  /* 获取hashType迭代器 */
void hashTypeReleaseIterator(hashTypeIterator *hi) /* 释放hashType迭代器 */
int hashTypeNext(hashTypeIterator *hi) /* 通过hashType迭代器获取下一个元素 */
void hashTypeCurrentFromZiplist(hashTypeIterator *hi, int what,unsigned char **vstr,unsigned int *vlen,long long *vll) /* 根据当前迭代器的位置,获取当前ziplist的所在位置的key位置,或value该位置上的值 */
void hashTypeCurrentFromHashTable(hashTypeIterator *hi, int what, robj **dst) /* 根据当前迭代器的位置,获取当前dict的所在位置的key位置,或value该位置上的值 */
robj *hashTypeCurrentObject(hashTypeIterator *hi, int what) /* 根据当前迭代器的位置,获取当前key对象 */
robj *hashTypeLookupWriteOrCreate(redisClient *c, robj *key) /* 根据c客户端对象,找到key是否存在,创建或实现添加操作  */
void hashTypeConvertZiplist(robj *o, int enc) /* 从ziplist压缩表到hashtable的转换 */
void hashTypeConvert(robj *o, int enc) /* 对象转换操作,例如从ziplist到dict的转换 */

hashType的相关操作命令类,其实就是对上面方法的结合调用:

/* 哈希命令类型 */
void hsetCommand(redisClient *c)  /* 客户端设置指令 */
void hsetnxCommand(redisClient *c) /* 客户端设置下一个位置指令 */
void hmsetCommand(redisClient *c) /* 客户单设置命令,如果没有key,还有后续操作 */
void hincrbyCommand(redisClient *c) /* 客户端添加value值操作 */
void hincrbyfloatCommand(redisClient *c) /* 客户端添加float类型value值操作 */
static void addHashFieldToReply(redisClient *c, robj *o, robj *field) /*  */
void hgetCommand(redisClient *c) /* 客户端获取操作,如果没找到,直接不做任何操作 */
void hmgetCommand(redisClient *c) /* 客户端获取key操作,如果为空,会返回一些了NULL值 */
void hdelCommand(redisClient *c) /* 客户端删除操作 */
void hlenCommand(redisClient *c) /* 客户端求长度命令 */
static void addHashIteratorCursorToReply(redisClient *c, hashTypeIterator *hi, int what) /* 客户端添加hashType迭代器操作 */
void genericHgetallCommand(redisClient *c, int flags) /* 客户端获取操作原始方法,可以添加flag参数 */
void hkeysCommand(redisClient *c) /* 客户端获取key值命令 */
void hvalsCommand(redisClient *c) /* 客户端获取val值命令 */
void hgetallCommand(redisClient *c) /* 客户端获取key;value 2个值都获取 */
void hexistsCommand(redisClient *c) /* 客户端判断记录是否存在操作 */
void hscanCommand(redisClient *c) /* 客户端扫描操作 */

robj的操作实现转换的原理很简单,rob通过里面的ptr指针,存的就是真实的ziplist或者dict哈希总类,然后后面的操作都是基于此进行的,比如说下面的方法:

/* Get the value from a hash table encoded hash, identified by field.
 * Returns -1 when the field cannot be found. */
/* 获取哈希字典中的某个值 */
int hashTypeGetFromHashTable(robj *o, robj *field, robj **value) {
    dictEntry *de;

    redisAssert(o->encoding == REDIS_ENCODING_HT);

    //通过robj->ptr里面存的dict总类或ziplist类开始寻找
    de = dictFind(o->ptr, field);
    if (de == NULL) return -1;
    //获取其中的value值
    *value = dictGetVal(de);
    return 0;
}

所有关于robj的相关结构体操作都会分成为2种情况处理,ZIPLIST和HASH类型就是dict类型,而且操作ziplist类型的时候要进行转码处理,当然在进行ziplist存入robj的时候要进行编码操作,可见,设计者在考虑到命令传输的时候想得还是很周到了,也考虑了安全的问题。

/* Add an element, discard the old if the key already exists.
 * Return 0 on insert and 1 on update.
 * This function will take care of incrementing the reference count of the
 * retained fields and value objects. */
/* hashType设置操作,分2种情况,ziplist,和字典hashtable */
int hashTypeSet(robj *o, robj *field, robj *value) {
    int update = 0;

    if (o->encoding == REDIS_ENCODING_ZIPLIST) {
        unsigned char *zl, *fptr, *vptr;

        //首先对field和value进行解码
        field = getDecodedObject(field);
        value = getDecodedObject(value);

        zl = o->ptr;
        fptr = ziplistIndex(zl, ZIPLIST_HEAD);
        if (fptr != NULL) {
            fptr = ziplistFind(fptr, field->ptr, sdslen(field->ptr), 1);
            if (fptr != NULL) {
                /* Grab pointer to the value (fptr points to the field) */
                vptr = ziplistNext(zl, fptr);
                redisAssert(vptr != NULL);
                update = 1;

                //设置的操作,其实先删除,再插入语一个新值
                /* Delete value */
                zl = ziplistDelete(zl, &vptr);

                /* Insert new value */
                zl = ziplistInsert(zl, vptr, value->ptr, sdslen(value->ptr));
            }
        }

        if (!update) {
            /* Push new field/value pair onto the tail of the ziplist */
            zl = ziplistPush(zl, field->ptr, sdslen(field->ptr), ZIPLIST_TAIL);
            zl = ziplistPush(zl, value->ptr, sdslen(value->ptr), ZIPLIST_TAIL);
        }
        o->ptr = zl;
        //用完之后,引用计数递减
        decrRefCount(field);
        decrRefCount(value);

        /* Check if the ziplist needs to be converted to a hash table */
        if (hashTypeLength(o) > server.hash_max_ziplist_entries)
            hashTypeConvert(o, REDIS_ENCODING_HT);
    } else if (o->encoding == REDIS_ENCODING_HT) {
    	//如果是字典,直接替换
        if (dictReplace(o->ptr, field, value)) { /* Insert */
            incrRefCount(field);
        } else { /* Update */
            update = 1;
        }
        //用完之后,引用计数递减
        incrRefCount(value);
    } else {
        redisPanic("Unknown hash encoding");
    }
    return update;
}

在这个过程中,redis代码中还用到了一个引用计数的东西,应该是为了合理的内存释放控制,在很多地方可以看到这样的操作;

/* Higher level function of hashTypeGet*() that always returns a Redis
 * object (either new or with refcount incremented), so that the caller
 * can retain a reference or call decrRefCount after the usage.
 *
 * The lower level function can prevent copy on write so it is
 * the preferred way of doing read operations. */
/* 获取某个key的对象 */
robj *hashTypeGetObject(robj *o, robj *field) {
    robj *value = NULL;

    if (o->encoding == REDIS_ENCODING_ZIPLIST) {
        unsigned char *vstr = NULL;
        unsigned int vlen = UINT_MAX;
        long long vll = LLONG_MAX;

        if (hashTypeGetFromZiplist(o, field, &vstr, &vlen, &vll) == 0) {
        	//在ziplist中获取值
            if (vstr) {
                value = createStringObject((char*)vstr, vlen);
            } else {
                value = createStringObjectFromLongLong(vll);
            }
        }

    } else if (o->encoding == REDIS_ENCODING_HT) {
        robj *aux;

        if (hashTypeGetFromHashTable(o, field, &aux) == 0) {
        	//对象被引用了,计数递增
            incrRefCount(aux);
            value = aux;
        }
    } else {
        redisPanic("Unknown hash encoding");
    }
    return value;
}

客户端的命令操作其实是基于一个叫redisClient的对象,这个其实也就是robj对象,命令传输时,这个robj->ptr存着,具体的数据,robj->args[]存放了各种参数,后面就是调用前面的方法了,唯一不一样的是,命令调用后要有回复和更新通知操作。,下面是一个设置的命令;

/* hashType处理客户端的命令请求 */
void hsetCommand(redisClient *c) {
    int update;
    robj *o;

    if ((o = hashTypeLookupWriteOrCreate(c,c->argv[1])) == NULL) return;
    hashTypeTryConversion(o,c->argv,2,3);
    hashTypeTryObjectEncoding(o,&c->argv[2], &c->argv[3]);
    //命令的操作都是通过,客户端中的对象,和存在于里面的命令参数组成
    update = hashTypeSet(o,c->argv[2],c->argv[3]);
    //操作完添加回复
    addReply(c, update ? shared.czero : shared.cone);
    //发送通知表示命令执行完毕,预测者会触发窗口上的显示
    signalModifiedKey(c->db,c->argv[1]);
    notifyKeyspaceEvent(REDIS_NOTIFY_HASH,"hset",c->argv[1],c->db->id);

    //客户端命令执行成功,因为客户单此时的数据时最新的,服务端的脏数据就自然多了一个,
    server.dirty++;
}

其他命令与此类似,就不说了。可以看见,现在慢慢的能够略微向逻辑层的代码靠近了,后面的代码也一定非常精彩。

时间: 2024-10-25 06:59:21

Redis源码分析(八)--- t_hash哈希转换的相关文章

redis源码分析3---结构体---字典

redis源码分析3---结构体---字典 字典,简单来说就是一种用于保存键值对的抽象数据结构: 注意,字典中每个键都是独一无二的:在redis中,内部的redis的数据库就是使用字典作为底层实现的: 1 字典的实现 在redis中,字典是使用哈希表作为底层实现的,一个hash表里面可以有多个hash表节点,而每个hash表节点就保存了字典中的一个键值对: hash表定义 table属性是一个数组,数组中的每个元素都是一个指向dictEntry结构的指针,每个dictEntry结构保存着一个键值

redis源码分析之内存布局

redis源码分析之内存布局 1. 介绍 众所周知,redis是一个开源.短小.高效的key-value存储系统,相对于memcached,redis能够支持更加丰富的数据结构,包括: 字符串(string) 哈希表(map) 列表(list) 集合(set) 有序集(zset) 主流的key-value存储系统,都是在系统内部维护一个hash表,因为对hash表的操作时间复杂度为O(1).如果数据增加以后,导致冲突严重,时间复杂度增加,则可以对hash表进行rehash,以此来保证操作的常量时

redis源码分析4---结构体---跳跃表

redis源码分析4---结构体---跳跃表 跳跃表是一种有序的数据结构,他通过在每个节点中维持多个指向其他节点的指针,从而达到快速访问节点的目的: 跳跃表支持平均O(logN),最坏O(N)复杂度的节点查找,还可以通过顺序性操作来批量处理节点.性能上和平衡树媲美,因为事先简单,常用来代替平衡树. 在redis中,只在两个地方使用了跳跃表,一个是实现有序集合键,另一个是在集群节点中用作内部数据结构. 1 跳跃表节点 1.1 层 层的数量越多,访问其他节点的速度越快: 1.2 前进指针 遍历举例

redis 源码分析(一) 内存管理

一,redis内存管理介绍 redis是一个基于内存的key-value的数据库,其内存管理是非常重要的,为了屏蔽不同平台之间的差异,以及统计内存占用量等,redis对内存分配函数进行了一层封装,程序中统一使用zmalloc,zfree一系列函数,其对应的源码在src/zmalloc.h和src/zmalloc.c两个文件中,源码点这里. 二,redis内存管理源码分析 redis封装是为了屏蔽底层平台的差异,同时方便自己实现相关的函数,我们可以通过src/zmalloc.h 文件中的相关宏定义

redis源码分析之事务Transaction(下)

接着上一篇,这篇文章分析一下redis事务操作中multi,exec,discard三个核心命令. 原文地址:http://www.jianshu.com/p/e22615586595 看本篇文章前需要先对上面文章有所了解: redis源码分析之事务Transaction(上) 一.redis事务核心命令简介 redis事务操作核心命令: //用于开启事务 {"multi",multiCommand,1,"sF",0,NULL,0,0,0,0,0}, //用来执行事

redis源码分析(1)--makefile和目录结构分析

一.redis源码编译 redis可以直接在官网下载(本文使用版本 3.0.7):https://redis.io/download 安装: $ tar xzf redis-3.0.7.tar.gz $ cd redis-3.0.7 $ make make执行以后主要编译产物在src/redis-server src/redis-cli 如果想把redis-server直接install到可执行目录/usr/local/bin,还需要执行: $ make install Run Redis wi

Redis源码分析(一)--Redis结构解析

从今天起,本人将会展开对Redis源码的学习,Redis的代码规模比较小,非常适合学习,是一份非常不错的学习资料,数了一下大概100个文件左右的样子,用的是C语言写的.希望最终能把他啃完吧,C语言好久不用,快忘光了.分析源码的第一步,先别急着想着从哪开始看起,先浏览一下源码结构,可以模块式的渐入,不过比较坑爹的是,Redis的源码全部放在在里面的src目录里,一下90多个文件统统在里面了,所以我选择了拆分,按功能拆分,有些文件你看名字就知道那是干什么的.我拆分好后的而结果如下: 11个包,这样每

redis源码分析之事务Transaction(上)

这周学习了一下redis事务功能的实现原理,本来是想用一篇文章进行总结的,写完以后发现这块内容比较多,而且多个命令之间又互相依赖,放在一篇文章里一方面篇幅会比较大,另一方面文章组织结构会比较乱,不容易阅读.因此把事务这个模块整理成上下两篇文章进行总结. 原文地址:http://www.jianshu.com/p/acb97d620ad7 这篇文章我们重点分析一下redis事务命令中的两个辅助命令:watch跟unwatch. 一.redis事务辅助命令简介 依然从server.c文件的命令表中找

Redis源码分析(四)-- sds字符串

今天分析的是Redis源码中的字符串操作类的代码实现.有了上几次的分析经验,渐渐觉得我得换一种分析的方法,如果每个API都进行代码分析,有些功能性的重复,导致分析效率的偏低.所以下面我觉得对于代码的分析偏重的是一种功能整体的思维实现来讲解,其中我也会挑出一个比较有特点的方法进行拆分了解,这也可以让我们见识一下里面的一些神奇的代码.好,回归正题,说到字符串,这不管放到哪个编程语言中,都是使用频率极高的操作类.什么new String, concat, strcopy,substr, splitSt

Redis源码分析(二十三)--- CRC循环冗余算法和RAND随机数算法

今天开始研究Redis源码中的一些工具类的代码实现,工具类在任何语言中,实现的算法原理应该都是一样的,所以可以借此机会学习一下一些比较经典的算法.比如说我今天看的Crc循环冗余校验算法和rand随机数产生算法. CRC算法全称循环冗余校验算法.CRC校验的基本思想是利用线性编码理论,在发送端根据要传送的k位二进制码序列,以一定的规则产生一个校验用的监督码(既CRC码)r位,并附在信息后边,构成一个新的二进制码序列数共(k+r)位,最后发送出去.在接收端, 则根据信息码和CRC码之间所遵循的规则进