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）