1.redis在数据类型有哪些?跟其他nosql相比数据类型的特点是什么?
答:字符串,列表,哈希,集合,有序集合
Redis 和其他很多key-value 数据库的不同之处在于,Redis 不仅支持简单的字符串键值对,它
还提供了一系列数据结构类型值,比如列表、哈希、集合和有序集,并在这些数据结构类型上
定义了一套强大的API 。
通过对不同类型的值进行操作,Redis 可以很轻易地完成其他只支持字符串键值对的key-value数据库很难(或者无法)完成的任务。
在Redis 的内部,数据结构类型值由高效的数据结构和算法进行支持,并且在Redis 自身的构
建当中,也大量用到了这些数据结构。
Redis 性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
原子 – Redis的所有操作都是原子性的,同时Redis还支持对几个操作全并后的原子性执行。
丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。
Redis有着更为复杂的数据结构并且提供对他们的原子性操作,这是一个不同于其他数据库的进化路径。Redis的数据类型都是基于基本数据结构的同时对程序员透明,无需进行额外的抽象。
Redis运行在内存中但是可以持久化到磁盘,所以在对不同数据集进行高速读写时需要权衡内存,应为数据量不能大于硬件内存。在内存数据库方面的另一个优点是, 相比在磁盘上相同的复杂的数据结构,在内存中操作起来非常简单,这样Redis可以做很多内部复杂性很强的事情。 同时,在磁盘格式方面他们是紧凑的以追加的方式产生的,因为他们并不需要进行随机访问。
2.redis中的字符串数据结构是怎样的?为什么没有采用C的传统字符串,有什么优势?
Sds (Simple Dynamic String,简单动态字符串)是Redis 底层所使用的字符串表示,它被用在几乎所有的Redis 模块中,Redis 使用sds 而不是传统C 字符串是因为能带来性能上的优势。
Sds 在Redis 中的主要作用有以下两个:
1. 实现字符串对象(StringObject);
2. 在Redis 程序内部用作char* 类型的替代品;
Redis 是一个键值对数据库(key-value DB),数据库的值可以是字符串、集合、列表等多种类型的对象,而数据库的键则总是字符串对象。
对于那些包含字符串值的字符串对象来说,每个字符串对象都包含一个sds 值。
struct sdshdr {
// buf 已占用长度
int len;
// buf 剩余可用长度
int free;
// 实际保存字符串数据的地方
char buf[];
};
sds 代替C 默认的char* 类型
因为char* 类型的功能单一,抽象层次低,并且不能高效地支持一些Redis 常用的操作(比
如追加操作和长度计算操作),所以在Redis 程序内部,绝大部分情况下都会使用sds 而不是
char* 来表示字符串。
性能问题在稍后介绍sds 定义的时候就会说到,因为我们还没有了解过Redis 的其他功能模
块,所以也没办法详细地举例说那里用到了sds ,不过在后面的章节中,我们会经常看到其他
模块(几乎每一个)都用到了sds 类型值。
目前来说,只要记住这样一个事实即可:在Redis 中,客户端传入服务器的协议内容、aof 缓
存、返回给客户端的回复,等等,这些重要的内容都是由都是由sds 类型来保存的。
在C 语言中,字符串可以用一个0 结尾的char 数组来表示。
比如说,hello world 在C 语言中就可以表示为"hello world0" 。
这种简单的字符串表示在大多数情况下都能满足要求,但是,它并不能高效地支持长度计算和
追加(append)这两种操作:
• 每次计算字符串长度(strlen(s))的复杂度为(N) 。
• 对字符串进行N 次追加,必定需要对字符串进行N 次内存重分配(realloc)。
在Redis 内部,字符串的追加和长度计算并不少见,而APPEND 和STRLEN 更是这两种操
作在Redis 命令中的直接映射,这两个简单的操作不应该成为性能的瓶颈。
另外,Redis 除了处理C 字符串之外,还需要处理单纯的字节数组,以及服务器协议等内容,
所以为了方便起见,Redis 的字符串表示还应该是二进制安全的:程序不应对字符串里面保存
的数据做任何假设,数据可以是以0 结尾的C 字符串,也可以是单纯的字节数组,或者其他
格式的数据。
考虑到这两个原因,Redis 使用sds 类型替换了C 语言的默认字符串表示:
3.redis的字符串对象在保存long值的时候有什么不同?
Note: “包含字符串值的字符串对象” ,这种说法初听上去可能会有点奇怪,但是在Redis 中,
一个字符串对象除了可以保存字符串值之外,还可以保存long 类型的值,所以为了严谨起见,
这里需要强调一下:当字符串对象保存的是字符串时,它包含的才是sds 值,否则的话,它就
是一个long 类型的值。
解释如下:
字符串对象的编码可以是 int
、 raw
或者 embstr
。
如果一个字符串对象保存的是整数值, 并且这个整数值可以用 long
类型来表示, 那么字符串对象会将整数值保存在字符串对象结构的ptr
属性里面(将 void*
转换成 long
), 并将字符串对象的编码设置为 int
。
![a568cb1142a2414f4e0fab82cfa78d0f.png](https://i-blog.csdnimg.cn/blog_migrate/06054df69abfa0bdfd5a7dbc4665a455.jpeg)
如果字符串对象保存的是一个字符串值, 并且这个字符串值的长度大于39
字节, 那么字符串对象将使用一个简单动态字符串(SDS)来保存这个字符串值, 并将对象的编码设置为raw
。
![926f68ab0039fb0fd33b205ead3f5381.png](https://i-blog.csdnimg.cn/blog_migrate/9678a8c2a32c4e0406ca3b5c9c35d380.jpeg)
如果字符串对象保存的是一个字符串值, 并且这个字符串值的长度小于等于 39
字节, 那么字符串对象将使用 embstr
编码的方式来保存这个字符串值。
embstr
编码是专门用于保存短字符串的一种优化编码方式, 这种编码和 raw
编码一样, 都使用 redisObject
结构和 sdshdr
结构来表示字符串对象, 但 raw
编码会调用两次内存分配函数来分别创建 redisObject
结构和 sdshdr
结构, 而 embstr
编码则通过调用一次内存分配函数来分配一块连续的空间, 空间中依次包含 redisObject
和 sdshdr
两个结构:
![c288a604cf458d856522322b7cc7b39f.png](https://i-blog.csdnimg.cn/blog_migrate/f6206ae0e134387e0ba1411b05d7bbfa.jpeg)
最后要说的是, 可以用 long
double
类型表示的浮点数在 Redis 中也是作为字符串值来保存的: 如果我们要保存一个浮点数到字符串对象里面, 那么程序会先将这个浮点数转换成字符串值, 然后再保存转换所得的字符串值。
在有需要的时候, 程序会将保存在字符串对象里面的字符串值转换回浮点数值, 执行某些操作, 然后再将执行操作所得的浮点数值转换回字符串值, 并继续保存在字符串对象里面。
redis> SET pi 3.14
OK
redis> OBJECT ENCODING pi
"embstr"
redis> INCRBYFLOAT pi 2.0
"5.14"
redis> OBJECT ENCODING pi
"embstr"
编码的转换
int
编码的字符串对象和 embstr
编码的字符串对象在条件满足的情况下, 会被转换为 raw
编码的字符串对象。
对于 int
编码的字符串对象来说, 如果我们向对象执行了一些命令, 使得这个对象保存的不再是整数值, 而是一个字符串值, 那么字符串对象的编码将从 int
变为 raw
。
另外, 因为 Redis 没有为embstr
编码的字符串对象编写任何相应的修改程序 (只有int
编码的字符串对象和raw
编码的字符串对象有这些程序), 所以embstr
编码的字符串对象实际上是只读的: 当我们对embstr
编码的字符串对象执行任何修改命令时, 程序会先将对象的编码从embstr
转换成raw
, 然后再执行修改命令; 因为这个原因,embstr
编码的字符串对象在执行修改命令之后, 总会变成一个raw
编码的字符串对象。
摘录自
Airfreezing:redis:字符串对象zhuanlan.zhihu.com该文章的内容也是来自于《redis设计与实现》一书
举个例子,以下命令创建了一个新的数据库键值对,这个键值对的键和值都是字符串对象,它
们都包含一个sds 值:
redis> SET book "Mastering C++ in 21 days"
OK
redis> GET book
"Mastering C++ in 21 days"
以下命令创建了另一个键值对,它的键是字符串对象,而值则是一个集合对象:
redis> SADD nosql "Redis" "MongoDB" "Neo4j"
(integer) 3
redis> SMEMBERS nosql
1) "Neo4j"
2) "Redis"
3) "MongoDB"
将
sds 既可以高效地实现追加和长度计算,并且它还是二进制安全的。
其中,类型sds 是char * 的别名(alias),而结构sdshdr 则保存了len 、free 和buf 三个
属性。
4.redis中字符串获取字符串长度的时间复杂度是多少?
保存hello world 字符串的sdshdr 结构:
struct sdshdr {
len = 11;
free = 0;
buf = "hello world0"; // buf 的实际长度为len + 1
};
通过len 属性,sdshdr 可以实现复杂度为(1) 的长度计算操作。
5. redis中字符串是如何减少在追加情况下的内存多次重新分配?
通过对buf 分配一些额外的空间,并使用free 记录未使用空间的大小,sdshdr 可
以让执行追加操作所需的内存重分配次数大大减少
当然,sds 也对操作的正确实现提出了要求——所有处理sdshdr 的函数,都必须正确地更新
len 和free 属性,否则就会造成bug 。
利用sdshdr 结构,除了可以用(1) 复杂度获取字符串的长度之外,还可以减
少追加(append) 操作所需的内存重分配次数,以下就来详细解释这个优化的原理。
为了易于理解,我们用一个Redis 执行实例作为例子,解释一下,当执行以下代码时,Redis
内部发生了什么:
redis> SET msg "hello world"
OK
redis> APPEND msg " again!"
(integer) 18
redis> GET msg
"hello world again!"
首先,SET 命令创建并保存hello world 到一个sdshdr 中,这个sdshdr 的值如下:
struct sdshdr {
len = 11;
free = 0;
buf = "hello world0";
}
当执行APPEND 命令时,相应的sdshdr 被更新,字符串" again!" 会被追加到原来的
"hello world" 之后:
struct sdshdr {
len = 18;
free = 18;
// 空白的地方为预分配空间,共18 + 18 + 1 个字节
buf = "hello world again!0 ";
}
注意,当调用SET 命令创建sdshdr 时,sdshdr 的free 属性为0 ,Redis 也没有为buf 创建
额外的空间——而在执行APPEND 之后,Redis 为buf 创建了多于所需空间一倍的大小。
在这个例子中,保存"hello world again!" 共需要18 + 1 个字节,但程序却为我们分配了
18 + 18 + 1 = 37 个字节——这样一来,如果将来再次对同一个sdshdr 进行追加操作,只要
追加内容的长度不超过free 属性的值,那么就不需要对buf 进行内存重分配。
比如说,执行以下命令并不会引起buf 的内存重分配,因为新追加的字符串长度小于18 :
redis> APPEND msg " again!"
(integer) 25
再次执行APPEND 命令之后,msg 的值所对应的sdshdr 结构可以表示如下:
struct sdshdr {
len = 25;
free = 11;
// 空白的地方为预分配空间,共18 + 18 + 1 个字节
buf = "hello world again! again!0 ";
}
sds.c/sdsMakeRoomFor 函数描述了sdshdr 的这种内存预分配优化策略,以下是这个函数的
伪代码版本:
def sdsMakeRoomFor(sdshdr, required_len):
# 预分配空间足够,无须再进行空间分配
if (sdshdr.free >= required_len):
return sdshdr
# 计算新字符串的总长度
newlen = sdshdr.len + required_len
# 如果新字符串的总长度小于SDS_MAX_PREALLOC
# 那么为字符串分配2 倍于所需长度的空间
# 否则就分配所需长度加上SDS_MAX_PREALLOC 数量的空间
if newlen < SDS_MAX_PREALLOC:
newlen *= 2
else:
newlen += SDS_MAX_PREALLOC
# 分配内存
newsh = zrelloc(sdshdr, sizeof(struct sdshdr)+newlen+1)
# 更新free 属性
newsh.free = newlen - sdshdr.len
# 返回
return newsh
在目前版本的Redis 中,SDS_MAX_PREALLOC 的值为1024 * 1024 ,也就是说,当大小小于
1MB 的字符串执行追加操作时,sdsMakeRoomFor 就为它们分配多于所需大小一倍的空间;当
字符串的大小大于1MB ,那么sdsMakeRoomFor 就为它们额外多分配1MB 的空间。
6. Redis字符串的字符串预分配的空间在什么情况下会被清除掉或者回收掉?
执行过APPEND 命令的字符串会带有额外的预分配空间,这些预分配空间不会被释放,除非
该字符串所对应的键被删除,或者等到关闭Redis 之后,再次启动时重新载入的字符串对象将
不会有预分配空间。
7.如果因为执行APPEND 命令的字符串键数量通常并不多,占用内存的体积通常也不大,
但是如果执行APPEND 操作的键很多,而字符串的体积又很大的话,应该如何进行优化?
那可能就需要修改Redis 服务器,让它定时释放一些字符串键的预分配空间,从而更有效地使用内存。
8.Redis字符串sds的优劣势分别是什么?
Redis 的字符串表示为sds ,而不是C 字符串(以0 结尾的char*)。
• 对比C 字符串,sds 有以下特性:
– 可以高效地执行长度计算(strlen);
– 可以高效地执行追加操作(append);
– 二进制安全;
• sds 会为追加操作进行优化:加快追加操作的速度,并降低内存分配的次数,代价是多占
用了一些内存,而且这些内存不会被主动释放。
9.为什么说redis的字符串是二进制安全的?
sds和char*并不等同,sds是二进制安全的,它可以存储任意二进制数据,不能像C语言字符串那样以‘0’来标识字符串结束,因此它必然存在一个长度字段。
10.redis的字符串为什么要定义五种结构体?
sds结构一共有五种Header定义,其目的是为了满足不同长度的字符串可以使用不同大小的Header,从而节省内存。通过下面的代码可以看出,保存不同长度的字符串采用不同的结构体可以有效节省内存。
/* 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[];
};
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[];
};
11.Redis字符串中为什么使用__attribute__ ((__packed__)) 来修饰结构体?
加上此字段是为了让编译器以紧凑模式来分配内存。如果没有这个字段,编译器会按照struct中的字段进行内存对齐,这样的话就不能保证header和sds的数据部分紧紧的相邻了,也不能按照固定的偏移来获取flags字段。
---------
[Redis源码阅读]sds字符串实现 - hoohack - 博客园www.cnblogs.com Redis源码剖析--动态字符串sdszcheng.ren![c19dbc3576c8f5bb51fac8222958bedb.png](https://i-blog.csdnimg.cn/blog_migrate/bd7d7edfcf93e2c8e1a867c73f8b3bbc.jpeg)
![08924400a6b21e53b8d8f71e542a6d3b.png](https://i-blog.csdnimg.cn/blog_migrate/01d28fac91a964d0f0d8fb3d9ac8e80e.png)
![64c7ee8aa1e84fa8375fb367dfb11548.png](https://i-blog.csdnimg.cn/blog_migrate/db93e0849005dc6f31f9afa4e34eeb69.png)