Redis之String的底层实现（SDS全方位讲解）

前言：

我们知道的是对于redis来说其相比于memcached而言其中的一个优点就是数据数据结构来说，reids有五种数据结构来实现各种不同的操作，所以运用也就更加广泛些，其中对于String类型来说，Redis就对其底层进行了一个优化的梳理，不再是简单的使用C中的字符，而是使用到了一个全新的数据结构 SDS。本节我们就先来介绍一下SDS，来揭开他的真实面纱。

定义学习

既然要学习到一个新的数据结构，那我们先来看看结构的定义是怎样的：

结构定义：

struct sdshdr{
int len;// 用于记录buf数组中已经使用的字节的数量，也等于SDS所保留的字符串的长度。
int free;// 记录buf数组中未使用的字节的数量。
int free； // 字节数组，用于保存字符串。
}

可能在看完结构的定义以后大家还是有点懵的，那么有图有真相：
在这里插入图片描述如上图所示，下面我们来进行具体的介绍：

free属性的值为0，表示这个SDS没有分配任何未使用空间。
len属性的值为5，表示这个SDS保存了一个五字节长的字符串。
buf属性是一个char类型的数组，数组的前五个字节分别保存了’R’、‘e’、‘d’、‘i’、‘s’五个字符，而最后一个字节则保存了空字符’\0’。

了解完了基础的结构以后，其实对于SDS还是和我们基本的C字符有很大的相似的地方：保留了空字符结尾的惯例，也会保留空字符的1自己空间并不计算在SDS的len属性里面，并且为空字符分配额外的1字节空间，以及添加空字符到字符串末尾等操作，都是由SDS函数自动完成的，所以这个空字符对于SDS的使用者来说是完全透明的。

作用讲解

前面有讲到对于SDS还有一个free变量的存在表示“未使用的空间的大小” 可能是如下的状态：
在这里插入图片描述
此时就会有五个空间是空闲下来未被使用到的。
下面我们就来讲解为什么对于Redis来说不使用现成的C类型的字符而偏偏要使用SDS。

常数复杂度获取字符长度

我们都知道对于一个C字符串来说并不会记录自身的长度，所以在获取长度的时候就需要对整个字符进行一个遍历，直到遇到代表字符串结尾的空字符为止，这个操作的复杂度为O（N）。
和C字符串不同，因为SDS在len属性中记录了SDS本身的长度，所以获取一个SDS长度的复杂度仅为O（1）。我们只需要访问到SDS中的len属性即可直接获取到长度。
注：设置和更新SDS长度的工作是由SDS的API在执行时自动完成的，使用SDS无须进行任何手动修改长度的工作。

好处

通过使用SDS而不是C字符串，Redis将获取字符串长度所需的复杂度从O（N）降低到了O（1），这确保了获取字符串长度的工作不会成为Redis的性能瓶颈。例如，因为字符串键在底层使用SDS来实现，所以即使我们对一个非常长的字符串键反复执行STRLEN命令，也不会对系统性能造成任何影响，因为STRLEN命令的复杂度仅为O（1）。

杜绝缓冲区溢出

除了获取字符串长度的复杂度高之外，C字符串不记录自身长度带来的另一个问题是容易造成缓冲区溢出（bufferoverflow）。举个例子，＜string.h＞/strcat函数可以将src字符串中的内容拼接到dest字符串的末尾：

char * strcat(char * dest,const char * src);

因为C字符串不记录自身的长度，所以strcat假定用户在执行这个函数时，已经为dest分配了足够多的内存，可以容纳src字符串中的所有内容，而一旦这个假定不成立时，就会产生缓冲区溢出。
举个栗子：
假设程序里有两个在内存中紧邻着的C字符串s1和s2，其中s1保存了字符串"Redis"，而s2则保存了字符串"MongoDB"。这个时候我们若是执行

strcat(s1,"Clustre");

将s1的内容修改为"Redis Cluster"，但却粗心地忘了在执行strcat之前为s1分配足够的空间，那么在strcat函数执行之后，s1的数据将溢出到s2所在的空间中，导致s2保存的内容被意外地修改。就会导致下图的情况出现：S1的内容溢出到S2所在的位置上面。
在这里插入图片描述
对于 SDS来说完全不会出现这样的情况：
当SDS API需要对SDS进行修改时，API会先检查SDS的空间是否满足修改所需的要求，如果不满足的话，API会自动将SDS的空间扩展至执行修改所需的大小，然后才执行实际的修改操作，所以使用SDS既不需要手动修改SDS的空间大小，也不会出现前面所说的缓冲区溢出问题。

SDS的API里面也有一个用于执行拼接操作的sdscat函数，它可以将一个C字符串拼接到给定SDS所保存的字符串的后面，但是在执行拼接操作之前，sdscat 会先检查给定SDS的空间是否足够，如果不够的话，sdscat就会先扩展SDS的空间，然后才执行拼接操作。

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

我们都知道的是，在前面两个小结里面说到因为C字符串并不记录自身的长度，所以对于一个包含了N个字符的C字符串来说，这个C字符串的底层实现总是一个N+1个字符长的数组（额外的一个字符空间用于保存空字符）。因为C字符串的长度和底层数组的长度之间存在着这种关联性，所以每次增长或者缩短一个C字符串，程序都总要对保存这个C字符串的数组进行一次内存重分配操作：

❑ 如果程序执行的是增长字符串的操作，比如拼接操作（append），那么在执行这个操作之前，程序需要先通过内存重分配来扩展底层数组的空间大小——如果忘了这一步就会产生缓冲区溢出。
❑ 如果程序执行的是缩短字符串的操作，比如截断操作（trim），那么在执行这个操作之后，程序需要通过内存重分配来释放字符串不再使用的那部分空间——如果忘了这一步就会产生内存泄漏。

