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

前言
字符串对象
- 为什么Redis的字符串对象是二进制安全的
- SDS空间分配策略
- - 空间预分配
  - 惰性空间释放
- SDS和C语言字符串区别
SDS的底层存储对象
- dictEntry对象
- redisObject
- - 对象类型type
  - 编码encoding
  - - embstr编码为什么从39位修改为44位
    - embstr编码和raw编码的区别
  - 最近访问时间lru
  - 引用计数refcount
总结

前言

上一篇我们介绍了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，即SDSunion {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(简单动态字符串)实现原理分析相关推荐

Redis源码阅读笔记（1）——简单动态字符串sds实现原理
首先,sds即simple dynamic string,redis实现这个的时候使用了一个技巧,并且C99将其收录为标准,即柔性数组成员(flexible array member),参考资料见这里 ...
Redis之简单动态字符串sds
转载:https://segmentfault.com/a/1190000012262739 redis在处理字符串的时候没有直接使用以'\0'结尾的C语言字符串,而是封装了一下C语言字符串并命名为s ...
【Redis】Redis数据结构与对象（一）简单动态字符串（SDS）
目录 1. C字符串与SDS 2. SDS的定义 3. SDS与C字符串的区别 3.1 常数复杂度获取字符串长度 3.2 杜绝缓冲区溢出 3.3 减少修改字符串时带来的内存重分配次数 3.3.1 空间 ...
Redis内部数据结构详解之简单动态字符串(sds)
本文所引用的源码全部来自Redis2.8.2版本. Redis中简单动态字符串sds数据结构与API相关文件是:sds.h, sds.c. 转载请注明,本文出自:http://blog.csdn.ne ...
Redis数据结构之简单动态字符串SDS
Redis的底层数据结构非常多,其中包括SDS.ZipList.SkipList.LinkedList.HashTable.Intset等.如果你对Redis的理解还只停留在get.set的水平的话, ...
【Redis笔记】简单动态字符串（SDS）
简单动态字符串:simple dynamic string ,SDS,用作Redis默认字符串表示. 在Redis中,C字符串只会作为字符串字面量用在一些无须对字符串值进行修改的地方. 在Redis需 ...
Redis源码初探（1）简单动态字符串SDS
前言现在面试可太卷了,Redis基本是必问的知识点,为了在秋招中卷过其他人(虽然我未必参加秋招),本菜鸡决定从源码层面再次学习Redis,不过鉴于本菜鸡水平有限,且没有c语言基础,本文不会对源码过于 ...
深入剖析Redis系列(五) - Redis数据结构之字符串
前言字符串类型是 Redis 最基础的数据结构.字符串类型的值实际可以是字符串(简单和复杂的字符串,例如 JSON.XML).数字(整数.浮点数),甚至是二进制(图片.音频.视频),但 ...
Redis数据结构——简单动态字符串-SDS
1.SDS简介: redis没有使用C语言传统的字符串表示(以空字符结尾的字符数组),而是自己构建了一种名为简单动态字符串(SDS)的抽象类型,并将SDS用作redis的默认字符串表示. 除了用来保存 ...

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