【Redis】底层数据结构及其封装对象详解

最新推荐文章于 2023-08-27 09:19:54 发布

快乐小羊没烦恼

最新推荐文章于 2023-08-27 09:19:54 发布

阅读量1.7k

点赞数

分类专栏：扫盲文章标签： Redis 数据结构

本文链接：https://blog.csdn.net/qq_30154571/article/details/121617101

版权

本文详细介绍了Redis的底层数据结构，包括简单动态字符串（SDS）的定义、优势以及空间预分配和惰性释放策略，链表的实现，字典的哈希表结构、rehash过程和渐进式rehash策略，以及跳跃表的原理和应用。此外，还探讨了Redis中数据结构对象的类型和编码，如字符串、列表、哈希、集合和有序集合的多种编码方式及转换条件。

摘要由CSDN通过智能技术生成

【底层数据结构】

在redis中，有一些底层的数据结构：

简单动态字符串（SDS）
双端链表
字典
压缩列表
整数集合…

在这里插入图片描述

一、简单动态字符串SDS

在Redis中，没有使用C语言自带的字符串功能，而是对其进行了封装，称之为简单动态字符串SDS。

1、SDS的定义

C语言对SDS的数据结构的实现，定义了三个变量如下图：
在这里插入图片描述

存储数据之后的结构如下图所示：
在这里插入图片描述
其中：

2、和普通C字符串的区别：

（1）获取len的时间复杂度为1

由于SDS中自带len这个变量，所以操作SDS可以直接获取len，不像C那样还需要整个遍历以便长度，时间复杂度为从n降低为现在的1。

（2）防止缓冲区溢出

由于C字符串不记录本身的长度，所以如果有两个字符串在内存中相邻：
在这里插入图片描述
对前面的字符串进行append操作时，便会产生这样的结果：si的数据将溢出到s2所在的空间中，导致s2保存的内容被意外地修改。

与C字符串不同， SDS的空间分配策略不会发生缓冲区溢出：当SDS的API需要对SDS进行修改时， API会先检査SDS的空间是否满足修改所需的要求，如果不满足的话， API会自动将SDS的空间扩展至执行修改所需的大小，然后才执行实际的修改操作。

所以使用SDS既不需要手动改SDS的空间大小，也不会出现前面所说的缓冲区溢出问题，比如说我现在有一个字符串redis：
在这里插入图片描述
如果进行拼接操作，SDS会对第一个字符串的buf进行扩容，具体扩容的规则会在后面讲。

（3）减少修改字符串时带来的内存重分配次数

在C字符串中：

如果程序执行的是增长字符串的操作，比如拼接操作(append)，那么在执行这个操作之前，程序需要先通过内存重分配来防止缓冲区溢出。
如果程序执行的是缩短字符串的操作，比如截断操作(trim),那么在执行这个操作之后，程序需要通过内存重分配来防止内存泄漏。
在一般程序中，如果修改字符串长度的情况不太常出现，那么每次修改都执行一次内存重分配是可以接受的。
但是Redis作为数据库，经常被用于速度要求严苛、数据被频繁修改的场合，如果每次修改字符串的长度都需要执行一次内存重分配的话，那么光是执行内存重分配的时间就会占去修改字符串所用时间的一大部分，如果这种修改频繁地发生的话,可能还会对性能造成影响。

为了解决这些问题，SDS实现了空间预分配和惰性空间释放两种优化策略：

空间预分配（扩容）

注意：扩容具体指的是扩大buf [] 的大小。

如果对SDS进行修改之后， SDS的长度（也即是len属性的值）将小于1MB,那么程序分配和len属性同样大小的未使用空间，这时SDS len属性的值将和free属性的值相同。举个例子，如果进行修改之后， SDS的len将变成13字节，那么程序也会分配13字节的未使用空间， SDS的buf数组的实际长度将变成13+13+1=27字节（额外的一字节用于保存空字符）。
如果对SDS进行修改之后， SDS的长度将大于等于1MB,那么程序会分配1MB的未使用空间。举个例子，如果进行修改之后， SDS的len将变30MB,那么程序会分配1MB的未使用空间， SDS的buf数组的实际长度将为30 MB + 1MB +l byte。

在扩展SDS空间之前， SDS API会先检査未使用空间是否足够，如果足够的话， API就会直接使用未使用空间，而无须执行内存重分配。通过这种预分配策略， SDS将连续增长N次字符串所需的内存重分配次数从必定N次降低为最多N次。