Redis设计与实现一之简单的动态字符串

　简单的动态字符串

Redis没有直接使用C语言中的字符串，而是自己构建了SDS这样的一种简单动态字符串，并且将他作为Redis中字符串的默认的表示。

但是并未完全抛弃C语言字符串，只不过是在C语言字符串的基础上，通过封装其他的属性，构造出一个更加高效的字符串的封装结构。

SDS ： redis 没有直接使用C语言的字符串，构建了一种简单动态字符串（simple dynamic string，即SDS）的抽象类型作为redis的默认字符串

SDS 用来保存字符串外，还被用作缓冲区，如：AOF缓存区，客户端输入缓冲区

C语言字符串 vs SDS

对比项	C语言字符串	SDS
获取字符串长度的复杂度	O(N)	O(1)
API安全性	不安全，会造成缓冲区溢出	安全
修改字符串长度	修改N次，必须执行N次内存重分配	修改N次，最多需要执行N次内存重分配
保存数据格式类型	只能保存文本数据	文本或二进制数据
函数库<string.h>使用度	全部可用	只有部分可用

SDS的定义

SDS示例：

1. free属性的值0，该SDS没有空闲的未使用空间。

2. len 为5，表示字符串的长度为5

3. buf是一个为CAHR字符数组，最后一位为\0标识字符串的结束。

SDS遵循C字符串以空字符结束的惯例，保留空字符的1字节的空间，不计算在SDS的len属性中，并且为空字符分配一个字节的空间，遵循这一惯例使得SDS仍然可以使用部分C语言字符串的一些函数。

SDS与C字符串的区别

Redis对字符串在安全性、效率和功能方面都要求很高，如果直接照搬C语言的字符串，会出现很多问题，而且当获取长度等操作的时候，效率明显很低达到O(N)。

获取字符串长度

1. C字符串不记录自己的长度，当需要获取长度的时候，需要遍历整个字符数组，对遇到的所有的字符进行计数，直到遇到空字符为止，执行时间复杂度为O(N)。

2. SDS字符串保存了自身的长度，当需要获取长度的时候，直接可以获取到，这样把时间复杂度降低到O(1)。图中为2.9版本中实例，如果3.2这里的free是没有的，计算free需要用alloc-len算出。

杜绝缓冲区溢出

C语言不记录字符串长度的另一个弊端就是容易造成缓冲区溢出。举个例子，拼接两个字符串：wy和xx

假设前者为s1后者为s2，那么这里在进行字符串拼接的时候，一旦没有为s1从新分配适合的空间的话，那么拼接后的结果会溢出到s2的空间中去。

SDS在进行字符串拼接的时候，会自行检查是不是内存空间是不是 满足要求，如果不满足的话，自动进行分配，而且在进行分配空间的时候，会实行预先分配的策略。

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

C语言字符串在进行字符串的扩充和收缩的时候，都会面临着内存空间的重新分配问题。

1. 字符串拼接会产生字符串的内存空间的扩充，在拼接的过程中，原来的字符串的大小很可能小于拼接后的字符串的大小，那么这样的话，就会导致一旦忘记申请分配空间，就会导致内存的溢出。

2. 字符串在进行收缩的时候，内存空间会相应的收缩，而如果在进行字符串的切割的时候，没有对内存的空间进行一个重新分配，那么这部分多出来的空间就成为了内存泄露。

Redis在内存空间分配的问题上进行了优化，主要分为两个过程。

1. 内存预分配

内存空间进行分配的时候，预先分配一块多余的空间给当前的字符串对象，使得，在下一次字符串比如拼接的时候，尽可能保证其内存空间的足够用，不需要再去分配内存，这样的话，效率将会大大的提升。

额外分配未使用空间数量：

1). 如果修改之后SDS的长度小于1MB,那么程序将会分配和当前字符串len相同的空间给该字符串对象。比如说，wy和xx进行合并，这里是4个字符，大小为4，实际的存储大小为5，但是分配的内存空间大小会采用预分配的方式，那么分配后的内存大小为4+4+1=9个字节。

2). 如果修改之后的SDS的长度大小大于等于1MB的话，程序分配的内存空间将会为1MB,比如说变化后的字符串对象达到了30M，当他在分配空间的时候只分配1MB空间。那么最终空间大小为30M+1MB+1B.

2. 惰性释放

当字符串进行缩短操作的时候，并不立即将空间释放出来，而是，将这部分空间通过free进行标识，本字符串有多少的空余的空间。这样的话，在再次使用时也可以避免分配内存造成的时间开销。

当然，Redis中提供了专门的API，需要的时候，会真正的释放这部分空闲的内存。

二进制安全

C字符串必须符合某种编码，除了字符串的末尾外，不能包含空字符，否则会被误认为是字符串的结尾，导致最终读取的字符串是不完整的。

这些限制导致了字符串不能用于存放图片、音频、视频等二进制数据，只能存放文本数据。

但是在Redis中，不是靠空字符来判断字符串的结束的，而是通过len这个属性。那么，即便是中间出现了空字符对于SDS来说，读取该字符仍然是可以的。

总结:

1. redis 3.2之后，针对不同长度的字符串引入了不同的SDS数据结构，并且强制内存对齐1，将内存对齐交给统一的内存分配函数，从而达到节省内存的目的
2. SDS的字符串长度通过sds->len来控制，不受限于C语言字符串\0，可以存储二进制数据，并且将获取字符串长度的时间复杂度降到了O(1)
3. SDS的头和buf字节数组的内存是连续的，可以通过寻址方式获取SDS的指针以及flags值
4. SDS的拼接扩展有一个内存预分配策略，用空间减少每次拼接的内存重分配可能性
5. SDS的缩短并不会真正释放掉对应空闲空间
6. SDS分配内存都会多分配1个字节用来在buf的末尾追加一个\0，在部分场景下可以和C语言字符串保证同样的行为甚至复用部分string.h的函数

源码可以查看《Redis设计与实现》书籍