Redis 数据结构 - Redis 的数据存储及 String 类型的实现

旧城等待， 2024-04-01 10:45 53阅读 0赞

#### ![f58b2b07b6dc45bb821923f87c5fcc64.jpeg][] ####

#### 1 引言 ####

Redis 作为基于内存的非关系型的 K-V 数据库。因读写响应快速、原子操作、提供了多种数据类型 String、List、Hash、Set、Sorted Set、在项目中有着广泛的使用，今天我们来探讨下下 Redis 的数据结构是如何实现的。

#### 2 数据存储 ####

2.1 RedisDB

Redis 将数据存储在 redisDb 中，默认 0~15 共 16 个 db。每个库都是独立的空间，不必担心 key 冲突问题，可通过 select 命令切换 db。集群模式使用 db0

typedef struct redisDb {
    dict *dict; /* The keyspace for this DB */
    dict *expires; /* Timeout of keys with a timeout set */
    ...
    } redisDb;

*  dict：数据库键空间，保存着数据库中的所有键值对
 *  expires：键的过期时间，字典的键为键，字典的值为过期事件 UNIX 时间戳

2.2 Redis 哈希表实现

**2.2.1 哈希字典 dict**

K-V 存储我们最先想到的就是 map，在 Redis 中通过 dict 实现，数据结构如下：

typedef struct dict {
    dictType *type;
    void *privdata;
    dictht ht[2];
    long rehashidx; /* rehashing not in progress if rehashidx == -1 */
    unsigned long iterators; /* number of iterators currently running */
    } dict;

*  type：类型特定函数是一个指向 dictType 结构的指针，每个 dictType 结构保存了一簇用于操作特定类型键值对的函数，Redis 会为用途不同的字典设置不同的类型特定函数。
 *  privdata：私有数据保存了需要传给那些类型特定函数的可选参数
 *  ht \[2\]：哈希表一个包含两个项的数组，数组中的每个项都是一个 dictht 哈希表，一般情况下，字典只使用 ht \[0\] 哈希表，ht \[1\] 哈希表只会在对 ht \[0\] 哈希表进行 rehash 时使用
 *  rehashidx：rehash 索引，当 rehash 不在进行时，值为 -1

hash 数据存在两个特点：

*  任意相同的输入一定能得到相同的数据
 *  不同的输入，有可能得到相同的输出

针对 hash 数据的特点，存在 hash 碰撞的问题，dict 通过 dictType 中的函数能够解决这个问题

typedef struct dictType {
    uint64_t (*hashFunction)(const void *key);
    int (*keyCompare)(void *privdata, const void *key1, const void *key2);
    ...
    } dictType;

*  hashFunction：用于计算 key 的 hash 值的方法
 *  keyCompare：key 的值比较方法

**2.2.2 哈希表 dictht**

dict.h/dictht 表示一个哈希表，具体结构如下：

typedef struct dictht {
    dictEntry **table;
    unsigned long size;
    unsigned long sizemask;
    unsigned long used;
    } dictht;

*  table：数组指针，数组中的每个元素都是一个指向 dict.h/dictEntry 结构的指针，每个 dictEntry 结构保存着一个键值对。
 *  size：记录了哈希表的大小，也就是 table 数组的大小，大小总是 2^n
 *  sizemask：总是等于 size - 1，这个属性和哈希值一起决定一个键应该被放到 table 数组的哪个索引上面。
 *  used：记录了哈希表目前已有节点（键值对）的数量。

键值对 dict.h/dictEntry

typedef struct dictEntry {
    void *key;
    union {
    void *val;
    uint64_t u64;
    int64_t s64;
    double d;
    } v;
    struct dictEntry *next;
    } dictEntry;

*  key：保存着键值对中的键 (SDS 类型对象)
 *  val：保存着键值对中的值，可以是一个 uint64\_t 整数，或者是一个 int64\_t 整数，又或者是一个指针指向一个被 redisObject 包装的值
 *  next：指向下个哈希表节点，形成链表指向另一个哈希表节点的指针，这个指针可以将多个哈希值相同的键值对连接在一次，以此来解决键冲突（collision）的问题

使用 hash 表就一定会存在 hash 碰撞的问题，hash 碰撞后在当前数组节点形成一个链表，在数据量超过 hash 表长度的情况下，就会存在大量节点称为链表，极端情况下时间复杂度会从 O (1) 变为 O (n)；如果 hash 表的数据再不断减少，会造成空间浪费的情况。Redis 会针对这两种情况根据负载因子做扩展与收缩操作：

