struct sdshdr{
int len;//记录buf数组已使用的长度，即SDS的长度(不包含末尾的’\0’)
int free;//记录buf数组中未使用的长度
char buf[];//字节数组，用来保存字符串
}经过改进之后，如果想要获取 sds 的长度不用去遍历 buf 数组了，直接读取 len 属性就可以得到长度，时间复杂度一下就变成了 O(1) ，而且因为判断字符串长度不再依赖空字符 \0 ，所以其能存储图片，音频，视频和压缩文件等二进制数据，不用担心读取到的字符串不完整。
需要注意的是， sds 依然遵循了 C 语言字符串以 \0 结尾的惯例，这么做是为了方便复用 C语言字符串原生的一些API，换言之就是在 C 语言中会以碰到的第一个 \0 字符当做当前字符串对象的结尾，所以如果一些二进制数据就会可能出现读取字符串不完整的现象，而 sds 会以长度来判断是否到字符串末尾。
在 Redis 3.2 之后的版本， Redis 对 sds 又做了优化，按照存储空间的大小拆分成为了 sdshdr5 、 sdshdr8 、 sdshdr16 、 sdshdr32 、 sdshdr64 ，分别用来存储大小为： 32 字节（ 2 的 5 次方）, 256 字节（ 2 的 8 次方）， 64KB （ 2 的 16 次方）， 4GB 大小（ 2 的 32 次方）以及 2 的 64 次方大小的字符串（因为目前版本key 和 value 都限制了最大 512MB，所以 sdshdr64 暂时并未使用到）。 sdshdr5只被应用在了 Redis 中的 key 中， value 中不会被使用到，因为 sdshdr5 和其他类型也不一样，其并没有存储未使用空间，所以其是比较适用于使用大小固定的场景（比如 key 值）：
任意选择其中一种数据类型，其字段代表含义如下：
struct attribute ((packed)) sdshdr8 {
uint8_t len; //已使用空间大小
uint8_t alloc; //总共申请的空间大小(包括未使用的)
unsigned char flags; //用来表示当前sds类型是sdshdr8还是sdshdr16等
char buf[]; //真实存储字符串的字节数组
};可以看到相比较于 Redis 3.2 版本之前的 sds 主要是修改了 free 属性然后新增了一个flags 标记来区分当前的 sds 类型。
sds 空间分配策略
==============
C 语言中因为字符串内部没有记录长度，所以如果扩充字符串的时候非常容易造成 缓冲区溢出（buffer overflow） 。
请看下面这张图，假设下面这张图就是内存里面的连续空间，可以很明显的看到，此时 wolf和 Redis 两个字符串之间只有三个空位，那么这时候如果我们要将 wolf 字符串修改为 lonelyWolf ，那么就需要 6 个空间，这时候下面这个空间是放不下的，所以必须要重新申请空间，但是假如说程序员忘了申请空间，或者说申请到的空间依然不够，那么就会出现后面的 Redis 字符串中的 Red 被覆盖了：
同样的，假如要缩小字符串的长度，那么也需要重新申请释放内存。否则，字符串一直占据着未使用的空间，会造成 内存泄露 。
C 语言避免缓存区溢出和内存泄露完全依赖于人为，很难把控，但是使用 sds 就不会出现这两个问题，因为当我们操作 sds 时，其内部会自动执行 空间分配策略 ，从而避免了上述两种情况的出现。
空间预分配
=========
空间预分配指的是当我们通过 api 对 sds 进行扩展空间的时候，假如未使用空间不够用，那么程序不仅会为 sds 分配必须要的空间，还会额外分配未使用空间，未使用空间分配大小主要有两种情况：
- 1、假如扩大长度之后的 len 属性小于等于 1MB （即 1024 * 1024），那么就会同时分配和 len 属性一样大小的未使用空间（ 此时 buf 数组已使用空间 = 未使用空间 ）。
- 2、假如扩大长度之后的 len 属性大于 1MB ，那么就会分配 1MB 未使用空间大小。
执行空间预分配策略的好处是 提前分配了未使用空间备用后，就不需要每次增大字符串都需要分配空间，减少了内存重分配的次数。
惰性空间释放
==========
惰性空间释放指的是当我们需要通过 api 减小 sds 长度的时候，程序并不会立即释放未使用的空间，而只是更新 free 属性的值，这样空间就可以留给下一次使用。而为了防止出现内存溢出的情况， sds 单独提供给了 api 让我们在有需要的时候去真正地释放内存。
sds 和 C 语言字符串区别
===================
下面表格中列举了 Redis 中的 sds 和 C 语言中实现的字符串的区别：
sds 是如何被存储的
===============
在 Redis 中所有的数据类型都是将对应的数据结构再进行了再一次包装，创建了一个字典对象来存储的， sds 也不例外。每次创建一个 key-value 键值对， Redis 都会创建两个对象，一个是键对象，一个是值对象。而且需要注意的是 在 Redis 中，值对象并不是直接存储，而是被包装成 redisObject 对象 ，并同时将键对象和值对象通过dictEntry 对象进行封装，如下就是一个 dictEntry 对象：
typedef struct dictEntry {
void *key;//指向key，即sds
union {
void *val;//指向value
uint64_t u64;
int64_t s64;
double d;
} v;
struct dictEntry *next;//指向下一个key-value键值对(哈希值相同的键值对会形成一个链表，从而解决哈希冲突问题)
} dictEntry;
redisObject 对象的定义为：
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;当我们在 Redis 客户端中执行命令 set name lonely_wolf ，就会得到下图所示的一个结构（省略了部分属性）：
看到这个图想必大家会有疑问，这里面的 type 和 encoding 到底是什么呢？其实这两个属性非常关键， Redis 就是通过这两个属性来识别当前的 value 到底属于哪一种基本数据类型，以及当前数据类型的底层采用了何种数据结构进行存储。
type 属性
===========
type 属性表示对象类型，其对应了 Redis 当中的 5 种基本数据类型：
可以看到，这就是对应了我们 5 种常用的基本数据类型。
encoding 属性
===============
Redis 当中每种数据类型都是经过特别设计的，相信大家看完这个系列也会体会到Redis 设计的精妙之处。字符串在我们眼里是非常简单的一种数据结构了，但是Redis 却把它优化到了极致，为了节省空间，其通过编码的方式定义了三种不同的存储方式：
- int 编码
当我们用字符串对象存储的是整型，且能用 8 个字节的 long 类型进行表示（即 2 的 63 次方减 1 ），则 Redis 会选择使用 int 编码来存储，此时redisObject 对象中的 ptr 指针直接替换为 long 类型。我们想想 8 个字节如果用字符串来存储只能存 8 位，也就是千万级别的数字，远远达不到 2 的 63次方减 1 这个级别，所以如果都是数字，用 long 类型会更节省空间。
- embstr 编码
当字符串对象中存储的是字符串，且长度小于 44 （ Redis 3.2 版本之前是 39）时， Redis 会选择使用 embstr 编码来存储。
- raw 编码
当字符串对象中存储的是字符串，且长度大于 44 时， Redis 会选择使用 raw编码来存储。
讲了半天理论，接下来让我们一起来验证下这些结论，依次输入 set name lonely_wolf ， type name ， object encoding name 命令：
可以发现当前的数据类型就是 string ，普通字符串因为长度小于 44 ，所以采用的是embstr编码。
再依次输入： set num 1111111111 ， set address aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa （长度 44 ）， set address aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa （长度 45 ），分别查看类型和编码：
可以发现，当输入纯数字的时候，采用的是 int 编码，而字符串小于等于 44 则为embstr ，大于 44 则为 raw 编码。
字符串对象中除了上面提到的纯整数和字符串，还可以存储浮点型类型，所以字符串对象可以存储以下三种类型：
- 字符串
- 整数
- 浮点数
