几分钟教你掌握Redis简单动态字符串SDS-数据库

这篇文章主要为大家介绍了几分钟教你掌握Redis简单动态字符串SDS方法，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪

正文

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

在 Redis 里面，C 字符串只会作为字符串字面量（string literal），用在一些无须对字符串值进行修改的地方，比如打印日志：

redisLog(REDIS_WARNING,"Redis is now ready to exit, bye bye...");

当 Redis 需要的不仅仅是一个字符串字面量，而是一个可以被修改的字符串值时，Redis 就会使用 SDS 来表示字符串值：比如在 Redis 的数据库里面，包含字符串的键值对在底层都是由 SDS 实现的。

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

redis> SET msg "hello world"
OK

那么 Redis 将在数据库中创建了一个新的键值对，其中：

键值对的键是一个字符串对象，对象的底层实现是一个保存着字符串 "msg" 的 SDS 。
键值对的值也是一个字符串对象，对象的底层实现是一个保存着字符串 "hello world" 的SDS。

又比如说，如果客户端执行命令：

redis> RPUSH fruits "apple" "banana" "cherry"
(integer) 3

那么 Redis 将在数据库中创建一个新的键值对，其中：

键值对的键是一个字符串对象，对象的底层实现是一个保存了字符串 "fruits" 的 SDS 。
键值对的值是一个列表对象，列表对象包含了三个字符串对象，这三个字符串对象分别由三个 SDS 实现：第一个 SDS 保存着字符串 "apple" ，第二个 SDS 保存着字符串 "banana" ，第三个 SDS 保存着字符串 "cherry" 。

除了用来保存数据库中的字符串值之外，SDS 还被用作缓冲区（buffer）：AOF 模块中的 AOF 缓冲区，以及客户端状态中的输入缓冲区，都是由 SDS 实现的，在之后介绍 AOF 持久化和客户端状态的时候，我们会看到 SDS 在这两个模块中的应用。

AOF中记录的是每一个命令的详细信息，包括完整的命令类型、参数等。只要产生写命令，就会实时写入到AOF文件中

SDS的定义

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

与C字符串的区别

C语言使用长度为 N+1 的字符数组来表示长度为 N 的字符串，并且字符数组的最后一个元素总是空字符 '\0'。

IiBzcmM9

获取字符串长度

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

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

杜绝缓冲区溢出

C 字符串不记录自身长度带来的另一个问题是容易造成缓冲区溢出（buffer overflow）。

假设程序里有两个在内存中紧邻着的 C 字符串 s1 和 s2 ，其中 s1 保存了字符串 "Redis" ，而 s2 则保存了字符串 "MongoDB" .

IiBzcmM9

如果一个程序员决定通过执行：strcat(s1, "Cluster")将 s1 的内容修改为 "Redis Cluster" ，但粗心的他却忘了在执行 strcat 之前为 s1 分配足够的空间，那么在 strcat 函数执行之后，s1 的数据将溢出到 s2 所在的空间中，导致 s2 保存的内容被意外地修改。

IiBzcmM9

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