2021开工第一天，就有小伙伴私信我，还给我分享了一道他面阿里的redis题（这家伙绝比已经拿到年终奖了），我看了以后觉得挺有意思，题目很简单，是那种典型的似懂非懂，常常容易被大家忽略的问题。这里整理出来分享一下，顺便自己巩固一下基础，希望对正在面试和想要面试的兄弟有点帮助。
题目大致是这样的
面试官：了解redis的String数据结构底层实现嘛?
铁子：当然知道，是基于SDS实现的
面试官：redis是用C语言开发的，那为啥不直接用C的字符串，还单独设计SDS这样的结构呢?
铁子：·····
其实看得出面试官是想看看，铁子是只停留在redis的使用层面，还是对底层数据结构有过更深入的研究，面试嘛都爱这样问大家都懂得。
我们知道redis是用C写的，但它却没有完全直接使用C的字符串，而是自己又重新构建了一个叫简单动态字符串SDS（simple dynamic string）的抽象类型。
redis也支持使用C语言的传统字符串，只不过会用在一些不需要对字符串修改的地方，比如静态的字符输出。
而我们开发中使用redis，往往会经常性的修改字符串的值，这个时候就会用SDS来表示字符串的值了。有一点值得注意：在redis数据库中，key-value键值对含有字符串值的，都是由SDS来实现的。
比如：在redis执行一个最简单的set命令，这时redis会新建一个键值对。
127.0.0.1:6379> set xiaofu "程序员内点事"此时键值对的key和value都是一个字符串对象，而对象的底层实现分别是两个保存着字符串xiaofu和程序员内点事的SDS结构。
再比如：我向一个列表中压入数据，redis 又会新建一个键值对。
127.0.0.1:6379> lpush xiaofu "程序员内点事" "程序员小富"这时候键值对的键和上边一样，还是一个由SDS实现的字符串对象，键值对的值是一个包含两个字符串对象的列表对象了，而这两个对象的底层也是由SDS实现。
SDS结构一个SDS值的数据结构，主要由len、free、buf[]这三个属性组成。
struct sdshdr{ int free; // buf[]数组未使用字节的数量 int len; // buf[]数组所保存的字符串的长度 char buf[]; // 保存字符串的数组 }其中buf[]为实际保存字符串的char类型数组；free表示buf[]数组未使用字节的数量；len表示buf[]数组所保存的字符串的长度。
例如上图表示的是buf[]保存长度为6个字节的字符串，未使用的字节数free为0，但是眼尖的同学会发现这明明是7个字符，还有一个"\0"啊？
上边提到过SDS没有完全直接使用C的字符串，还是沿用了一些C特性的，比如遵循C的字符串以空格符结尾的规则，这样还可以使用一部分C字符串的函数。而对于SDS来说，空字符串占用的一字节是不计算在len属性里的，会为他分配额外的空间。
简单了解SDS结构后，下边我们来看看SDS相比于C字符串有哪些优点。
效率高举个例子：工作中使用redis，经常会通过STRLEN命令得到一个字符串的长度，在SDS结构中len属性记录了字符串的长度，所以我们获取一个字符串长度直接取len的值，复杂度是O(1)。
而如果用C字符串，在获取一个字符串长度时，需对整个字符串进行遍历，直至遍历到空格符结束（C中遇到空格符代表一个完整字符串），此时的复杂度是O(N)。
在高并发场景下频繁遍历字符串，获取字符串的长度很有可能成为redis的性能瓶颈，所以SDS性能更好一些。
数据溢出上边提到C字符串是不记录自身长度的，相邻的两个字符串存储的方式可能如下图，为字符串分配了合适的内存空间。
如果此时我想把“程序员内点事”改成“程序员内点事123”，可之前分配的内存只有6个字节，修改后的字符串需要9个字节才能放下啊，怎么搞？
没办法只能侵占相邻字符串的空间，自身数据溢出导致其他字符串的内容被修改。
而SDS很好的规避了这点，当我们需要修改数据时，首先会检查当前SDS空间len是否满足，不满足则自动扩容空间至修改所需的大小，然后再执行修改,如下图所示。
