【Redis实现系列】SDS、整数集合、压缩列表

数据结构

SDS 动态字符串

  • 在Redis里面,C字符串只会作为字符串字面量(string literal)用在一些无须对字符串值进行修改的地方,比如打印日志。

  • 当Redis需要的不仅仅是一个字符串字面量,而是一个可以被修改的字符串值时,Redis就会使用SDS来表示字符串值

    • Redis的数据库里面,包含字符串值的键值对在底层都是由SDS实现的。
    • 除了用来保存数据库中的字符串值之外,SDS还被用作缓冲区(buffer):AOF模块中的AOF缓冲区,以及客户端状态中的输入缓冲区,都是由SDS实现的。
实现
struct sdshdr {
    // 记录 buf 数组中已使用字节的数量,等于 SDS 所保存字符串的长度
    int len;
    // 记录buf 数组中未使用字节的数量
    int free;
    // 字节数组,用于保存字符串
    char buf[];
};

补充:SDS遵循C字符串以空字符结尾的惯例,保存空字符的1字节空间不计算在SDS的len属性里面

  • 为空字符分配额外的1字节空间,以及添加空字符到字符串末尾等操作,都是由SDS函数自动完成的,所以这个空字符对于SDS的使用者来说是完全透明的。
  • 遵循空字符结尾这一惯例的好处是,SDS可以直接重用一部分C字符串函数库里面的函数。
SDS优化策略

空间预分配

  • 空间预分配用于优化SDS的字符串增长操作:当SDS的API对一个SDS进行修改,并且需要对SDS进行空间扩展的时候,程序不仅会为SDS分配修改所必须要的空间,还会为SDS分配额外的未使用空间。

  • 额外分配的未使用空间数量由以下公式决定:

    • 如果对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数组的实际长度将为30MB+1MB+1byte。

  • 通过这种预分配策略,SDS将连续增长N次字符串所需的内存重分配次数从必定N次降低为最多N次。

惰性空间释放

  • 惰性空间释放用于优化SDS的字符串缩短操作:当SDS的API需要缩短SDS保存的字符串时,程序并不立即使用内存重分配来回收缩短后多出来的字节,而是使用free属性将这些字节的数量记录起来,并等待将来使用。

  • 通过惰性空间释放策略,SDS避免了缩短字符串时所需的内存重分配操作,并为将来可能有的增长操作提供了优化。

  • 与此同时,SDS也提供了相应的API,让我们可以在有需要时,真正地释放SDS的未使用空间,所以不用担心惰性空间释放策略会造成内存浪费。

与C字符串区别

常数复杂度获取字符串长度

  • 因为C字符串并不记录自身的长度信息,所以为了获取一个C字符串的长度,程序必须遍历整个字符串,对遇到的每个字符进行计数,直到遇到代表字符串结尾的空字符为止,这个操作的复杂度为O(N)。
  • SDS 的复杂度仅为O(1),当一个非常长的字符串键反复执行STRLEN命令,也不会对系统性能造成任何影响。

杜绝缓冲区溢出

  • C字符串不记录自身长度带来的另一个问题是容易造成缓冲区溢出,比如调用 <string.h>/strcat拼接函数 ,可能因为 dest 剩余空间小于 src 的长度,那么就会覆盖 dest 长度外的数据。
  • SDS的空间分配策略完全杜绝了发生缓冲区溢出的可能性:当SDS API需要对SDS进行修改时,API会先检查SDS的空间是否满足修改所需的要求,如果不满足的话,API会自动将SDS的空间扩展至执行修改所需的大小,然后才执行实际的修改操作,所以使用SDS既不需要手动修改SDS的空间大小,也不会出现前面所说的缓冲区溢出问题。

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

  • 因为C字符串并不记录自身的长度,所以对于一个包含了N个字符的C字符串来说,这个C字符串的底层实现总是一个N+1个字符长的数组(额外的一个字符空间用于保存空字符)。因为C字符串的长度和底层数组的长度之间存在着这种关联性,所以每次增长或者缩短一个C字符串,程序都总要对保存这个C字符串的数组进行一次内存重分配操作:

    • 如果程序执行的是增长字符串的操作,比如拼接操作(append),那么在执行这个操作之前,程序需要先通过内存重分配来扩展底层数组的空间大小,如果忘了这一步就会产生缓冲区溢出。

    • 如果程序执行的是缩短字符串的操作,比如截断操作(trim),那么在执行这个操作之后,程序需要通过内存重分配来释放字符串不再使用的那部分空间,如果忘了这一步就会产生内存泄漏。

  • 影响:因为内存重分配涉及复杂的算法,并且可能需要执行系统调用,所以它通常是一个比较耗时的操作

    • 在一般程序中,如果修改字符串长度的情况不太常出现,那么每次修改都执行一次内存重分配是可以接受的。
    • 但是Redis作为数据库,经常被用于速度要求严苛、数据被频繁修改的场合,如果每次修改字符串的长度都需要执行一次内存重分配的话,那么光是执行内存重分配的时间就会占去修改字符串所用时间的一大部分,如果这种修改频繁地发生的话,可能还会对性能造成影响。

