Redis字符串对象之SDS实现原理分析

前言
字符串对象
SDS的底层存储对象
总结

前言

上一篇我们介绍了Redis中支持的9种数据类型及其简单的使用，但是也仅仅只限于使用，从这一篇开始，我们会逐步分析每一种数据类型其底层的存储数据结构,而本文会介绍最重要也是使用最频繁的字符串对象的底层存储结构。

字符串对象

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字节(2⁵),256字节(2⁸)，64KB(2¹⁶),4GB大小(2³²)以及2⁶⁴大小的字符串（因为目前版本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[]; //真实存储字符串的字节数组
};

SDS空间分配策略

C语言中因为字符串内部没有记录长度，所以如果扩充字符串的时候非常容易造成缓冲区溢出(buffer overflow)。

请看下面这张图，假设下面这张图就是内存里面的连续空间，可以很明显的看到，此时lonely和Redis两个字符串之间只有两个空位，那么这时候如果我们要将lonely字符串修改为lonelyWolf，那么就需要4个空间，这时候下面这个空间是放不下的，必须要重新申请空间，但是假如说程序员忘了申请空间，或者说申请了空间但是还是不够，那么就会出现后面的Redis字符串中的Re被覆盖了。
在这里插入图片描述
同样的，假如要缩小字符串的长度，那么也需要重新申请释放内存，否则，字符串一直占据着未使用的空间，会造成内存泄露。

所以说C语言避免缓存区溢出和内存泄露完全依赖于人为，很难把控，但是使用SDS就不会出现这两个问题，因为当我们操作SDS时，其内部会自动执行空间分配策略，无需人为操作，从而杜绝了上述两种情况的出现。

空间预分配

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

1、假如扩大长度之后的len属性小于等于1MB(即1024*1024)，那么同时就会分配和len属性一样大小的未使用空间(此时buf数组已使用空间=未使用空间)。
2、假如扩大长度之后的len属性大于1MB，那么就会分配1MB未使用空间大小。

执行空间预分配策略的好处是提前分配了未使用空间备用后，就不需要每次增大字符串都需要分配空间，减小了内存重分配的次数。

惰性空间释放

惰性空间释放指的是当我们需要通过API减小SDS长度的时候，程序并不会立即释放未使用的空间，而只是更新free属性的值，这样空间就可以留给下一次使用。而为了防止出现内存溢出的情况，SDS单独提供给了API让我们在有需要的时候去真正的释放内存。

SDS和C语言字符串区别

现在我们总结一下SDS和C语言中实现的字符串的区别

C字符串	SDS
只能保存文本类不含空字符串’\0’数据	可以保存文本或者二进制数据，允许包含空字符串’\0’
获取字符串长度的复杂度为O(n)	获取字符串长度的复杂度为O(1)
操作字符串可能会造成缓冲区溢出	不会出现缓冲区溢出情况
修改字符串长度N次，必然需要N次内存重分配	修改字符串长度N次，最多需要N次内存重分配
可以使用C字符串相关的所有函数	可以使用C字符串相关的部分函数

SDS的底层存储对象

上面讲了这么多，可能很多人会以为Redis底层就是直接用了SDS数据结构来存储，然而实际上并不是，我们回想一下Redis的全称是远程字典服务，所以在Redis中所有的数据类型都是将对应的数据结构再进行了一次包装，创建了一个字典对象来存储的。

dictEntry对象

每次创建一个key-value键值对，Redis都会创建两个对象，一个是键对象，一个是值对象，而且在Redis中，任何一个对象总是被包装成redisObject对象，并同时将键对象和值对象通过dictEntry对象进行封装，如下就是一个dictEntry对象（源码dict.h内）：