*  负载因子：哈希表已保存节点数量 / 哈希表大小，load\_factor = ht \[0\].used/ht \[0\].size
 *  扩展操作：
 *  服务器目前没有在执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且哈希表的负载因子大于等于 1；
 *  服务器目前正在执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且哈希表的负载因子大于等于 5；

收缩操作：

*  当哈希表的负载因子小于 0.1 时， 程序自动开始对哈希表执行收缩操作。

Redis 在扩容时如果全量扩容会因为数据量问题导致客户端操作短时间内无法处理，所以采用渐进式 rehash 进行扩容，步骤如下：

1.  同时持有 2 个哈希表
2.  将 rehashidx 的值设置为 0, 表示 rehash 工作正式开始
3.  在 rehash 进行期间， 每次对字典执行添加、删除、查找或者更新操作时，程序除了执行指定的操作以外，还会顺带将 ht \[0\] 哈希表在 rehashidx 索引上的所有键值对 rehash 到 ht \[1\] , 当 rehash 工作完成之后，程序将 rehashidx 属性的值增一
4.  某个时间点上，ht \[0\] 的所有键值对都会被 rehash 至 ht \[1\] ，这时程序将 rehashidx 属性的值设为 - 1， 表示 rehash 操作已完成

在渐进式 rehash 进行期间，字典的删除（delete）、查找（find）、更新（update）等操作会在两个哈希表上进行；在字典里面查找一个键的话， 程序会先在 ht \[0\] 里面进行查找，如果没找到的话，就会继续到 ht \[1\] 里面进行查找；新添加到字典的键值对一律会被保存到 ht \[1\] 里面，而 ht \[0\] 则不再进行任何添加操作：这一措施保证了 ht \[0\] 包含的键值对数量会只减不增 (如果长时间不进行操作时，事件轮询进行这种操作)，并随着 rehash 操作的执行而最终变成空表。

dict.h/redisObject

Typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:LRU_BITS;
    int refcount;
    void *ptr;
    }

*  type:4：约束客户端操作时存储的数据类型，已存在的数据无法修改类型，4bit
 *  encoding:4：值在 redis 底层的编码模式，4bit
 *  lru:LRU\_BITS：内存淘汰策略
 *  refcount：通过引用计数法管理内存，4byte
 *  ptr：指向真实存储值的地址，8byte

完整结构图如下：

#### 3 String 类型 ####

3.1 String 类型使用场景

String 字符串存在有三种类型：字符串，整数，浮点。主要有以下使用场景

1）页面动态缓存  
比如生成一个动态页面，首次可以将后台数据生成页面，并且存储到 redis 字符串中。再次访问，不再进行数据库请求，直接从 redis 中读取该页面。特点是：首次访问比较慢，后续访问快速。

2）数据缓存  
在前后分离式开发中，有些数据虽然存储在数据库，但是更改特别少。比如有个全国地区表。当前端发起请求后，后台如果每次都从关系型数据库读取，会影响网站整体性能。  
我们可以在第一次访问的时候，将所有地区信息存储到 redis 字符串中，再次请求，直接从数据库中读取地区的 json 字符串，返回给前端。

3）数据统计  
redis 整型可以用来记录网站访问量，某个文件的下载量。（原子自增自减）

4）时间内限制请求次数  
比如已登录用户请求短信验证码，验证码在 5 分钟内有效的场景。当用户首次请求了短信接口，将用户 id 存储到 redis 已经发送短信的字符串中，并且设置过期时间为 5 分钟。当该用户再次请求短信接口，发现已经存在该用户发送短信记录，则不再发送短信。

5）分布式 session  
当我们用 nginx 做负载均衡的时候，如果我们每个从服务器上都各自存储自己的 session，那么当切换了服务器后，session 信息会由于不共享而会丢失，我们不得不考虑第三应用来存储 session。通过我们用关系型数据库或者 redis 等非关系型数据库。关系型数据库存储和读取性能远远无法跟 redis 等非关系型数据库。

3.2 String 类型的实现 ——SDS 结构

Redis 并没有直接使用 C 字符串实现 String 类型，在 Redis3.2 版本之前通过 SDS 实现

Typedef struct sdshdr {
    int len;
    int free;
    char buf[];
    };

*  len：分配内存空间
 *  free：剩余可用分配空间
 *  char \[\]：value 值实际数据

3.3 SDS 与 C 字符串之间的区别

**3.3.1 查询时间复杂度**