二进制安全

  • C字符串中的字符必须符合某种编码(比如ASCII),并且除了字符串的末尾之外,字符串里面不能包含空字符,否则最先被程序读入的空字符将被误认为是字符串结尾,这些限制使得C字符串只能保存文本数据,而不能保存像图片、音频、视频、压缩文件这样的二进制数据。
  • 虽然数据库一般用于保存文本数据,但使用数据库来保存二进制数据的场景也不少见,因此,为了确保Redis可以适用于各种不同的使用场景,SDS的API都是二进制安全的(binary-safe),所有SDS API都会以处理二进制的方式来处理SDS存放在buf数组里的数据,程序不会对其中的数据做任何限制、过滤、或者假设,数据在写入时是什么样的,它被读取时就是什么样。因为SDS使用len属性的值而不是空字符来判断字符串是否结束。

兼容部分C字符串函数

  • 虽然SDS的API都是二进制安全的,但它们一样遵循C字符串以空字符结尾的惯例:这些API总会将SDS保存的数据的末尾设置为空字符,并且总会在为buf数组分配空间时多分配一个字节来容纳这个空字符,这是为了让那些保存文本数据的SDS可以重用一部分<string.h>库定义的函数。
  • 当保存的是文本数据时,大多数情况都可以复用 <string.h> 下的函数

小结:

小结

API:

在这里插入图片描述

在这里插入图片描述

Redis只会使用C字符串作为字面量,在大多数情况下,Redis使用SDS(Simple Dynamic String,简单动态字符串)作为字符串表示。

比起C字符串,SDS具有以下优点:

  • 常数复杂度获取字符串长度。

  • 杜绝缓冲区溢出。

  • 减少修改字符串长度时所需的内存重分配次数。

  • 二进制安全。

  • 兼容部分C字符串函数

整数集合

  • 整数集合(intset)是集合键(sadd)的底层实现之一
    • 当一个集合只包含整数值元素,并且这个集合的元素数量不多时,Redis就会使用整数集合作为集合键的底层实现。
实现

整数集合(intset)是Redis用于保存整数值的集合抽象数据结构,它可以保存类型为int16_t、int32_t或者int64_t的整数值,并且保证集合中不会出现重复元素。

intset.h/intset结构表示一个整数集合

typedef struct intset {
    // 编码方式
    uint32_t encoding;
    // 集合包含的元素数量
    uint32_t length;
    // 保存元素的数组
    int8_t contents[];
} intset;

contents数组

  • 是整数集合的底层实现:整数集合的每个元素都是contents数组的一个数组项(item),各个项在数组中按值的大小从小到大有序地排列,并且数组中不包含任何重复项。

length属性

  • 记录了整数集合包含的元素数量,也即是contents数组的长度。

encoding属性

  • 虽然intset结构将contents属性声明为int8_t类型的数组,但实际上contents数组并不保存任何int8_t类型的值,contents数组的真正类型取决于encoding属性的值
  • 如果encoding属性的值为INTSET_ENC_INT16,那么contents就是一个int16_t类型的数组,数组里的每个项都是一个int16_t类型的整数值(最小值为-32768,最大值为32767)。
  • 如果encoding属性的值为INTSET_ENC_INT32,那么contents就是一个int32_t类型的数组,数组里的每个项都是一个int32_t类型的整数值(最小值为-2147483648,最大值为2147483647)。
  • 如果encoding属性的值为INTSET_ENC_INT64,那么contents就是一个int64_t类型的数组,数组里的每个项都是一个int64_t类型的整数值(最小值为-9223372036854775808,最大值为9223372036854775807)。
数组升级

每当我们要将一个新元素添加到整数集合里面,并且新元素的类型比整数集合现有所有元素的类型都要长时,整数集合需要先进行升级(upgrade),然后才能将新元素添加到整数集合里面。

升级整数集合并添加新元素共分为三步进行:

  • 根据新元素的类型,扩展整数集合底层数组的空间大小,并为新元素分配空间。

  • 将底层数组现有的所有元素都转换成与新元素相同的类型,并将类型转换后的元素放置到正确的位上,而且在放置元素的过程中,需要继续维持底层数组的有序性质不变。

  • 将新元素添加到底层数组里面。