当然对于干巴巴的叙述很有可能大家就看晕了，又到了最欢乐的时候举例子：

举个栗子
如果我们持有一个值为"Redis"的C字符串s，那么为了将s的值改为"Redis Cluster"，在执行：

strcat(s,"Clustre");

之前，我们需要先使用内存重分配操作，扩展空间。
之后，如果我们又打算将s的值从"Redis Cluster"改为"Redis Cluster Tutorial"，那么再执行：

strcat(s,"Clustre1");

之前，还是要重复以上的操作。（无限套娃）
这个时候我们就看到了问题的所在：因为内存重分配涉及复杂的算法，并且可能需要执行系统调用，所以它通常是一个比较耗时的操作：
但是对于Redis来说：经常被用于速度要求严苛、数据被频繁修改的场合，如果每次修改字符串的长度都需要执行一次内存重分配的话，那么光是执行内存重分配的时间就会占去修改字符串所用时间的一大部分，如果这种修改频繁地发生的话，可能还会对性能造成影响。这也是高兴呢的Redis所不允许的。

所以呢为了避免C字符串的这种缺陷，SDS通过未使用空间解除了字符串长度和底层数组长度之间的关联：在SDS中，buf数组的长度不一定就是字符数量加一，数组里面可以包含未使用的字节，而这些字节的数量就由SDS的free属性记录。通过未使用空间，SDS实现了空间预分配和惰性空间释放两种优化策略。

空间预分配：

空间预分配用于优化SDS的字符串增长操作：当SDS的API对一个SDS进行修改，并且需要对SDS进行空间扩展的时候，程序不仅会为SDS分配修改所必须要的空间，还会为SDS分配额外的未使用空间。

其中，额外分配的未使用空间数量由以下公式决定：
❑如果对SDS进行修改之后，SDS的长度（也即是len属性的值）将小于1MB，那么程序分配和len属性同样大小的未使用空间，这时SDS len属性的值将和free属性的值相同。举个例子，如果进行修改之后，SDS的len将变成13字节，那么程序也会分配13字节的未使用空间，SDS的buf数组的实际长度将变成13+13+1=27字节（额外的一字节用于保存空字符）。

❑如果对SDS进行修改之后，SDS的长度将大于等于1MB，那么程序会分配1MB的未使用空间。举个例子，如果进行修改之后，SDS的len将变成30MB，那么程序会分配1MB的未使用空间，SDS的buf数组的实际长度将为30MB+1MB+1byte。

通过空间预分配策略，Redis可以减少连续执行字符串增长操作所需的内存重分配次数

惰性空间释放

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

举个栗子：
sdstrim函数接受一个SDS和一个C字符串作为参数，移除SDS中所有在C字符串中出现过的字符。若是对如下的s
在这里插入图片描述
来执行

sdstrim(s,"XY");// 移除SDSZ中所有的X与Y;

就会变成如下图所示：
在这里插入图片描述
注：注意执行sdstrim之后的SDS并没有释放多出来的8字节空间，而是将这8字节空间作为未使用空间保留在了SDS里面，如果将来要对SDS进行增长操作的话，这些未使用空间就可能会派上用场。

这个时候如果恰好执行了

strcat(s,"Redis");

那么完成这次sdscat操作将不需要执行内存重分配：因为SDS里面预留的8字节空间已经足以拼接6个字节长的"Redis" 如下图所示：
在这里插入图片描述
与此同时，SDS也提供了相应的API，让我们可以在有需要时，真正地释放SDS的未使用空间，所以不用担心惰性空间释放策略会造成内存浪费。

二进制安全

C字符串中的字符必须符合某种编码（比如ASCII），并且除了字符串的末尾之外，字符串里面不能包含空字符，否则最先被程序读入的空字符将被误认为是字符串结尾，这些限制使得C字符串只能保存文本数据，而不能保存像图片、音频、视频、压缩文件这样的二进制数据。

虽然数据库一般用于保存文本数据，但使用数据库来保存二进制数据的场景也不少见，因此，为了确保Redis可以适用于各种不同的使用场景，SDS的API都是二进制安全的（binary-safe），所有SDS API都会以处理二进制的方式来处理SDS存放在buf数组里的数据，程序不会对其中的数据做任何限制、过滤、或者假设，数据在写入时是什么样的，它被读取时就是什么样。

这也是我们将SDS的buf属性称为字节数组的原因——Redis不是用这个数组来保存字符，而是用它来保存一系列二进制数据。

兼容部分C字符串函数

虽然SDS的API都是二进制安全的，但它们一样遵循C字符串以空字符结尾的惯例：这些API总会将SDS保存的数据的末尾设置为空字符，并且总会在为buf数组分配空间时多分配一个字节来容纳这个空字符，这是为了让那些保存文本数据的SDS可以重用一部分＜string.h＞库定义的函数。

总结

C字符串	SDS
获取字符串长度的复杂度为O(N)	获取字符串长度的复杂度为O(1)
API是不安全的可能会导致缓存区的溢出	API是安全的不会造成缓冲区的溢出
修改字符串长度N此必然需要执行N此内存重新分配	修改字符串长度N次最多需要N此内存的分配
只保留文本数据	可以保留文本或二进制数据
可以使用到所有的<stdio.h>库中的函数	使用一部分库中函数

所以综上所述，我们讲讲述了对于SDS的基本结构，和进行了与C字符类型的全方面的对比，以后在遇到他也就不用再惧怕了。

Maycope

发布了26 篇原创文章 · 获赞 5 · 访问量 711

私信关注