Redis的字符串的底层实现SDS

前言

Redis是使用C语言开发的，C语言又自己字符类型，但是Redis却没有直接使用C语言传统的字符串表示（以空字符串结尾的字符数组），而是自己构建了一种名为简单动态字符串（simple dynamic string，SDS）的抽象类型，并将SDS用作Redis 的默认字符串表示。

举个例子就是，如果客户端执行如下命令：

实际上在Redis内部创建了两个SDS，一个是名为“msg”的key的SDS，另一个是名为“hello world”的SDS。

SDS的定义

如果去查看源码，一个SDS的数据结构如下

struct sdshdr {
    // 记录buf数组中已使用字节的数量，等于SDS所保存字符串长度
    int len;
    // 记录buf数组中未使用字节数量
    int free;
    // 字节数组，用户保存字符串
    char buf[]
};

SDS相比C字符串的优势

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

学过C语言的都知道，在C语言中我们如果想获取一个字符串的长度，只有从头到尾的进行一波遍历，直到出现空字符串就停止，以此来统计字符串的长度，这种方式的时间复杂度是O（n）。

我们通过观察Redis中SDS的结构就发现了，它自己本身就保存了长度信息，所以我们要获取长度的话，他的时间复杂度就是O（1）。

杜绝缓冲区溢出

在C语言中，如果你想要拼接字符串时，它总是假定你已经分配好了足够的内存，但是一旦假定不成立，那么就会产生缓冲区溢出。

原本在程序内存中有两个紧邻着的C字符串s1和s2，s1保存了字符串“Redis”，s2保存了字符串“MongoDB”，如下图。

如果程序执行了语句，将s1的内存修改为“Redis Cluster”，但是在执行之前没有为s1分配足够的内存空间，那么在执行完只有，s1的数据就将溢出到s2所在的空间中，导致s2的内容被恶意的修改。

我们可以看出s1修改的内容最终落在了字符串s2的位置上了。

而在Redis中的SDS实际上就是对操作API进行封装，当调用API对SDS进行修改时，首先检查空间是否满足修改需求，如果不满足的话，API会自动将SDS的空间自动扩展至合适大小，然后再执行实际的修改操作。

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

Redis是一个高速缓存的数据库，性能就是他的命。同时经常要对字符串进行频繁的拼接和截断的操作，但是内存分配又是一个比较耗时的操作，如果每次修改字符串的长度都需要执行一次内存重新分配的话，可能还会对性能造成影响。

空间预分配
空间预分配用于优化SDS的字符串增长操作：当SDS的API对一个SDS进行修改。并且需要对SDS进行空间扩展的时候，程序不仅会为SDS分配修改所必须的空间，还会为SDS分配额外的未使用空间free，这样就避免了连续执行字符串添加带来的性能消耗。

惰性空间释放

每次分配都会分配多余的空间，那么会不会造成内存泄露或者浪费？所以还需要考虑内存释放问题。

Redis中采用了惰性空间释放用于优化SDS的字符串缩短操作：当SDS的API需要缩短字符串时，程序并不会立即使用内存重新来回收缩短后多出来的字节，而是使用free属性将这些字节数据记录起来，并等待将来使用。

二进制安全

在C语言中，判断一个字符串是否到达末尾就是检测是否出现了空字符串‘\0’。但是有很多数据结构很经常穿插空字符串在中间，比如图片，音频，视频，压缩文件的二进制数据。

而Redis就没有这种问题了，因为他自身的SDS结构中就已经保存了字符串的长度，所以我们不在需要依据‘\0’作为字符串的结尾，直接使用len就好了