【Redis源码分析】一个对SDSHDR5是否使用的疑问

【Redis源码分析】一个对SDSHDR5是否使用的疑问

熊浩含

问题提出

  • 1、在Redis源码中有一句注释,是对sdshdr5的解释:
/* Note: sdshdr5 is never used, we just access the flags byte directly.
 * However is here to document the layout of type 5 SDS strings. */
struct __attribute__ ((__packed__)) sdshdr5 {
    unsigned char flags; /* 3 lsb of type, and 5 msb of string length */
    char buf[];
};

那么sdshdr5真的不使用了吗

  • 2、在Redis5中,执行以下命令,key和value最终是用哪种sds存放?

比如:

> set a ttt

sds基础回顾

从Redis3.2开始,sds就有了5种类型,5种类型分别存放不同大小的字符串。在创建字符串时,sds会根据字符串的长度选择不同的类型。最终由sdsnewlen函数创建字符串:

sds sdsnewlen(const void *init, size_t initlen) {
    void *sh;
    sds s;
    char type = sdsReqType(initlen);
    if (type == SDS_TYPE_5 && initlen == 0) type = SDS_TYPE_8;//为空时强制用sdshdr8
    int hdrlen = sdsHdrSize(type);
    unsigned char *fp; /* flags pointer. */

    sh = s_malloc(hdrlen+initlen+1);
    if (init==SDS_NOINIT)
        init = NULL;
    else if (!init)
        memset(sh, 0, hdrlen+initlen+1);
    if (sh == NULL) return NULL;
    s = (char*)sh+hdrlen;
    fp = ((unsigned char*)s)-1;
    switch(type) {
        case SDS_TYPE_5: {
            *fp = type | (initlen << SDS_TYPE_BITS);
            break;
        }
        case SDS_TYPE_8: {
            SDS_HDR_VAR(8,s);
            sh->len = initlen;
            sh->alloc = initlen;
            *fp = type;
            break;
        }
        case SDS_TYPE_16: {
            ...
        }
        case SDS_TYPE_32: {
            ...
        }
        case SDS_TYPE_64: {
            ...
        }
    }
    if (initlen && init)
        memcpy(s, init, initlen);
    s[initlen] = '
sds sdsnewlen(const void *init, size_t initlen) {
void *sh;
sds s;
char type = sdsReqType(initlen);
if (type == SDS_TYPE_5 && initlen == 0) type = SDS_TYPE_8;//为空时强制用sdshdr8
int hdrlen = sdsHdrSize(type);
unsigned char *fp; /* flags pointer. */
sh = s_malloc(hdrlen+initlen+1);
if (init==SDS_NOINIT)
init = NULL;
else if (!init)
memset(sh, 0, hdrlen+initlen+1);
if (sh == NULL) return NULL;
s = (char*)sh+hdrlen;
fp = ((unsigned char*)s)-1;
switch(type) {
case SDS_TYPE_5: {
*fp = type | (initlen << SDS_TYPE_BITS);
break;
}
case SDS_TYPE_8: {
SDS_HDR_VAR(8,s);
sh->len = initlen;
sh->alloc = initlen;
*fp = type;
break;
}
case SDS_TYPE_16: {
...
}
case SDS_TYPE_32: {
...
}
case SDS_TYPE_64: {
...
}
}
if (initlen && init)
memcpy(s, init, initlen);
s[initlen] = '\0';
return s;
}
'; return s; }

除了创建空字符串时会强转为SDS_TYPE_8外,没有什么其它特别之处了。

gdb结果

问题中的key和value都是长度短于32的字符串,似乎应该都用sdshdr5来存。但gdb打印后发现,key确实是用sdshdr5存储的,但value却是用sdshdr8存储的。
在getCommand函数处打断点,打印c-db->dict中的相关内容:

【Redis源码分析】一个对SDSHDR5是否使用的疑问

分别打印key和val的值,其中key是sds,val是robj。结果如下:

(gdb) p    (sds)0x7f09d2009830
$117 = 0x7f09d2009830 "\ba"
(gdb) p *(robj*)0x7f09d2029830
$118 = {type = 0, encoding = 8,    lru = 1536715, refcount = 1, ptr = 0x7f09d2029843}
(gdb) p    (sds)0x7f09d2029842
$119 = 0x7f09d2029842 "
(gdb) p    (sds)0x7f09d2009830
$117 = 0x7f09d2009830 "\ba"
(gdb) p *(robj*)0x7f09d2029830
$118 = {type = 0, encoding = 8,    lru = 1536715, refcount = 1, ptr = 0x7f09d2029843}
(gdb) p    (sds)0x7f09d2029842
$119 = 0x7f09d2029842 "\001ttt"
1ttt"
  • ttt前的001,代表flags是00000001(二进制),低三位表类型,意味着存ttt所用的类型为SDS_TYPE_8
  • a前的b,代表flags是00001000(二进制),低三位表类型,意味着存a所用类型为SDS_TYPE_5
#define SDS_TYPE_5  0
#define SDS_TYPE_8  1
#define SDS_TYPE_16 2
#define SDS_TYPE_32 3
#define SDS_TYPE_64 4

set命令流程

光看sdsnewlen无法解释问题,执行

>set a ttt

入口函数是setcommand,我们从setcommand命令入口看起:

void setCommand(client *c) {
    ...
    c->argv[2] = tryObjectEncoding(c->argv[2]);
    setGenericCommand(c,flags,c->argv[1],c->argv[2],expire,unit,NULL,NULL);
}

最终调setGenericCommand,c->argv[1],c->argv[2]是两个robj,存放着key和value,打印结果如下:

(gdb) p (sds)((*c->argv[1])->ptr-1)
$125 = 0x7f09d2029aca "
(gdb) p (sds)((*c->argv[1])->ptr-1)
$125 = 0x7f09d2029aca "\001a"
(gdb) p (sds)((*c->argv[2])->ptr-1)
$126 = 0x7f09d202988a "\001ttt"
1a" (gdb) p (sds)((*c->argv[2])->ptr-1) $126 = 0x7f09d202988a "
(gdb) p (sds)((*c->argv[1])->ptr-1)
$125 = 0x7f09d2029aca "\001a"
(gdb) p (sds)((*c->argv[2])->ptr-1)
$126 = 0x7f09d202988a "\001ttt"
1ttt"

可以看到,__两个robj底层的sds_type都是sdshdr8__。为什么是两个sdshdr8呢?argv应该是在命令解析的时候生成的,继续跟源码。命令解析的源头在readQueryFromClient,从readQueryFromClient一直往下跟,调用链如下:

【Redis源码分析】一个对SDSHDR5是否使用的疑问

最终走到了createStringObject:

robj *createStringObject(const char *ptr, size_t len) {
    if (len <= OBJ_ENCODING_EMBSTR_SIZE_LIMIT)//OBJ_ENCODING_EMBSTR_SIZE_LIMIT = 44
        return createEmbeddedStringObject(ptr,len);
    else
        return createRawStringObject(ptr,len);
}

redis在存储命令参数时,根据参数长度选不同的结构。有意思的是,参数长度小于44时,走createEmbeddedStringObject分支,但createEmbeddedStringObject中又强制用sdshdr8来存字符串:

robj *createEmbeddedStringObject(const char *ptr, size_t len) {
    robj *o = zmalloc(sizeof(robj)+sizeof(struct sdshdr8)+len+1);//指定sdshdr8
    ...
    return o;
}

而当参数长度大于44时,走一般流程。此时创建的字符串长度既然大于44,更大于32了,自然也不可能用sdshdr5。换而言之,__从Buffer中解析出的命令参数,redis统一用大于sdshdr5的结构存,这跟之前gdb的现象是一致的__。
那什么时候key变回由sdshdr5存储了呢?回过头继续跟setGenericCommand,调用链如下:

setGenericCommand-->setKey-->dbAdd

在dbAdd函数中,可以看到,redis对待存入的key做了一次复制,__正是这次复制将key由之前的sdshdr8转成了sdshdr5__:

void dbAdd(redisDb *db, robj *key, robj *val) {
    sds copy = sdsdup(key->ptr);
    int retval = dictAdd(db->dict, copy, val);
    ...
}

sdsdup复制只看字符串内容,根据字符串内容创建新的sds,由于key->ptr指向的字符串是”a”,故copy这个robj底层是个sdshdr5。最终调用dictAdd时,键的robj底层是sdshdr5,而值的robj底层是sdshdr8。

总结

最终可以确认,长度小于32的键值对,键的底层是sdshdr5,而值的robj底层是sdshdr8。

  • Q1:为什么用sdshdr5存key可以,存value不行?

    个人猜想是键不更新而值会更新,故键用尽可能小的结构存;值更新会引起扩容,索性直接用大些的结构存。

  • Q2:为什么解析参数时,Redis又抛弃了小的sdshdr5?

    个人猜想是为了编码方便。不同命令的参数个数都不相同,一开始分不清哪个位置是key哪个位置是value,索性统一处理,在具体场景下,再单独优化。

  • Q3:源码里面的注释是不是错了呢?

    笔者给Redis作者发了一封邮件去确认下,还未收到回信。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/101248.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)
