Redis设计与实现
第一章数据结构与对象(字符串)
- 字符串的实现
Redis并没有直接使用c语言里面的字符串表示,而是自己构造了名为简单动态字符串(SDS)的抽象类型,并将SDS用作Redis的默认字符串表示。
在Redis里面,C字符串只会作为字符串字面量(string literal)用在 一些无须对字符串值进行修改的地方,比如打印日志:
redisLog(REDIS_WARNING,“Redis is now ready to exit, bye bye…”);
如果Redis需要对字符串进行修改,那就需要使用SDS来表示字符串。
redis> SET msg "hello world" OK
如上述,键msg用SDS,键值对的值"hello word"也是使用SDS。
redis> RPUSH fruits "apple" "banana" "cherry"
键值对的键是一个字符串对象,对象的底层实现是一个保存了字 符串“fruits”的SDS。 键值对的值是一个列表对象,列表对象包含了三个字符串对象, 这三个字符串对象分别由三个SDS实现:第一个SDS保存着字符 串“apple”,第二个SDS保存着字符串“banana”,第三个SDS保存着字符 串“cherry”。
- SDS的其他作用
SDS还被用作缓冲区 (buffer):AOF模块中的AOF缓冲区,以及客户端状态中的输入缓冲 区,都是由SDS实现的,在之后介绍AOF持久化和客户端状态的时候, 我们会看到SDS在这两个模块中的应用。 - SDS的实现
struct sdshdr {
//
记录buf
数组中已使用字节的数量
//
等于SDS
所保存字符串的长度
int len;
//
记录buf
数组中未使用字节的数量
int free;
//
字节数组,用于保存字符串
char buf[];
};
free属性的值为0,表示这个SDS没有分配任何未使用空间。
len属性的值为5,表示这个SDS保存了一个五字节长的字符串。
buf属性是一个char类型的数组,数组的前五个字节分别保存 了’R’、‘e’、‘d’、‘i’、‘s’五个字符,而最后一个字节则保存了空字符’\0’。
这个SDS和之前展示的SDS一样,都 保存了字符串值“Redis”。这个SDS和之前展示的SDS的区别在于,这个 SDS为buf数组分配了五字节未使用空间,所以它 的free属性的值为 5(图中使用五个空格来表示五字节的未使用空间)。
- SDS和C字符串的的区别
- 获取长度
C字符串:因为C字符串并不记录自身的长度信息,所以为了获取一个C字符 串的长度,程序必须遍历整个字符串,对遇到的每个字符进行计数,直到遇到代表字符串结尾的空字符为止,这个操作的复杂度为O(N)。
SDS:程序只要访问SDS的len属性,就可以立即知道SDS的长度。所以这个操作的时间复杂度为O(1)。
通过使用SDS而不是C字符串,Redis将获取字符串长度所需的复杂 度从O(N)降低到了O(1),这确保了获取字符串长度的工作不会成为Redis的性能瓶颈。例如,因为字符串键在底层使用SDS来实现,所以即使我们对一个非常长的字符串键反复执行STRLEN命令,也不会对系统性能造成任何影响,因为STRLEN命令的复杂度仅为O(1)。 - 杜绝缓冲区溢出
C字符串不记录自身长度带容易造成缓冲区溢出(buffer overflow)。举个例子,假设程序里有两个在内存中紧邻着的C字符串s1和s2, 其中s1保存了字符串"Redis",而s2则保存了字符串"MongoDB"。
如果一个程序员决定通过执行: strcat(s1, " Cluster");
将s1的内容修改为"Redis Cluster",但粗心的他却忘了在执行strcat 之前为s1分配足够的空间,那么在strcat函数执行之后,s1的数据将溢出到s2所在的空间中,导致s2保存的内容被意外地修改。
与C字符串不同,SDS的空间分配策略完全杜绝了发生缓冲区溢出的可能性。当SDS API需要对SDS进行修改时,API会先检查SDS的空间是否满足修改所需的要求,如果不满足的话,API会自动将SDS的空间扩展至执行修改所需的大小,然后才执行实际的修改操作。
举个例子,SDS的API里面也有一个用于执行拼接操作的sdscat函数,它可以将一个C字符串拼接到给定SDS所保存的字符串的后面,但是在执行拼接操作之前,sdscat会先检查给定SDS的空间是否足够,如果不够的话,sdscat就会先扩展SDS的空间,然后才执行拼接操作。
例如,如果我们执行:
sdscat(s, " Cluster");
执行之前s如图所示:
执行之后s如图所示:
sdscat不仅对这个SDS进行了拼接操作,它还为SDS分配了13字节的未使用空间,并且拼接之后的字符串也正好是13字节长,这种现象既不是bug也不是巧合,它和SDS的空间分配策略有关,接下来的小节将对这一策略进行说明。
- 减少修改字符串时带来的内存重分配次数
因为C字符串的长度和底层数组的长度之间存在着这种关联性,所以每次增长或者缩短一个C字符串,程序都总要对保存这个C字符串的数组进行一次内存重分配操作。因为内存重分配涉及复杂的算法,并且可能需要执行系统调用,所以它通常是一个比较耗时的操作。
Redis作为数据库,经常被用于速度要求严苛、数据被频繁修改的场合,如果每次修改字符串的长度都需要执行一次内存重分配的话,那么光是执行内存重分配的时间就会占去修改字符串所用时间的一大部分,如果这种修改频繁地发生的话,可能还会对性能造成影响。为了避免C字符串的这种缺陷,SDS通过未使用空间解除了字符串长度和底层数组长度之间的关联:在SDS中,buf数组的长度不一定就是字符数量加一,数组里面可以包含未使用的字节,而这些字节的数量就由SDS的free属性记录。
通过未使用空间,SDS实现了空间预分配和惰性空间释放两种优化策略。
- 空间预分配 。
空间预分配用于优化SDS的字符串增长操作:当SDS的API对一个SDS进行修改,并且需要对SDS进行空间扩展的时候,程序不仅会为SDS分配修改所必须要的空间,还会为SDS分配额外的未使用空间。
如果对SDS进行修改之后,SDS的长度(也即是len属性的值)将小于1MB,那么程序分配和len属性同样大小的未使用空间,这时SDS len属性的值将和free属性的值相同。举个例子,如果进行修改之后,SDS的len将变成13字节,那么程序也会分配13字节的未使用空间,SDS的buf数组的实际长度将变成13+13+1=27字节(额外的一字节用于保存空字符)。如果对SDS进行修改之后,SDS的长度将大于等于1MB,那么程序会分配1MB的未使用空间。举个例子,如果进行修改之后,SDS的len将变成30MB,那么程序会分配1MB的未使用空间,SDS的buf数组的实际长度30MB+1MB+1byte。
在扩展SDS空间之前,SDS API会先检查未使用空间是否足够,如果足够的话,API就会直接使用未使用空间,而无须执行内存重分配。通过这种预分配策略,SDS将连续增长N次字符串所需的内存重分配次数从必定N次降低为最多N次。 - 惰性空间释放
惰性空间释放用于优化SDS的字符串缩短操作:当SDS的API需要缩短SDS保存的字符串时,程序并不立即使用内存重分配来回收缩短后多出来的字节,而是使用free属性将这些字节的数量记录起来,并等待将来使用。 通过惰性空间释放策略,SDS避免了缩短字符串时所需的内存重分配操作,并为将来可能有的增长操作提供了优化。 与此同时,SDS也提供了相应的API,让我们可以在有需要时,真正地释放SDS的未使用空间,所以不用担心惰性空间释放策略会造成内存浪费。 - 二进制安全
C字符串中的字符必须符合某种编码(比如ASCII),并且除了字符串的末尾之外,字符串里面不能包含空字符,否则最先被程序读入的空字符将被误认为是字符串结尾,这些限制使得C字符串只能保存文本数据,而不能保存像图片、音频、视频、压缩文件这样的二进制数据。
使用SDS来保存之前提到的特殊数据格式就没有任何问题,因为SDS使用len属性的值而不是空字符来判断字符串是否结束。
- 总结
Redis只会使用C字符串作为字面量,在大多数情况下,Redis使用SDS(Simple Dynamic String,简单动态字符串)作为字符串表示。
比起C字符串,SDS具有以下优点:
1)常数复杂度获取字符串长度。
2)杜绝缓冲区溢出。
3)减少修改字符串长度时所需的内存重分配次数。
4)二进制安全。
5)兼容部分C字符串函数