升级之后新元素的摆放位置

  • 因为引发升级的新元素的长度总是比整数集合现有所有元素的长度都大,所以这个新元素的值要么就大于所有现有元素,要么就小于所有现有元素:

  • 在新元素(指负数)小于所有现有元素的情况下,新元素会被放置在底层数组的最开头(索引0);

  • 在新元素(指正数)大于所有现有元素的情况下,新元素会被放置在底层数组的最末尾(索引length-1)。

升级的好处

  • 整数集合的升级策略有两个好处,一个是提升整数集合的灵活性,另一个是尽可能地节约内存。

  • 提升灵活性

    • 因为C语言是静态类型语言,为了避免类型错误,我们通常不会将两种不同类型的值放在同一个数据结构里面。

    • 例如,我们一般只使用int16_t类型的数组来保存int16_t类型的值,只使用int32_t类型的数组来保存int32_t类型的值,诸如此类。

    • 但是,因为整数集合可以通过自动升级底层数组来适应新元素,所以我们可以随意地将int16_t、int32_t或者int64_t类型的整数添加到集合中,而不必担心出现类型错误,这种做法非常灵活。

  • 节约内存

    • 当然,要让一个数组可以同时保存int16_t、int32_t、int64_t三种类型的值,最简单的做法就是直接使用int64_t类型的数组作为整数集合的底层实现。不过这样一来,即使添加到整数集合里面的都是int16_t类型或者int32_t类型的值,数组都需要使用int64_t类型的空间去保存它们,从而出现浪费内存的情况。

    • 而整数集合现在的做法既可以让集合能同时保存三种不同类型的值,又可以确保升级操作只会在有需要的时候进行,这可以尽量节省内存。

    • 例如,如果我们一直只向整数集合添加int16_t类型的值,那么整数集合的底层实现就会一直是int16_t类型的数组,只有在我们要将int32_t类型或者int64_t类型的值添加到集合时,程序才会对数组进行升级。

数组降级

  • 整数集合不支持降级操作,一旦对数组进行了升级,编码就会一直保持升级后的状态。
小结

API:

在这里插入图片描述

整数集合是集合键的底层实现之一。

实现

  • 整数集合的底层实现为数组,这个数组以有序、无重复的方式保存集合元素,在有需要时,程序会根据新添加元素的类型,改变这个数组的类型。

  • 升级操作为整数集合带来了操作上的灵活性,并且尽可能地节约了内存。

  • 整数集合只支持升级操作,不支持降级操作。

压缩列表

压缩列表(ziplist)是列表键(lpush、rpush)、集合键(sadd)、哈希键(hset)的底层实现之一

  • 只包含少量元素项,并且每个元素项要么就是小整数值,要么就是长度比较短的字符串,那么Redis就会使用压缩列表来做列表键的底层实现。

  • 因为压缩列表比双端链表更节约内存,并且在元素数量较少时,在内存中以连续块方式保存的压缩列表比起双端链表可以更快被载入到缓存中;但随着列表对象包含的元素越来越多,使用压缩列表来保存元素的优势逐渐消失时,对象就会将底层实现从压缩列表转向功能更强、也更适合保存大量元素的双端链表上面

实现

压缩列表是Redis为了节约内存而开发的,是由一系列特殊编码的连续内存块组成的顺序型(sequential)数据结构。一个压缩列表可以包含任意多个节点(entry),每个节点可以保存一个字节数组或者一个整数值。

组成部分

  • Redis使用字节数组表示一个压缩列表,字节数组逻辑划分为多个字段

    在这里插入图片描述

  • 说明

    在这里插入图片描述

压缩列表节点

每个压缩列表节点可以保存一个字节数组或者一个整数值

  • 字节数组可以是以下三种长度的其中一种:

    • 长度小于等于63(2^6–1)字节的字节数组;
    • 长度小于等于16383(2^14–1)字节的字节数组;
    • 长度小于等于4294967295(2^32–1)字节的字节数组;
  • 整数值则可以是以下六种长度的其中一种:

    • 4位长,介于0至12之间的无符号整数;
    • 1字节长的有符号整数;
    • 3字节长的有符号整数;
    • int16_t类型整数;
    • int32_t类型整数;
    • int64_t类型整数。

每个压缩列表节点都由previous_entry_length、encoding、content三个部分组成

