字符串对象的底层存储结构-简单动态字符串(Simple dynamic string)简称SDS

本文链接：https://blog.youkuaiyun.com/qq_40277163/article/details/124878774

字符串对象

Redis是使用C语言进行编写的，而C语言中的字符串是二进制不安全的，所以Redis就没有直接使用C语言的字符串，而是自己编写了一个新的数据结构来表示字符串，这种数据结构称之为：简单动态字符串(Simple dynamic string)，简称SDS。

为什么Redis的字符串对象是二进制安全的

在C语言中，字符串采用的是一个char数组(柔性数组)来存储字符串，而且字符串必须要以一个空字符串’\0’来结尾。字符串并不记录长度，所以如果想要获取一个字符串的长度就必须遍历整个字符串，直到遇到’\0’为止(’\0’不会计入长度)，时间复杂度为O(n)。

正因为C语言中是以空字符’\0’来识别是否到了字符串末尾，因此其只能保存文本数据，不能保存图片，音频，视频和压缩文件等二进制数据，所以就是二进制不安全的。

Redis中为了实现二进制安全的字符串，对原有的C语言中的字符串做了改进。如下所示就是一个SDS字符串的结构：

struct sdshdr{
  int len;//记录buf数组已使用的长度，即SDS的长度(不包含末尾的'\0')
  int free;//记录buf数组中未使用的长度
  char buf[];//字节数组，用来保存字符串
}

经过改进之后，在Redis中如果想要获取SDS的长度不用去遍历buf数组了，直接读取len属性就可以得到长度，时间复杂度一下就变成了O(1)，效率大大提升，而且因为判断字符串长度不再依赖空字符’\0’，所以其能存储图片，音频，视频和压缩文件等二进制数据。
PS：不过需要注意的是，SDS依然遵循了C语言字符串以’\0’结尾的惯例，这么做是为了方便复用C语言字符串原生的一些API。

在Redis 3.2之后的版本，Redis对sds又做了优化，按照存储空间的大小拆分成为了sdshdr5、sdshdr8、sdshdr16、sdshdr32、sdshdr64，分别用来存储大小为：32字节(25),256字节(28)，64KB(216),4GB大小(232)以及264大小的字符串（因为目前版本key和value都限制了只能使用512MB，所以sdshdr64暂时并未使用到）。看源码的注释，对value而言sdshdr5并不会被使用到，但是key会被使用到，因为sdshdr5和其他类型也不一样，其并没有存储未使用空间，所以我的猜测是比较适用于使用大小固定的场景(比如key值)：
在这里插入图片描述
任意选择一种类型，其具体含义代表如下：

struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; //已使用空间大小
    uint8_t alloc; //总共申请的空间大小(包括未使用的)
    unsigned char flags; //用来表示当前sds类型是sdshdr8还是sdshdr16等
    char buf[]; //真实存储字符串的字节数组
};

空间预分配

空间预分配指的是当我们通过API对SDS进行扩展空间的时候，假如未使用空间不够用，那么程序不仅会为SDS分配必须要的空间，还会额外分配未使用空间，未使用空间分配大小主要有两种情况：

假如扩大长度之后的len属性小于等于1MB(即1024*1024)，那么同时就会分配和len属性一样大小的未使用空间(此时buf数组已使用空间=未使用空间)。
假如扩大长度之后的len属性大于1MB，那么就会分配1MB未使用空间大小。
执行空间预分配策略的好处是提前分配了未使用空间备用后，就不需要每次增大字符串都需要分配空间，减小了内存重分配的次数。