面试题：Redis的SDS和C中字符串相比有什么优势？

众所周知，Redis 是现在最火的 nosql 系统。面试必备，面试必会。今年情况特别特殊，困难重重，前段时间群里刮起了一阵学习 Redis 源码的风。刚好最近有网友面试遇到了，Redis 的 SDS 和 C 中字符串相比有什么优势？本文来简单的说一说。

在 C 语言中使用 N + 1 长度的字符数组来表示字符串，尾部使用’/0’作为结尾标志，对于此种实现无法满足 Redis 对于安全性、效率、丰富的功能的要求，因此 Redis 单独封装了 SDS 简单动态字符串结构。

在理解 SDS 的优势之前需要先看下 SDS 的实现细节，找了 github 最新的 src/sds.h 的定义看下：

typedef char *sds;

/*这个用不到 忽略即可*/
struct __attribute__ ((__packed__)) sdshdr5 {
    unsigned char flags; /* 3 lsb of type, and 5 msb of string length */
    char buf[];
};

/*不同长度的header 8 16 32 64共4种 都给出了四个成员
len：当前使用的空间大小；alloc去掉header和结尾空字符的最大空间大小
flags:8位的标记 下面关于SDS_TYPE_x的宏定义只有5种 3bit足够了 5bit没有用
buf:这个跟C语言中的字符数组是一样的，从typedef char* sds可以知道就是这样的。
buf的最大长度是2^n 其中n为sdshdr的类型，如当选择sdshdr16，buf_max=2^16。
*/
struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; /* used */
    uint8_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr16 {
    uint16_t len; /* used */
    uint16_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr32 {
    uint32_t len; /* used */
    uint32_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr64 {
    uint64_t len; /* used */
    uint64_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};

#define SDS_TYPE_5  0
#define SDS_TYPE_8  1
#define SDS_TYPE_16 2
#define SDS_TYPE_32 3
#define SDS_TYPE_64 4
#define SDS_TYPE_MASK 7
#define SDS_TYPE_BITS 3

看了前面的定义，笔者画了个图：

面试题：Redis的SDS和C中字符串相比有什么优势？ — Redis 简单动态数组 SDS 结构

从图中可以知道 sds 本质分为三部分：header、buf、null 结尾符，其中 header 可以认为是整个 sds 的指引部分，给定了使用的空间大小、最大分配大小等信息，再用一张网上的图来清晰看下 sdshdr8 的实例：

在 sds.h/sds.c 源码中可清楚地看到sds完整的实现细节，本文就不展开了要不然篇幅就过长了，快速进入主题说下 sds 的优势：