在这里插入图片描述

  • previous_entry_length

    • 如果前一节点的长度小于254字节,那么previous_entry_length属性的长度为1字节:前一节点的长度就保存在这一个字节里面。
    • 如果前一节点的长度大于等于254字节,那么previous_entry_length属性的长度为5字节:其中属性的第一字节会被设置为0xFE(十进制值254),而之后的四个字节则用于保存前一节点的长度。

    压缩列表的从表尾向表头遍历操作就是使用这一原理实现的,只要拥有了一个指向某个节点起始地址的指针,那么通过这个指针以及这个节点的previous_entry_length属性,程序就可以一直向前一个节点回溯,最终到达压缩列表的表头节点。

    在这里插入图片描述

  • encoding

    节点的encoding属性记录了节点的content属性所保存数据的类型以及长度

    • 字节数组编码(一字节、两字节或者五字节长,值的最高位为00、01或者10):这种编码表示节点的content属性保存着字节数组,数组的长度由编码除去最高两位之后的其他位记录;

    • 整数值编码(一字节长,值的最高位以11开头的是整数编码):这种编码表示节点的content属性保存着整数值,整数值的类型和长度由编码除去最高两位之后的其他位记录;

    字节数组编码(’_‘表示留空,而b、x等变量则代表实际的二进制数据)

    在这里插入图片描述

    整数编码

    在这里插入图片描述

  • content

    节点的content属性负责保存节点的值,节点值可以是一个字节数组或者整数,值的类型和长度由节点的encoding属性决定。

示例:

  • 字节数组:编码的最高两位00表示节点保存的是一个字节数组;编码的后六位001011记录了字节数组的长度11;content属性保存着节点的值"hello world"。

    在这里插入图片描述

  • 整数值:编码11000000表示节点保存的是一个int16_t类型的整数值;content属性保存着节点的值10086。

    在这里插入图片描述

连锁更新

原因:

增加节点:

  • 条件1:假设在一个压缩列表中,有多个连续的、长度介于250字节到253字节之间的节点e1至eN。并且这些节点的长度只需要1字节长的previous_entry_length属性来记录。

    在这里插入图片描述

  • 条件2:如果我们将一个长度大于等于 254 字节的新节点 new 设置为e1的前置节点

    在这里插入图片描述

  • 结果:

    • 因为e1的previous_entry_length属性仅长1字节,它没办法保存新节点new的长度,所以程序将对压缩列表执行空间重分配操作,并将e1节点的previous_entry_length属性从原来的1字节长扩展为5字节长。
    • 那么 e1 的 previous_entry_length 属性新增四个字节的空间之后,e1的长度就变成了介于254字节至257字节之间,那么 e2的previous_entry_length 也需要从原来的1字节长扩展为5字节长。
    • 同理 扩展e2也会引发对e3的扩展,而扩展e3又会引发对e4的扩展……为了让每个节点的previous_entry_length属性都符合压缩列表对节点的要求,程序需要不断地对压缩列表执行空间重分配操作,直到eN为止。
  • 结论:

    Redis将这种在特殊情况下产生的连续多次空间扩展操作称之为“连锁更新”(cascade update)

    在这里插入图片描述

删除节点:

  • 除了添加新节点可能会引发连锁更新之外,删除节点也可能会引发连锁更新。

  • 条件1:如果e1至eN都是大小介于250字节至253字节的节点,big节点的长度大于等于254字节

  • 条件2:删除 e1 前面的节点,并且被删除节点的前一个节点大于等于 254 kb

在这里插入图片描述

时间复杂度

  • 因为连锁更新在最坏情况下需要对压缩列表执行N次空间重分配操作,而每次空间重分配的最坏复杂度为O(N),所以连锁更新的最坏复杂度为O(N 2)。

要注意的是,尽管连锁更新的复杂度较高,但它真正造成性能问题的几率是很低的:

  • 首先,压缩列表里要恰好有多个连续的、长度介于250字节至253字节之间的节点,连锁更新才有可能被引发,在实际中,这种情况并不多见;

  • 其次,即使出现连锁更新,但只要被更新的节点数量不多,就不会对性能造成任何影响:比如说,对三五个节点进行连锁更新是绝对不会影响性能的;

因为以上原因,ziplistPush等命令的平均复杂度仅为O(N),在实际中,我们可以放心地使用这些函数,而不必担心连锁更新会影响压缩列表的性能。

小结

API:

  • 因为ziplistPush、ziplistInsert、ziplistDelete和ziplistDeleteRange四个函数都有可能会引发连锁更新,所以它们的最坏复杂度都是O(N 2)。

在这里插入图片描述

压缩列表是一种为节约内存而开发的顺序型数据结构,被用作列表键和哈希键的底层实现之一。

实现

  • 压缩列表由 zlbytes(原始长度)、zltail(尾 entry 起始位置)、zllen(压缩列表长度)、entrys、zlend(结束标志)

  • entry 由 previous_entry_lenth(前一个 entry 长度)、encoding(content 的编码与形式)、content(内容,一个整数或者字节数组)

  • 压缩列表可以包含多个节点,每个节点可以保存一个字节数组或者整数值。

  • 添加新节点到压缩列表,或者从压缩列表中删除节点,可能会引发连锁更新操作,但这种操作出现的几率并不高。

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 撸撸猫 设计师:C马雯娟 返回首页