AIOps 一场颠覆传统运维的盛筵
678
2022-10-14
Redis开发与运维:SDS
STRING
我们会经常打交道的string类型,在redis中拥有广泛的使用。也是开启redis数据类型的基础。
在我最最开始接触的redis的时候,总是以为字符串类型就是值的类型是字符串。
比如:SET key value
我的理解是value数据类型是stirng类型,现在来看呢,这句话说得不够具体全面。
所有的键都是字符串类型字符串类型的值可以是字符串、数字、二进制
这里也就引出了,另一个概念:外部类型和内部类型
外部类型 vs 内部类型
这里的外部类型,就是我们所熟知的:字符串(string)、哈希(hash)、列表(list)、集合(set)、有序结合(zset)等
Q1:那么什么是内部类型呢?
Q2:外部类型和内部类型是什么时候出现的?
Q3:为什么要这样设计?
我们先来看问题1,可以这样理解,对外数据结构就像是我们的API,对外提供着一定组织结构的数据。
对内来说,我们可以更换里面的逻辑算法,甚至更换数据存储方式,比如将Mysql换成Redis.
内部类型其实就是数据存储的形式。举现在我们所讨论的stirng来说。
string的外部类型就是string,而它对应的数据内部存储结构分为三种。
int:8个字节的长整形embstr:<=39个字节的字符串(3.2 版本变成了44)raw:>39个字节的字符串(3.2 版本变成了44)
所以,string类型会根据当前字符串的长度来决定到底使用哪种内部数据结构。
现在我们再回到问题上:什么是内部类型?
就是数据真正存储在内存上的数据结构。
其实第二个问题:外部类型和内部类型是什么时候出现的?
这里也算是有答案了,外部类型就是对外公开的数据类型也可以说是API,内部类型根据长度判断哪种内部结构。
第三个问题:为什么这样设计?
前后分离,如果有更好地内部数据类型,我们可以替换后面的数据类型,但不影响前面的Api.还有一点也是根据不同情况,选择更好地数据结构,节省内存。毕竟是内存数据库,资源珍贵。
如何查看外部类型和内部类型
查看外部类型:type
127.0.0.1:6999[1]> SET sc sunchong // 对外类型:stringOK127.0.0.1:6999[1]> type scstring
127.0.0.1:6999[1]> HSET hsc sun chong // 对外类型:hash(integer) 1127.0.0.1:6999[1]> type hschash
127.0.0.1:6999> RPUSH rsc s un ch hong(integer) 4127.0.0.1:6999> TYPE rsclist
查看内部类型:object
int
127.0.0.1:6999[1]> set sc 1234567890123456789 // 对内类型:intOK127.0.0.1:6999[1]> STRLEN sc(integer) 19127.0.0.1:6999[1]> OBJECT encoding sc"int"
int -> embstr
(int 8位的长整形,最大存储十进制位数为19位)
127.0.0.1:6999[1]> set sc 12345678901234567890 // 对内类型:embstrOK127.0.0.1:6999[1]> STRLEN sc(integer) 20127.0.0.1:6999[1]> OBJECT encoding sc "embstr"
embstr -> raw
127.0.0.1:6999[1]> set sc 123456789012345678901234567890123456789 OK127.0.0.1:6999[1]> STRLEN sc(integer) 39127.0.0.1:6999[1]> OBJECT encoding sc"embstr"
127.0.0.1:6999[1]> set sc 12345678901234567890123456789012345678901 OK127.0.0.1:6999[1]> STRLEN sc(integer) 41127.0.0.1:6999[1]> OBJECT encoding sc"embstr"
额,这里我看《Redis 开发与运维》一书
39字节,embstr 转raw。写错了?
我的本机redis版本是5.0+,这本书是3.0,中间肯定是有了版本更新。
继续尝试 embstr -> raw
127.0.0.1:6999[1]> set sc 12345678901234567890123456789012345678901234OK127.0.0.1:6999[1]> STRLEN sc(integer) 44127.0.0.1:6999[1]> OBJECT encoding sc"embstr"
127.0.0.1:6999[1]> set sc 123456789012345678901234567890123456789012345 // 对内类型:rawOK127.0.0.1:6999[1]> STRLEN sc(integer) 45127.0.0.1:6999[1]> OBJECT encoding sc"raw"
常用命令
set key value [EX seconds] [PX milliseconds] [NX|XX]
-- ex 秒级过期时间
-- px 毫秒级过期时间
-- nx 不存在才能执行成功,类似添加
-- xx 必须存在才能执行成功,类似修改
nx
127.0.0.1:6999[1]> EXISTS bus(integer) 0127.0.0.1:6999[1]> SET bus Q xx(nil)127.0.0.1:6999[1]> SET bus Q nxOK
xx
127.0.0.1:6999[1]> EXISTS car(integer) 0127.0.0.1:6999[1]> SET car BOK127.0.0.1:6999[1]> SET car C nx(nil)127.0.0.1:6999[1]> SET car C xxOK127.0.0.1:6999[1]> GET car"C"
setnx / setxx
这两个命令会逐步弃用
String类型源码分析
SDS 数据结构
为什么Redis要自己实现一套简单的动态字符串?
1. 效率2. 安全(二进制安全:C语言中的字符串已 “\0” 为结束标志。)3. 扩容
如果说,有一辆车,到站前提前告知车站乘客,本次列车还有多少余座。
此时,如果有个计数器可以计算一下当前坐了多少乘客,同时还有多少空位就好了。
这样司机师傅就不必每次停车上客前,数数还有多少座位可以坐。可以专心开车。
同样,Redis SDS 也使用了这样一些小小的记录,
使用时候获取这个记录,时间复杂度是O(1),效率是很高的。不用每次都去统计。
redis做了这样的设计:
struct sdshdr { unsigned int len; unsigned int free; char buf[];};
len 已用字节数free 未用字节数buf[] 字符数组
这样设计有什么好处?1. 方便统计当前长度等,时间复杂度是O(1)2. 有了长度这些关键属性,可以不依赖“\0” 终止符。二进制安全。3. 指针返回的是buf[],这样可以复用C字符串相关的函数。避免重复造轮子,兼容C字符串操作4. 前面的len和free以及数组指针buf,内存分配上地址是连续的。所以很容易使用buf地址找到len和free.
我们先来看看,这个数据结构:
问题来了,是否还有优化的空间呢?
这样问比较笼统。我们思考一种场景:是不是所有的字符串存储都需要这样的结构?
到这里,有经验的你已经想到,所有的情况用没问题,但是Redis是内存数据库,
内存是资源,如何在资源上斤斤计较是Redis必须权衡的问题。
现在我们坐下来仔细分析一下:
unsigned int len 可以存的数据范围是:0 ~ 4294967295 (4 Bytes)
Redis中的字符串长度往往不需要这么大,多大合适呢?
1字节(Byte)? 这样?
struct sdshdr { char len; char free; char buf[];};
呀, 1字节是0~255,一般长度的字符串足够用。
如果真的存储了1个字节的字符串,len和free加起来也占了两个字节。
本来数据就1字节大,我为了存数据,额外信息都占2字节。
再优化,只能使用位来存储长度
假设,我们从全局来看,将字符串长度(小于1KB,1KB,2KB,4KB,8KB)来表示。
对于1字节,至少要拿出3个位,才能覆盖这5种情况( 2^3=8),那么剩下的5位才能存储长度。
现在我们已经进入到了Redis5.0 数据结构时代:
struct __attribute__ ((__packed__)) sdshdr5 { unsigned char flags; /* 3 lsb of type, and 5 msb of string length */ char buf[];};
3个低位标识类型,5个高位存长度(2^5=32)
说到这,长度大于31('\0'结束符)的字符串,1个字节是存不下的。
我们还是按照之前的逻辑 len和free再结合刚才的按位看长度类型,来看看大于1字节的数据结构:
struct __attribute__ ((__packed__)) sdshdr8 { uint8_t len; /* used */ uint8_t alloc; /* excluding the header and null terminator */ unsigned char flags; /* 3 lsb of type, 5 unused bits */ char buf[];};
使用了多少(len)、分配了多大(alloc)、长度类型标识(flags) ---- 这些表头= 1字节+1字节+1字节 ,共3字节
所以Redis对:字符串大小的界限就有了对应的宏定义
#define SDS_TYPE_5 0 // 小于1KB#define SDS_TYPE_8 1 #define SDS_TYPE_16 2 #define SDS_TYPE_32 3 #define SDS_TYPE_64 4
对应的数据结构就是:
struct __attribute__ ((__packed__)) sdshdr5 { unsigned char flags; /* 3 lsb of type, and 5 msb of string length */ char buf[];};struct __attribute__ ((__packed__)) sdshdr8 { uint8_t len; /* used */ uint8_t alloc; /* excluding the header and null terminator */ unsigned char flags; /* 3 lsb of type, 5 unused bits */ char buf[];};struct __attribute__ ((__packed__)) sdshdr16 { uint16_t len; /* used */ uint16_t alloc; /* excluding the header and null terminator */ unsigned char flags; /* 3 lsb of type, 5 unused bits */ char buf[];};struct __attribute__ ((__packed__)) sdshdr32 { uint32_t len; /* used */ uint32_t alloc; /* excluding the header and null terminator */ unsigned char flags; /* 3 lsb of type, 5 unused bits */ char buf[];};struct __attribute__ ((__packed__)) sdshdr64 { uint64_t len; /* used */ uint64_t alloc; /* excluding the header and null terminator */ unsigned char flags; /* 3 lsb of type, 5 unused bits */ char buf[];};
创建字符串
sds sdsnewlen(const void *init, size_t initlen);
看看注释,非常明白:
/* Create a new sds string with the content specified by the 'init' pointer * and 'initlen'. * If NULL is used for 'init' the string is initialized with zero bytes. * If SDS_NOINIT is used, the buffer is left uninitialized; * * The string is always null-termined (all the sds strings are, always) so * even if you create an sds string with: * * mystring = sdsnewlen("abc",3); * * You can print the string with printf() as there is an implicit \0 at the * end of the string. However the string is binary safe and can contain * \0 characters in the middle, as the length is stored in the sds header. */
获取SDS类型
char type = sdsReqType(initlen);
SDS_TYPE_5 一般用于字符串追加,所以还是用8这个。
if (type == SDS_TYPE_5 && initlen == 0) type = SDS_TYPE_8;
获取头长度
int hdrlen = sdsHdrSize(type);
申请内存(头+数据体+终止符)
sh = s_malloc(hdrlen+initlen+1);
s=数据体buf[]指针
s = (char*)sh+hdrlen;
buf[]指针-1,就找到了长度类型flag
fp = ((unsigned char*)s)-1;
最后缀上结束符,然后返回的是buf[]指针,兼容C语言字符串
s[initlen] = '\0'; return s;
追加字符串
sds sdscatlen(sds s, const void *t, size_t len) { size_t curlen = sdslen(s); // 原字符串长度 s = sdsMakeRoomFor(s,len); // 调整空间 if (s == NULL) return NULL; // 内存不足 memcpy(s+curlen, t, len); // 追加 sdssetlen(s, curlen+len); // 设置新的长度 s[curlen+len] = '\0'; // 结束标志,兼容C字符串 return s; }
释放字符串
void sdsfree(sds s)
直接释放内存
if (s == NULL) return; s_free((char*)s-sdsHdrSize(s[-1]));}
为了避免频繁申请关释放内存, 把使用量len重置为0,同时清空数据
void sdsclear(sds s) { sdssetlen(s, 0); s[0] = '\0';}
好处数据可以复用,避免重新申请内存
应用场景
用户信息
最近用户中心的访问压力极大,数据库已经扛不住。
我们使用比家里快而且成熟的技术,就是再加一层缓存。
比如:
uid:ui01
username: sunchong
nickname:二中
roletype:01
level:0
需求是:用户中心的用户数据,可以用uid拿到,也可以根据username拿到(uid和username 都是唯一不重复的)
我根据uid可以获取查询到用户,也可以根据username获取到用户。
首先,使用哈希进行数据的缓存 — HSET user:ui01 key1 value1 key2 value2 key3 value3 ...
127.0.0.1:6999> HSET user:ui01 username sunchong nickname 二中 roletype 01 level 0(integer) 4127.0.0.1:6999> HKEYS user:ui011) "username"2) "nickname"3) "roletype"4) "level"
然后创建映射关系:
127.0.0.1:6999> SET user:sunchong ui01OK127.0.0.1:6999> GET user:sunchong"ui01"
通过 username 找到主键uid,然后根据主键获取用户信息。
数据量较多时,过期时间设置为一定区间内的随机数。避免缓存穿透。
接口请求次数
当前我们有对用户开放的API,用户充值后使用,使用次数累加,剩余次数递减。
127.0.0.1:6999> SET user-ui01:times 1000OK127.0.0.1:6999> INCR user-ui01:times(integer) 1001127.0.0.1:6999> GET user-ui01:times"1001"127.0.0.1:6999> DECR user-ui01:times(integer) 1000
短信验证码
就在前几天,我们刚刚对接了阿里云短信码服务。
起初,我自己认为短信验证码为了实时性不需要进行实际的缓存处理。
但是完全可以根据实际情况进行设计魂村策略。
为了防止接口的频繁调用,我们可以像网关一样进行设置。
现在就有这样一个需求:1个手机号,1分钟最多获取10次验证码
SET Catch:Limit:13355222226 1 ex 60 nx
初始化手机号,起始次数是1,默认过期时间60秒
再剩下的就是代码判断次数即可。
string redisConn = "127.0.0.1:6378,defaultDatabase=0,prefix="; using (var redis = new CSRedis.CSRedisClient(redisConn)) { string key = "Catch:13355222222"; bool inserted = redis.SetAsync(key, 1, 60, CSRedis.RedisExistence.Nx).Result; if (inserted || redis.IncrByAsync(key).Result <= 10) { // 新增或未达上限--发送验证码 } else { // 受限 } }
总结
字符串类型结合命令有很多的应用场景,这个有待去收集和发现。
Redis 比较容易上手,文档全,代码整洁高效。
当然更需要我们去深入其运行原理,来更好使用这个工具来服务我们的业务。
发表评论
暂时没有评论,来抢沙发吧~