blank

相关推荐

  • 数据结构之循环队列

    数据结构之循环队列数据结构之循环队列前言:关于循环队列需明白以下几点:1、循环队列是队列的顺序存储结构2、循环队列用判断是否为空利用Q.front=Q.rear3、循环队列头指针始终指向队列头元素,而尾指针始终指向队列尾元素的下一个位置4、按照队列的定义,队头删除,队尾插入,在这里插入图片描述会导致队头之前可能有空余的内存空间(如下图J1,J2出队后,空间被浪费),为了解决该问题,提出循环队列的解决方…

  • 字符串常量池理解「建议收藏」

    字符串常量池理解「建议收藏」在JVM中,为了减少字符串对象的重复创建,维护了一块特殊的内存空间,这块内存就被称为字符串常量池。在JDK1.6及之前,字符串常量池存放在方法区中。到JDK1.7之后,就从方法区中移除了,而存放在堆中。以下是《深入理解Java虚拟机》第二版原文:对于HotSpot虚拟机,根据官方发布的路线图信息,现在也有放弃永久代并逐步改为采用NativeMemory来实现方法区的规划了,在目前已经发布的…

  • JAVA的使用_Java集成开发环境

    JAVA的使用_Java集成开发环境IDE是集成开发环境:IntegratedDevelopmentEnvironment的缩写。使用IDE的好处在于按,可以把编写代码、组织项目、编译、运行、调试等放到一个环境中运行,能极大地提高

  • ViewStub的使用

    ViewStub的使用ViewStub经常用在ListView中,用来隐藏一些操作,使用起来也很简单,主要就是在ListView的Item中通过一个ViewStub来引用被隐藏的布局文件。监听用户点击Item,判断下当前是可见还是不可见,实时进行状态的转换即可。效果图如下:   下面看代码:MainActivity.java:设置数据源 publicclassMainActiv…

  • “大数据管理局”让大数据共用共享

    “大数据管理局”让大数据共用共享近日,广州市政府官方网站公布了工信委、商务委和国资委3个部门的“三定方案”。三个部门共“定编”339名,其中商务委编制最多,占比超4成。机构设置方面,工信委下设的广州市大数据管理局(正处级)颇具创新,其承载着建设工业大数据库等9项重要职责。城市发展到了今天这么大的体量,社会治理模式也需要不断升级。大数据,无疑是一个重要的发展方向。随着网络的普及…

  • 人际关系处理技巧

    人际关系处理技巧

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号