typedef struct dictEntry {
    
    
    void *key;//指向key，即SDS
    union {
    
    
        void *val;//执行value，即5大常用数据类型
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    struct dictEntry *next;//指向下一个key-value键值对(哈希值相同的键值对会形成一个链表，这种方式可以解决哈希冲突问题)
} dictEntry;

当我们执行如下命令：

set name lonely_wolf

会得到这样的一个对象(省略了一些无关的属性）：
在这里插入图片描述

redisObject

上面的redisObject就是我们的值对象（实际上key也是一个redisObject对象）如下就是一个redisObject对象的数据结构定义(源码server.h内)：

typedef struct redisObject {
    
    
    unsigned type:4;//对象类型（4位=0.5字节）
    unsigned encoding:4;//编码（4位=0.5字节）
    unsigned lru:LRU_BITS;//记录对象最后一次被应用程序访问的时间（24位=3字节）
    int refcount;//引用计数。等于0时表示可以被垃圾回收（32位=4字节）
    void *ptr;//指向底层实际的数据存储结构，如：SDS等(8字节)
} robj;

所以，最终我们可以把上面的图简化为如下图所示([x]会根据长度选择为合适的值)：
在这里插入图片描述

对象类型type

对象类型即redisObject中的type属性，主要分为以下5种：

类型属性	描述	type命令返回值
REDIS_STRING	字符串对象	string
REDIS_LIST	列表对象	list
REDIS_HASH	哈希对象	hash
REDIS_SET	集合对象	set
REDIS_ZSET	有序集合对象	zset

可以看到，这就是对应了我们5种常用的基本数据类型。

编码encoding

编码即redisObject中的encoding属性。我们可以使用命令 object encoding 来查看当前对象的编码。
在这里插入图片描述
从上图也可以看到，在字符串对象中，主要有3种编码类型，如下表所示：

编码属性	描述	object encoding命令返回值
OBJ_ENCODING_INT	使用整数的字符串对象	int
OBJ_ENCODING_EMBSTR	使用embstr编码的SDS实现的字符串对象	embstr
OBJ_ENCODING_RAW	使用SDS实现的字符串对象	raw

int编码
当我们用字符串对象存储的是整型，且能用8个字节的long类型进行表示（即2⁶³-1），则Redis会选择使用int编码来存储，而且此时redisObject对象中的ptr指针直接替换为long类型。
embstr编码
当字符串对象中存储的是字符串，且长度小于44(3.2版本之前是39)时，Redis会选择使用embstr编码来存储。
raw编码
当字符串对象中存储的是字符串，且长度大于44时，Redis会选择使用raw编码来存储。

embstr编码为什么从39位修改为44位

embstr编码中，redisObject和SDS是连续的一块内存空间，这块内存空间Redis限制为了64个字节，而redisObject占了16字节，Redis3.2版本之前的sds占了8个字节，再加上字符串末尾’\0’占用了1个字节，所以：64-16-8-1=39字节。

Redis3.2之后sds做了优化，对于embstr编码会采用sdshdr8来存储，而sdshdr8占用的空间只有24位：3字节(len+alloc+flag)+1字节(’\0’字符)，所以最后就剩下了：64-16-3-1=44字节。

embstr编码和raw编码的区别

embstr编码是一种优化的存储方式，其在申请空间的时候使得redisObject和SDS两个对象是一个连续空间，所以只需要申请1次空间（同样的，释放内存也只需要1次），而raw编码因为redisObject和SDS两个对象的空间是不连续的，所以使用的时候需要2次申请空间（同样的，释放内存也需要2次）。但是使用embstr编码时，假如需要修改字符串，那么因为redisObject和SDS是在一起的，所以两个对象都需要重新申请空间，为了避免这种情况发生，embstr编码的字符串是只读的，不允许修改。

上图中的示例我们看到，对一个embstr编码的字符串对象进行append操作时，长度还没有达到45，但是编码已经被修改为raw了，这就是因为embstr编码是只读的，如果需要对其修改，Redis内部会将其修改为raw编码之后再操作。同样的，如果是操作int编码的字符串之后，导致long类型无法存储时(int类型不再是整数或者长度超过2⁶³-1时)，也会将int编码修改为raw编码。

PS：需要注意的是，编码一旦升级(int–>enmstr–>raw)，即使后期再把字符串修改为符合原内存编码的存储格式时，编码也不会回退。

最近访问时间lru

这个属性记录了对象最后一次被访问的时间，可以通过命令object idletime得到当前对象的空闲时间，即：当前时间-lru时间。
在这里插入图片描述
需要注意的是 object idletime 命令本身不会记录到lru属性。

当我们开启了maxmemory时，而且回收内存算法属性maxmemory-policy配置为volatile-lru或者allkeys-lru时候，当达到maxmemory设定值时，空闲时间最长的key会被优先回收。

maxmemory 512MB  #不带单位则默认是字节
maxmemory-policy volatile-lru

引用计数refcount

C语言本身并没有提供内存回收机制，所以Redis自己实现了一种简单的引用计数法来进行垃圾回收，简单来说就是当前对象被引用1次，计数就+1，当refcount等于0时表示当前对象没有任何引用，可以被垃圾回收。想要详细了解垃圾回收算法的，可以点击这里。

总结

本文主要介绍了Redis中五种常用类型中最常用的一种字符串数据对象进行了分析，其底层采用了SDS来存储，并进一步分析了SDS是如何被包装以及其内存分配策略和空间释放策略，及其编码类型等，在文中，我们也将其和C语言的字符串进行了对比，进一步分析了为什么Redis最终选择使用SDS来替换C语言中的字符串。

下一篇，将会介绍5种常用数据类型中的列表类型底层存储结构及其原理分析。

请关注我，和孤狼一起学习进步。

【Redis系列2】Redis字符串对象之SDS(简单动态字符串)实现原理分析