关于redis中SDS的细节

一、问题的产生
为什么redis速度快？因为他们有独特的数据结构，如String类型的SDS，那么SDS到底是什么样子的，这么设计有什么好处？

二、SDS结构
SDS是Simple Dynamic String的缩写。

struct sdshdr {
	// 记录buf中已使用的字节数，等于SDS中保存字符串的长度
	unsigned int len;
	// 记录buf中未使用的字节数
	unsigned int free;
	// 用于保存字符串
	char buf[];
}

buf的尾部自动追加一个‘\0’，且不会计算在SDS的len中，这是延续C字符串以空字符串结尾的惯例，方便SDS可以使用string.h库中的函数，如strlen。

三、数据优化
问题：在Redis3.x版本中，不同长度的字符串占用头部是相同的，但如果一字符串很短，则头部会占用更多空间，造成浪费。
解决思路：区分不同长度字符串，优化短字符串的数据结构。
方案：
把字符串区分为三种：
短字符串(长度小于32，即5bit)，len和free的长度用1字节即可；
长字符串，用2字节或者4字节；
超长字符串，用8字节。
用一个type字段为类型标识，但由于只有5种类型，所以用1byte的char类型0即可。

// 注意：sdshdr5从未被使用，Redis中只是访问flags。
struct __attribute__ ((__packed__)) sdshdr5 {
	// 这里就去掉了头部的len和alloc
	// 因为<32bit的字符串，即最长只有5位，刚好存进高5位，剩下的低3位作为类型
    unsigned char flags; /* 低3位存储类型, 高5位存储长度 */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; /* 已使用 */
    uint8_t alloc; /* 总长度，用1字节存储 */
    unsigned char flags; /* 低3位存储类型, 高5位预留 */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr16 {
    uint16_t len; /* 已使用 */
    uint16_t alloc; /* 总长度，用2字节存储 */
    unsigned char flags; /* 低3位存储类型, 高5位预留 */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr32 {
    uint32_t len; /* 已使用 */
    uint32_t alloc; /* 总长度，用4字节存储 */
    unsigned char flags; /* 低3位存储类型, 高5位预留 */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr64 {
    uint64_t len; /* 已使用 */
    uint64_t alloc; /* 总长度，用8字节存储 */
    unsigned char flags; /* 低3位存储类型, 高5位预留 */
    char buf[];
};

四、字节对齐
1、什么是字节对齐
内存空间是按字节划分的，理论上可以从任何起始地址访问任意类型的变量。但实际中在访问特定类型变量时经常在特定的内存地址访问，这就需要各种类型数据按照一定的规则在空间上排列，而不是顺序一个接一个地存放，这就是对齐。
2、对齐原因
各个硬件平台对存储空间的处理上有很大的不同。一些平台对某些特定类型的数据只能从某些特定地址开始存取。
比如有些平台每次读都是从偶地址开始，如果一个int型（假设为 32位）存放在偶地址开始的地方，那么一个读周期就可以读出，而如果存放在奇地址开始的地方，就可能会需要2个读周期，并进行拼凑才能得到数据，效率下降很多。
3、为什么Redis不对齐

SDS 的指针并不是指向 SDS 的起始位置（len位置），而是直接指向buf[]，使得 SDS 可以直接使用 C 语言string.h库中的某些函数，做到了兼容。
如果不进行对齐填充，那么在获取当前 SDS 的类型时则只需要后退一步即可，flagsPointer = ((unsigned char*)s)-1；
如果进行对齐填充，由于 Padding 的存在，我们在不同的系统中不知道退多少才能获得flags，并且我们也不能将 sds 的指针指向flags，这样就无法兼容 C 语言的函数，也不知道前进多少才能得到 buf[]。

五、二进制安全
问题：什么是二进制安全？
回答：通俗地讲，C语言中，用’0’表示字符串的结束，如果字符串本身就有’0’字符，字符串就会被截断，即非二进制安全；若通过某种机制，保证读写字符串时不损害其内容，则是二进制安全。
另外：C字符串中的字符除了末尾字符为’\0’外其他字符不能为空字符，否则会被认为是字符串结尾。这限制了C字符串只能保存文本数据，而不能保存二进制数据。而SDS使用len属性的值判断字符串是否结束，所以不会受’\0’的影响。

六、杜绝缓冲区溢出
问题：字符串的拼接操作是使用十分频繁的，在C语言开发中使用strcat方法拼接字符串到末尾。但由于C字符串不记录自身的长度，所似strcat方法会认为用户已经提前分配好足够的内存，而这个条件不成立，就会产生缓冲区溢出，会把其他数据覆盖掉。
解决方案：SDS与C字符串不同，它的自动扩容机制杜绝了缓冲区溢出的可能：当SDS修改时，会先检查 SDS 的空间是否满足修改所需的要求，不满足，则自动扩展空间至所需大小，然后执行修改操作。
自动扩容机制总结：

扩容阶段：
1、若 SDS 中剩余空闲空间 avail >新增内容的长度 addlen，则无需扩容；
2、若 SDS 中剩余空闲空间 avail <=新增内容的长度 addlen：
1)、若新增后总长度 len+addlen < 1MB，则按新长度的两倍扩容；
2)、若新增后总长度 len+addlen > 1MB，则按新长度加上 1MB 扩容。
内存分配阶段，需根据扩容后的长度选择对应的 SDS 类型：
1、若类型不变，则只需通过 s_realloc_usable扩大 buf 数组即可；
2、若类型变化，则需要为整个 SDS 重新分配内存，并将原来的 SDS 内容拷贝至新位置。

七、内存重分配次数优化
1、空间预分配策略
因为 SDS 的空间预分配策略， SDS 字符串在增长过程中不会频繁的进行空间分配。通过这种分配策略，SDS 将连续增长N次，最多重分配N次。
2、惰性空间释放机制
当SDS 字符串缩短时，并不会立即使用内存重分配来回收缩短后多出来的空间，而仅仅更新 SDS 的len属性，多出来的空间供将来使用。
3、释放SDS
为了优化性能，SDS 提供了不直接释放内存，而是通过重置len达到清空 SDS 目的的方法sdsclear。将 SDS 的len归零，而buf的空间并为真正被清空，新的数据可以复写，而不用重新申请内存。

void sdsclear(sds s) {
    sdssetlen(s, 0);// 设置len为0
    s[0] = '\0';//“清空”buf
}

若真正想清空 SDS 则可以调用sdsfree方法，底层通过调用s_free释放内存。

void sdsfree(sds s) {
    if (s == NULL) return;
    s_free((char*)s-sdsHdrSize(s[-1]));
}

八、其它
1、过期的字符串设置为永久
如果一个命令只是修改一个带生存时间的key的value，则生存时间被移除，即变为永久
如果一个命令用一个新key代替了旧key，生存时间不变
如：

127.0.0.1：6379> expire age 100
(integer) 1
127.0.0.1：6379> ttl age
(integer) 97
// 用set修改value后，过期时间变为永久
127.0.0.1：6379> set age 20
OK
127.0.0.1：6379> ttl age
(integer) -1
127.0.0.1：6379> expire age 100
(integer) 1
127.0.0.1：6379> ttl age
(integer) 98
// 用rename修改key值后，过期时间不变
127.0.0.1：6379> rename age age2
OK
127.0.0.1：6379> ttl age2
(integer) 87
// 用persist移除过期时间
127.0.0.1：6379> expire age 100
(integer) 1
127.0.0.1：6379> ttl age
(integer) 98
127.0.0.1：6379> persist age
(integer) 1
127.0.0.1：6379> ttl age
(integer) -1