Redis设计与实现-1.数据结构

Posted 2020-11-27 名字可以起这么长

       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字符串的值了。