redis sds结构设计学习

---

前言

最近刷技术文章时，收获了redis字符串sds结构原理，在这里记录一下。

一、sds是什么？

我们知道redis是用C写的，但它却没有完全直接使用C的字符串，而是自己又重新构建了一个叫简单动态字符串SDS（simple dynamic string）的抽象类型。

二、sds与普通字符串对比

获取字符串长度的时间复杂度

C 字符串本身是不记录自身的长度信息的，当我们需要获取 C 字符串的长度时就需要遍历整个字符串计数，直到遇到空字符为止，这个操作的时间复杂度是 O(N)。

SDS 和 C 字符串并不同，当你需要获取长度信息的时候直接访问 SDS 的 len 属性即可，这个操作的时间复杂度是 O(1)。设置和更新 len 属性都由 SDS 的 API 在执行时自动完成。

举个例子：工作中使用redis，经常会通过STRLEN命令得到一个字符串的长度，在SDS结构中len属性记录了字符串的长度，所以我们获取一个字符串长度直接取len的值，复杂度是O(1)。

而如果用C字符串，在获取一个字符串长度时，需对整个字符串进行遍历，直至遍历到空格符结束（C中遇到空格符代表一个完整字符串），此时的复杂度是O(N)。

在高并发场景下频繁遍历字符串，获取字符串的长度很有可能成为redis的性能瓶颈，所以SDS性能更好一些。

缓冲区溢出

上边提到C字符串是不记录自身长度的，相邻的两个字符串存储的方式可能如下图，为字符串分配了合适的内存空间。

如果此时我想把“程序员内点事”改成“程序员内点事123”，可之前分配的内存只有6个字节，修改后的字符串需要9个字节才能放下啊，怎么搞？

没办法只能侵占相邻字符串的空间，自身数据溢出导致其他字符串的内容被修改。
而SDS很好的规避了这点，当我们需要修改数据时，首先会检查当前SDS空间len是否满足，不满足则自动扩容空间至修改所需的大小，然后再执行修改,如下图所示。

不过有个特殊的地方，在把“程序员内点事”的6个字节扩容到“程序员内点事123”9个字节后，发现free属性的值变成了扩容后字符串的总长度，这就涉及到下边要说的内存重分配策略了。

内存分配次数

C字符串长度是一定的，所以每次在增长或者缩短字符串时，都要做内存的重分配，而内存重分配算法通常又是一个比较耗时的操作，如果程序不经常修改字符串还是可以接受的。

但很不幸，redis作为一个数据库，数据肯定会被频繁修改，如果每次修改都要执行一次内存重分配，那么就会严重影响性能。

SDS通过两种内存重分配策略，很好的解决了字符串在增长和缩短时的内存分配问题。

1.空间预分配

空间预分配策略用于优化SDS字符串增长操作，当修改字符串并需对SDS的空间进行扩展时，不仅会为SDS分配修改所必要的空间，还会为SDS分配额外的未使用空间free，下次再修改就先检查未使用空间free是否满足，满足则不用在扩展空间。

通过空间预分配策略，redis可以有效的减少字符串连续增长操作，所产生的内存重分配次数。

额外分配未使用空间free的规则：
如果对 SDS 字符串修改后，len 值小于 1M，那么此时额外分配未使用空间 free 的大小与len相等。如果对 SDS 字符串修改后，len 值大于等于 1M，那么此时额外分配未使用空间 free 的大小为1M。

2.惰性空间释放

惰性空间释放策略则用于优化SDS字符串缩短操作，当缩短SDS字符串后，并不会立即执行内存重分配来回收多余的空间，而是用free属性将这些空间记录下来，如果后续有增长操作，则可直接使用。

二进制安全与多样性

因为 C 字符串是以空字符串来判断结尾的，那么存取的 C 字符串里面不能包含空字符，那么程序会误判断提前结束，这使得 C 字符串只能保存文本数据，不能保存图片、音频、视频和压缩文件这样的二进制数据。
虽然数据库一般都保存文本数据，但是为了让数据库满足各种场景，SDS 的 API 是二进制安全的，数据在写入时是怎么样的，读取的时候就是怎么样的，并不会对数据进行处理，SDS 不会就出现像 C 字符串一样误判，是因为 SDS 是依靠 len 属性的值判断字符串是否结束而不是空字符。

总结

学习到的东西记录一下。

文章引用： 阿里面试这样问：redis 为什么把简单的字符串设计成 SDS？
文章引用： 【Redis 数据结构】为什么 Redis 要用 SDS？