Redis~列表List的数据结构之 链表(LinkedList)和压缩列表(ZipList)

Redis的列表类型(List)使用压缩列表(ZipList)或链表(LinkedList)作为底层实现。链表是双向无环的,支持高效节点操作,而压缩列表用于节省内存,适用于少量小数据存储。压缩列表由特殊编码的连续内存块组成,当数据超出一定限制时可能触发连锁更新,虽然复杂度高,但在实际中影响较小。Redis通过这种方式在性能和内存使用之间取得平衡。
摘要由CSDN通过智能技术生成

Redis中的列表

  • 列表类型 (List) 是⼀个使用线性结构存储的结构,它的元素插入会按照先后顺序存储到链表结构中。
  • 列表类型的底层数据结构可以是压缩列表(ZipList)或者链表(LinkedList)
  • 当列表对象的所有字符串元素长度都小于64字节,并且保存的元素数量小于512个时,使用压缩列表
  • 如果不满足上述条件中的任意一个,都会使用链表

链表(LinkedList)

  • 作为一种常用数据结构,链表内置在很多高级的编程语言里面,因为Redis使用的C语言并没有内置这种数据结构,所以Redis构建了自己的链表实现
  • 链表提供了高效的节点重排能力,以及顺序性的节点访问方式,并且可以通过增删节点来灵活地调整链表的长度

链表的底层实现

  • 每个链表节点使用一个listNode结构来表示:
typedef struct listNode {
    //前置节点
    struct listNode * prev;
    //后置节点
    struct listNode * next;
    //节点的值
    void * value;
}listNode;
  • 多个listNode可以通过prev和next指针组成双端链表,如下图所示:
    在这里插入图片描述

从上面的结构可以看出,Redis的链表是一个带头尾节点的双向无环链表,并且通过len字段记录了链表节点的长度

  • 这个就是实际的链表
typedef struct list {
    //表头节点
    listNode * head;
    //表尾节点
    listNode * tail;
    //链表所包含的节点数量
    unsigned long len;
    //节点值复制函数
    void *(*dup)(void *ptr);
    //节点值释放函数
    void (*free)(void *ptr);
    //节点值对比函数
    int (*match)(void *ptr,void *key);
} list;

在这里插入图片描述

  • list结构为链表提供了表头指针head、表尾指针tail,以及链表长度计数器len
  • dup、 free和match成员则是用于实现多态链表所需的类型特定函数:
  1. dup函数用于复制链表节点所保存的值
  2. free函数用于释放链表节点所保存的值
  3. match函数则用于对比链表节点所保存的值和另一个输入值是否相等

总结Redis的链表实现的特性

  • 双向:链表节点带有prev和next指针,获取某个节点的前置节点和后置节点的复杂度都 是O(1)
  • 无环:表头节点的prev指针和表尾节点的next指针都指向NULL,对链表的访问以 NULL为终点
  • 带表头指针和表尾指针:通过list结构的head指针和tail指针,程序获取链表的表头节点 和表尾节点的复杂度为O(1)
  • 带链表长度计数器:程序使用list结构的len属性来对list持有的链表节点进行计数,程序 获取链表中节点数量的复杂度为O(1)
  • 多态:链表节点使用void*指针来保存节点值,并且可以通过list结构的dup、free、 match三个属性为节点值设置类型特定函数,所以链表可以用于保存各种不同类型的值

压缩列表(ZipList)

  • 压缩列表(ziplist)是列表键和哈希键的底层实现之一
  • 当一个列表键只包含少量列表项,并且每个列表项要么就是小整数值,要么就是长度比较短的字符串,那么Redis就会使用 压缩列表来做列表键的底层实现
  • 当一个哈希键只包含少量键值对,比且每个键值对的键和值要么就是小整数值, 要么就是长度比较短的字符串,那么Redis就会使用压缩列表来做哈希键的底层实现

压缩列表的构成

  • 压缩列表是Redis为了节约内存而开发的,是由一系列特殊编码的连续内存块组成的顺序型(sequential)数据结构。一个压缩列表可以包含任意多个节点(entry),每个节点可以保存一字节数组或者一个整数值
  • 因为普通链表节点的内存是随机分配的, 占用的内存是零星的,如果是大量数据的话使用这个号好, 但是如果是少量数据的话这样是比较浪费空间的, 而压缩列表使用的内存是整顿的, 是连续的, 所以再少量数据的时候使用压缩列表是节约了一定的内存
  • 下图展示了压缩列表的各个组成部分
    在这里插入图片描述
  • 下表则记录了各个组成部分的类型、长度以及用途
    在这里插入图片描述

压缩列表节点的构成

  • 每个压缩列表节点可以保存一个字节数组或者一个整数值
    字节数组可以是以下 三种长度的其中一种:

长度小于等于63(2 6 –1)字节的字节数组;
长度小于等于16383(2 14–1)字节的字节数组;
长度小于等于4294967295(2 32–1)字节的字节数组

  • 整数值则可以是以下六种长度的其中一种:

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

连锁更新

  • 前面说过,使用压缩链表使, 放置的数据是有限制的, 自如字符个数要在64个以内, 但是如果出现这种情况, 连续节点放置的数据都是63个, 如果突然第一个节点的字符超过了64个需要扩展, 因为压缩列表使用的内存是连续的, 所以后面的节点也应该扩展
    在这里插入图片描述

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

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

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

  1. 首先,压缩列表里要恰好有多个连续的、长度介于250字节至253字节之间的节点,连锁 更新才有可能被引发,在实际中,这种情况并不多见
  2. 其次,即使出现连锁更新,但只要被更新的节点数量不多,就不会对性能造成任何影 响:比如说,对三五个节点进行连锁更新是绝对不会影响性能的
  • 因为以上原因,ziplistPush等命令的平均复杂度仅为O(N),在实际中,我们可以放心 地使用这些函数,而不必担心连锁更新会影响压缩列表的性能
  • 5
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 5
    评论
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值