Redis底层探秘(一):简单动态字符串(SDS)

  

  redis是我们使用非常多的一种缓存技术,他的性能极高,读的速度是110000次/s,写的速度是81000次/s。这么高的性能背后,到底是怎么样的实现在支撑,这个系列的文章,我们一起去看看。

       redis的底层数据结构有以下7种,包括简单动态字符串(SDS),链表、字典、跳跃表、整数集合、压缩列表、对象。今天我们一起看下简单动态字符串(simple dynamic string),后面的文章以SDS简称。

SDS简介

       Redis没有直接使用C语言传统的字符串表示(以空字符结尾的字符串数组,以下简称C字符串)。C字符串并不能满足redis对字符串安全性、效率以及功能的要求,所以Ridis自定义SDS抽象类型。

       Redis中,C字符串只会作为字符串字面量(string literal)用在一些无须对字符串值进行修改的地方,比如打印日志。

       在redis数据库里,包含字符串值的键值对在底层都是由SDS实现的。除了用来保存数据库中的字符串值之外,sds还被用来作缓冲区(buffer):AOF(一种持久化策略)模块中的AOF缓冲区,以及客户端状态中的输入缓冲区,都是由SDS实现的。

       至于SDS的具体好处,我们会在后文有详细的论述。

SDS定义

struct __attribute__ ((__packed__)) sdshdr64 {
    uint64_t len; /* used 记录buff数组中已使用字节的数量 */   
    uint64_t free; /* 记录未使用字节数量*/
    char buf[];
};

下图展示了sds示例

  SDS遵循C字符串以空字符结尾的惯例,保存空字符的1字节空间不计算在SDS的len属性里面,并且为空字符分配额外的1字节空间,以及添加空字符到字符串末尾等操作,都是有SDS函数自动完成的,所以这个空字符对于SDS的使用者来说完全透明。遵循空字符结尾这一惯例的好处是,SDS可以直接重用一部分C字符串函数库里面的函数。

常数复杂度获取字符串长度

       因为C字符串并不记录自身的长度信息,所以为了获取一个C字符串的长度,程序必须遍历整个字符串,复杂度为O(N)。

       和C字符串不同,因为SDS在len属性中记录了SDS本身的长度,所以获取一个SDS长度的复杂度仅为O(1)。

       通过使用SDS而不是C字符串,Redis将获取字符串长度所需的复杂度从O(N)降低到了O(1),这确保了获取字符串长度的工作不会成为Redis的性能瓶颈。这样即使我们队一个非常长的字符串键反复执行StrLen命令,也不会对系统性能造成任何影响。

杜绝缓冲区溢出

       除了获取字符串长度的复杂度高之外,C字符串不记录自身长度带来的另一个问题是容易造成缓冲区溢出(buffer overflow)。举个例子,<string.h>/strcat函数可以将src字符串中的内容拼接到dest字符串末尾。char *strcat( char * dest, const char *src);

       因为C字符串不记录自身的长度,所以strcat嘉定用户在执行这个函数时,已经为dest分配了足够多的内存,但是一旦假定不成立,就会产生缓冲溢出(导致其他内存空间的数据被意外修改)。

       与C字符串不同,SDS空间分配策略完全杜绝了发送缓冲区溢出的可能性:当SDS API需要对SDS进行修改时,API会先检查SDS的空间是否满足修改所需的要求,如果不满足,API会自动将SDS的空间扩展至执行修改所需的大小,然后才执行实际的修改操作,所以使用SDS既不需要手动修改SDS空间大小,也不会出现前面所说的缓冲区溢出问题。

减少修改字符串时带来的内存重分配次数

       因为C字符串并不记录自身长度,所以对于一个包含了N个字符串的C字符串来说,这个C字符串的底层实现总是一个N+1个字符长的数组(额外的一个用来保存空字符)。因为C字符串的长度和底层数组的长度之间存在着这种关联性,所以每次增长或缩短C字符串,程序都总要对保存这个C字符串的数组进行一次内存重分配操作:因为内存重分配涉及复杂的算法,并且可能需要执行系统系统调用,所以它通常是一个比较耗时的操作,redis作为数据库,经常被用于速度要求苛刻、数据频繁修改的场合,如果每次修改字符串都需要执行一次内存重分配,那么效率会相当低。

       为避免C字符串这种缺陷,SDS通过未使用空间解除了字符串长度和底层数组长度之间的关联:在SDS中,buf数组的长度不一定就是字符串数量加一,数组里面可以包含未使用的字节,而这些字节的数量就是由SDS的free属性记录。通过未使用空间,SDS实现了空间预分配和惰性空间释放两种优化策略。

1、空间预分配

       空间预分配用于优化SDS的字符串增长操作:当SDS的API对一个SDS进行修改,并且需要对SDS进行空间扩展的时候,程序不仅会为SDS分配分配修改所必须要的空间,还会为SDS分配额外的未使用空间(具体分配多少空间有一个特殊的算法,这里不做深入讨论。)

       在扩展SDS空间之前,SDS Api会先检查未使用空间是否足够,如果足够的话,api会直接使用未使用空间,而无需执行内存分配。

       通过这种预分配策略,SDS将连续增长N次字符串所需的内存重分配次数从必定N次降低为最多N次。

2、惰性空间释放

       惰性空间释放用于优化SDS的字符串缩短操作:当SDS的ApI需要缩短SDS保存的字符串时,程序并不立即使用内存重分配来回收缩短后多出来的字节,而是使用free属性见这些字节的数量记录起来,并等待将来使用。

       通过惰性空间释放策略,SDS避免了缩短字符串时所需的内存重分配操作,并为将来可能有的增长操作提供了优化。

       与此同时,SDS也提供了相应的API,让我们可以在有需要时,真正地释放SDS的未使用空间,所以不用担心惰性空间释放策略会造成内存浪费。

二进制安全

       C字符串中的字符必须符合某种编码(比如ASCII),并且除了字符串的末尾之外,字符串里面不能包含空字符,否则最先被程序读入的空字符江北误认为是字符串结尾,这些限制使得C字符串只能保存文本数据,而不能保存像图片、音频、视频、压缩文件这样的二进制数据。

     虽然数据库一般用于保存文本数据,但使用数据库来保存二进制数据的场景也不少见,因此,为了确保Redis可以适用于各种不同的使用场景,SDS的API都是二进制安全。

       这也是我们将SDS的buf属性称为字节数组的原因—Redis不是用这个数组来保存字符,而是用它来保存一系列二进制数据。

兼容部分C字符串函数

       虽然SDS的API都是二进制安全的,但它们一样遵循C字符串以空字符结尾的惯例:这些API总会将SDS保存的数据末尾设置为空字符,并且总会在为BUF数组分配空间时多分配一个字节来容纳这个空字符,这是为了让那些保存文本数据的SDS可以重用一个部分<string.h>库定义的函数。

       比如我们可以重用<string.h>/strcasecmp函数,使用它来对比SDS保存的字符串和另一个C字符串。

strcasecmp(sds->buf,”hello world”);

这样redis就不用自己专门去写一个函数来对比SDS和C字符串的值了。

SDS API

 

参考资料:

redis设计与实现(第二版)

Redis in action

猜你喜欢

转载自www.cnblogs.com/qixinbo/p/9650451.html