C 获取字符串长度的复杂度为 O (N)。而 SDS 通过 len 记录长度，从 C 的 O (n) 变为 O (1)。

**3.3.2 缓冲区溢出**

C 字符串不记录自身长度容易造成缓冲区溢出（buffer overflow）。SDS 的空间分配策略完全杜绝了发生缓冲区溢出的可能性，当需要对 SDS 进行修改时，会先检查 SDS 的空间是否满足修改所需的要求，如果不满足的话 SDS 的空间扩展至执行修改所需的大小，然后才执行实际的修改操作，所以使用 SDS 既不需要手动修改 SDS 的空间大小，也不会出现缓冲区溢出问题。

在 SDS 中，buf 数组的长度不一定就是字符数量加一，数组里面可以包含未使用的字节，而这些字节的数量就由 SDS 的 free 属性记录。通过未使用空间，SDS 实现了空间预分配和惰性空间释放两种优化策略：

*  空间预分配：当对一个 SDS 进行修改，并且需要对 SDS 进行空间扩展的时候，程序不仅会为 SDS 分配修改所必须要的空间，还会为 SDS 分配额外的未使用空间。扩展 SDS 空间之前，会先检查未使用空间是否足够， 如果足够的话，就会直接使用未使用空间，而无须执行内存重分配。如果不够根据 (len + addlen (新增字节)) \* 2 的方式进行扩容，大于 1M 时，每次只会增加 1M 大小。通过这种预分配策略，SDS 将连续增长 N 次字符串所需的内存重分配次数从必定 N 次降低为最多 N 次。
 *  惰性空间释放：惰性空间释放用于优化 SDS 的字符串缩短操作：当需要缩短 SDS 保存的字符串时，程序并不立即使用内存重分配来回收缩短后多出来的字节，而是使用 free 属性将这些字节的数量记录起来，并等待将来使用。

**3.3.3 二进制安全**

C 字符串中的字符必须符合某种编码（比如 ASCII，并且除了字符串的末尾之外，字符串里面不能包含空字符， 否则最先被程序读入的空字符将被误认为是字符串结尾。

SDS 的 API 都是二进制安全的（binary-safe）：都会以处理二进制的方式来处理 SDS 存放在 buf 数组里的数据，程序不会对其中的数据做任何限制、过滤、或者假设 —— 数据在写入时是什么样的，它被读取时就是什么样。redis 不是用这个数组来保存字符，而是用它来保存一系列二进制数据。

3.4 SDS 结构优化

String 类型所存储的数据可能会几 byte 存在大量这种类型数据，但 len、free 属性的 int 类型会占用 4byte 共 8byte 存储，3.2 之后会根据字符串大小使用 sdshdr5、sdshdr8、sdshdr16、sdshdr32、sdshdr64 数据结构存储，具体结构如下：

struct __attribute__ ((__packed__)) sdshdr5 {
    unsigned char flags; /* 3 lsb of type, and 5 msb of string length */
    char buf[];
    };
    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[];
    };

*  unsign char flags：3bit 表示类型，5bit 表示未使用长度
 *  len：表示已使用长度
 *  alloc：表示分配空间大小，剩余空间大小可以使用 alloc - len 获得

3.5 字符集编码

redisObject 包装存储的 value 值，通过字符集编码对数据存储进行优化，string 类型的编码方式有如下三种：

*  embstr:  
    CPU 每次按 Cache Line 64byte 读取数据，一个 redisObject 对象为 16byte，为填充 64byte 大小，会向后再读取 48 byte 数据。但获取实际数据时还需要再通过 \* ptr 指针读取对应内存地址的数据。而一个 sdshdr8 属性的信息占用 4byte，其余 44byte 可以用来存储数据。如果 value 值小于 44，byte 可以通过一次读取缓存行获取数据。
 *  int:  
    如果 SDS 小于 20 位，并且能够转换成整型数字，redisObject 的 \* ptr 指针会直接进行存储。
 *  raw:  
    SDS

#### 4 总结 ####

redis 作为 k-v 数据存储，因查找和操作的时间复杂度都是 O (1) 和丰富的数据类型及数据结构的优化，了解了这些数据类型和结构更有利于我们平时对于 redis 的使用。下一期将对其它常用数据类型 List、Hash、Set、Sorted Set 所使用的 ZipList、QuickList、SkipList 做进一步介绍，对于文章中不清晰不准确的地方欢迎大家一起讨论交流。

[f58b2b07b6dc45bb821923f87c5fcc64.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/6431e17f5d59459fb6aa9d1676030825.jpeg