Simple Dynamic String

引言

为何redis中大量使用的是SDS，而不是传统的C语言字符串表示法存储字符串？到底什么是SDS？为什么要使用SDS？其相对于传统的C语言字符串有何优点？本文会针对以上几点做一个详细的分析，帮助大家以及自己更好的理解redis中的简单动态字符串

介绍SDS之前先简单介绍一下C语言中的传统字符串表示法

C语言字符串（C字符串）

始终以空字符结尾的字符数组，c语言为其封装了大量的函数库操作API

C字符串特点

• 字符数组存储

• 以空字符结尾，除了末尾之外，字符串里面不可以包含空字符

• 由于采用字符数组，导致所存储的字符必须符合某种编码（如ASCII）

• 获取C字符串长度必须遍历整个字符串，并对遇到的每个字符计数，直到遇到空字符为止，时间复杂度为O(N)

那么基于以上特点，C字符串是否能够满足我们Redis高效，安全的需求呢？显然是不能的，单是一个获取字符串长度就需要遍历整个字符串数组了，必须重新定义一种新的结构以支持Redis中对于频繁高效操作字符串的要求

---

SDS 简单动态字符串

基于以上C字符串的缺陷，Redis自己构建了一种名为简单动态字符串的抽象类型，简称SDS

SDS结构

struct sdshdr {

    // buf数组已经使用字节数量，即SDS字符串长度
    int len;

    // 记录buf数组中未使用字节的数量
    int free;

    // 字节数组，用于保存二进制数据
    char buf[];
}

可以看出，SDS定义的结构中，增加了一个int类型的len属性用于记录SDS所保存的字符串长度，一个free属性用于记录数组中未使用的字节数量

SDS特点

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

Redis中利用SDS字符串的len属性可以直接获取到所保存的字符串的长
度，直接将获取字符串长度所需的复杂度从C字符串的O(N)降低到了O(1)

---

• 减少修改字符串时导致的内存重新分配次数

基于前面介绍的C字符串的特性，我们知道对于一个包含了N个字符的C字符串来说，其底层实现总是N+1个字符长的数组（额外一个空字符结尾），那么如果这个时候需要对字符串进行修改，程序就需要提前对这个C字符串数组进行一次内存重分配（可能是扩展或者释放），而内存重分配就意味着是一个耗时的操作

Redis巧妙的使用了SDS避免了C字符串的缺陷，再SDS中，buf数组的长度不一定就是字符串的字符数量加一，buf数组里面可以包含未使用的字节，而这些未使用的字节由free属性记录

SDS采用了空间预分配策略避免C字符串每一次修改时都需要进行内存重分配的耗时操作，将内存重分配从原来的每修改N次就分配N次降低到了修改N次最多分配N次

字符串扩展：

首先检查SDS未使用空间即free属性是否够用，如果够用，则会直接使用未使用空间，而无须进行内存重分配

空间预分配

所谓预分配就是额外多分配一部分空间给SDS，并不是仅仅只分配刚好够字符串扩展修改后的空间

分配策略：

2. 若SDS修改后，其长度（len的属性）小于1MB，那么程序会分配和修改后的len属性同样大小的未使用空间

3. 若修改后，其长度大于1MB，那么程序只会分配固定1MB的未使用空间，不会再多分配了，考虑内存的成本因素

字符串缩短：

针对SDS字符串的缩短场景，SDS并不会立即释放多余出来的内存空间，而是将这部分内存空间记录再其free属性中，当SDS字符串进行扩展时，这部分未使用的内存空间就能直接用，而不需要进行内存重分配，这就是SDS的惰性空间释放

---

• 杜绝缓冲区溢出

在C字符串的拼接操作过程中，例如某程序员操作S1拼接S2，由于程序员忘记了给需要拼接的字符串S1分配足够的内存空间（到底需要分配多少内存呢？哈哈，当然需要遍历S2的字符数组才能知道S2的长度是多少，因为C字符串不记录自身的长度），那么拼接的时候就会导致缓冲区溢出的可能性

针对以上情况，SDS的空间分配策略可以完全杜绝这种情况，因为当SDS 的API对SDS进行修改时，API会首先检查SDS的未使用空间是否足够，不够的化会进行内存重分配以扩展空间至足够修改所需的大小，然后再执行实际的修改操作，这样就可以达到杜绝缓冲区溢出的可能

---

• 让Redis保存更多类型的数据成为可能

由于C字符串中保存的字符必须符合某种编码格式（如ASCII），这就限制了C字符串只能保存文本数据，而不能保存箱视频，音频，压缩文件这种的二进制数据

另一个限制是C字符串中间不能包含空字符，否则中间的空字符会被认为是整个字符串的结尾，而导致后面的部分字符被忽略掉

SDS的API被设计成了二进制安全的，以处理二进制的方式来处理SDS中存放再buf数组中的数据，原样存取，这就是为什么在SDS的结构中采用的是字节数组，而不是C字符串中的字符数组

这样的二进制安全的SDS，使得Redis不仅可以保存文本，还可以保存任意格式的二进制数据

---

• 兼容部分C字符串API

由于C字符串本身具有大量操作API，SDS如果可以利用一部分C字符串的API那样就不用重复发明轮子了，所以Redis中的SDS遵循C字符串以空字符结尾的惯例，在SDS的API中，总会将SDS保存的数据末尾设置未空字符，在分配buf数组时也总会多分配一个字节来保存这个空字符，这样SDS就可以重用一部分C字符串库的API

---

C字符串与SDS对比

对比点	C字符串	SDS
获取字符串长度时间复杂度	O(N)	O(1)
API安全性	不安全，可能造成缓冲区溢出	安全，不会造成溢出
字符串修改N次需要几次内存重分配	N次	至多Ｎ次
能够保存数据类型	只能保存文本	文本或二进制
对于C语言中字符串API的使用范围	所有	一部分

总结

Redis中采用SDS替代C语言中传统字符串表示法，提升了获取字符串长度的效率，扩大了能够保存数据的类型范围，以及降低了每次修改字符串时候的内存重分配次数，甚至规避了在操作C字符串中可能出现的缓冲区内存溢出的可能性，从而为Redis中字符串操作的安全，高效提供了保障。