redis 原理系列之–字符串存储的实现原理（1）

redis功能强大，几乎已经成了现代大中型服务必备的缓存技术了。除了十分给力的缓存功能，redis当做消息队列，数据库也有着不错的表现。

我们都知道，redis 有五种数据类型，string，list， hash， set 和zset。其中最基本的，同时也是最常用的就是string了。本文就来谈谈 redis内部，string 的实现原理：SDS（simple dynamic string）。

struct sdshdr {    // buf 中已占用空间的长度
    int len;    // buf 中剩余可用空间的长度
    int free;    // 数据空间
    char buf[];
};

图示如下：

简单解释一下： buf是一个字节数组，是用来放具体数据的。其长度是按一定策略伸缩的，具体解释在下面。 len 表示buf 中已经使用掉的长度，free表示 buf中尚未使用的长度。
buf内 sds 的字符串，总是以空字符结尾，这一点同c字符串一致。因此sds 可以直接重用一部分c字符串函数库的函数。

1，O(1) 获取字符串长度

2，杜绝缓冲区溢出导致的内存问题

此时需要给s1 追加一个“boy”，如果是C字符串，忘记了在追加之前先给s1 分配空间，此时追加将导致 s2的值被意外的修改。而使用 sds则不会有这个问题。因为其封装好的函数，会在追加数据之前先检查空间是否够用，如果不够用就扩容。

3，通过空间预分配和空间惰性释放减少内存分配问题

当给sds的值追加一个字符串，而当前的剩余空间不够时，就会触发sds的扩容机制。扩容采用了空间预分配的优化策略，即分配空间的时候：如果sds 值大小< 1M ,则增加一倍；反之如果>1M , 则当前空间加1M作为新的空间。
当sds的字符窜缩短了，sds的buf内会多出来一些空间，这个空间并不会马上被回收，而是暂时留着以防再用的时候进行多余的内存分配。这个是惰性空间释放的策略

4，二进制安全

c字符串必须符合某种编码（例如ASCII），且不能包含空字符。这些限制使得 c字符窜不能保存图片，音频等二进制文件。而sds的api 都是二进制安全的，其所有api 都会以处理二进制的方式来处理buf内的数据，所以不会有任何的限制。

sds 其实就是字符串数组的一个封装，但是由于考虑了多种场景，作者给它适配了多个高效、优雅的接口，使得 sds成为了一个存储字符串的优秀设计。使得sds成为一个独立的、可提供高效优质服务的基础实体。

我们在设计一些偏底层的数据结构、对象、甚至是数据库表的时候，可以参考sds的设计，从中寻找一些启发。

参考：《Redis 设计与实现》黄健宏

有收获就点个赞吧~