Redis压缩列表原理与应用分析

摘要

Redis是一款著名的key-value内存数据库软件,同时也是一款卓越的数据结构服务软件。它支持字符串、列表、哈希表、集合、有序集合五种数据结构类型,同时每种数据结构类型针对不同的应用场景又支持不同的编码方式。这篇文章主要介绍压缩列表编码,在理解压缩列表编码原理的基础上介绍Redis对压缩列表的应用,最后再对Redis压缩列表应用进行分析。

摘要

Redis是一款著名的key-value内存数据库软件,同时也是一款卓越的数据结构服务软件。它支持字符串、列表、哈希表、集合、有序集合五种数据结构类型,同时每种数据结构类型针对不同的应用场景又支持不同的编码方式。这篇文章主要介绍压缩列表编码,在理解压缩列表编码原理的基础上介绍Redis对压缩列表的应用,最后再对Redis压缩列表应用进行分析。

Redis压缩列表原理与应用

压缩列表是一种数据结构,这种数据结构的功能是将一系列数据与其编码信息存储在一块连续的内存区域,这块内存物理上是连续的,逻辑上被分为多个组成部分,其目的是在一定可控的时间复杂读条件下尽可能的减少不必要的内存开销,从而达到节省内存的效果,这么介绍有点玄乎,我们先一起看看它的实现原理吧,Redis3.2版本中,作者对压缩列表的实现在ziplist.h和ziplist.c中。

压缩列表原理

我认为将数据按照一定规则存储在内存中可以用“编码”这个词描述,因此下面会常用“编码”这个词。

总体编码

上面说到压缩列表是一块连续的内存区域,这块内存区域布编码示意图大致如下:

Redis压缩列表内存编码示意图

常态的压缩列表内存编码如上图所示,整个内存块区域内分为五个部分,下面分别介绍着五个部分:

zlbytes:存储一个无符号整数,固定四个字节长度,用于存储压缩列表所占用的字节,当重新分配内存的时候使用,不需要遍历整个列表来计算内存大小。

zltail:存储一个无符号整数,固定四个字节长度,代表指向列表尾部的偏移量,偏移量是指压缩列表的起始位置到指定列表节点的起始位置的距离。

zllen:压缩列表包含的节点个数,固定两个字节长度,源码中指出当节点个数大于2^16-2个数的时候,该值将无效,此时需要遍历列表来计算列表节点的个数。

entryX:列表节点区域,长度不定,由列表节点紧挨着组成。

zlend:一字节长度固定值为255,用于表示列表结束。

列表元素编码

上面介绍了压缩列表的总体内存布局,对于初entryX区域以外的四个区域的长度都是固定的,下面再看看entryX区域的编码情况。

每个列表节点由三部分组成:

压缩列表节点编码示意图

每个压缩列表节点区域头部包含两部分,一部分叫做previous length,另一部分叫encoding,最后是主体内容,叫做content,下面分别介绍他们:

previous length

用于存储上一个节点的长度,因此压缩列表可以从尾部向头部遍历,即当前节点位置减去上一个节点的长度即得到上一个节点的起始位置。previous length的长度可能是1个字节或者是5个字节,如果上一个节点的长度小于254,则该节点只需要一个字节就可以表示前一个节点的长度了,如果前一个节点的长度大于等于254,则previous length的第一个字节为254,后面用四个字节表示当前节点前一个节点的长度。这么做很有效地减少了内存的浪费。

encoding

节点的encoding保存的是节点的content的内容类型以及长度,encoding类型一共有两种,一种字节数组一种是整数,encoding区域长度为1字节、2字节或者5字节长。Redis作者巧妙的利用了前两个字节来表示content存储的内容类型和encoding区域的长度,我们先看看字节数组类型的encoding内容:

content为字节数组的encoding内容

再看看整数编码类型的encoding内容:

content为整数的encoding内容

content

content区域用于保存节点的内容,节点内容类型和长度由encoding决定,上面可以看出目前content的内容类型有整数类型和字节数组类型,且某些条件下content的长度可能为0。

相信到这里,我们都明白了压缩列表的原理压缩列表并不是对数据利用某种算法进行压缩,而是将数据按照一定规则编码在一块连续的内存区域,目的是节省内存。下面我们看看压缩列表在Redis中的应用领域。

Redis中压缩列表的应用

Redis中,不同的数据类型广泛地应用了压缩列表编码,整理如下表:

Redis中数据结构类型与压缩列表的应用

上表总结了压缩列表编码在Redis不同的数据类型中的应用,Redis一共支持五种数据结构类型,其中有三种数据结构在一定条件下会应用压缩列表,至于什么条件后面会分析,值得一提的是Redis当前支持的GEO(地理位置)对压缩列表也有应用,具体此处不做讨论。

Redis压缩列表应用分析

上面部分介绍了Redis压缩列表的原理与应用,下面简单分析一下,主要从通过试图回答一些问题来分析:Redis为什么使用压缩列表?使用压缩列表的好处是什么?使用压缩列表的好处还有什么?压缩列表的应用对与我们使用内存有没有什么启发?

Redis对于每种数据结构、无论是列表、哈希表还是有序集合,在决定是否应用压缩列表作为当前数据结构类型的底层编码的时候都会依赖一个开关和一个阈值,开关用来决定我们是否要启用压缩列表编码,阈值总的来说通常指当前结构存储的key数量有没有达到一个数值(条件),或者是value值长度有没有达到一定的长度(条件)。任何策略都有其应用场景,不同场景应用不同策略。为什么当前结构存储的数据条目达到一定数值使用压缩列表就不好?压缩列表的新增、删除的操作平均时间复杂度为O(N),随着N的增大,时间必然会增加,他不像哈希表可以以O(1)的时间复杂度找到存取位置,然而在一定N内的时间复杂度我们可以容忍然而压缩列表利用巧妙的编码技术除了存储内容尽可能的减少不必要的内存开销,将数据存储于连续的内存区域,这对于Redis本身来说是有意义的,因为Redis是一款内存数据库软件,想办法尽可能减少内存的开销是Redis设计者一定要考虑的事情。

另外,经过仔细琢磨,我认为使用压缩列表的好处除了节约内存之外,还有减少内存碎片的作用,我把这种行为叫做"合并存储",也就是将很多小的数据块存储在一个比较大的内存区域,试想想,如果我们将要存储的数据都是很小的条目,我们为每一个数据条目都单独的申请内存,结果是这些条目将有可能分散在内存的每一个角落,最终导致碎片增加,这是一件令人头疼的事情。

总结

这篇文章在介绍Redis压缩列表原理与应用的基础之上对Redis压缩列表的应用进行分析,分析部分主要掺杂着个人的理解与认知,如果有不同观点或者补充观点,欢迎留言讨论。

时间: 2024-10-08 21:04:47

Redis压缩列表原理与应用分析的相关文章

Redis压缩列表

此篇文章是主要介绍Redis在数据存储方面的其中一种方式,压缩列表.本文会介绍1. 压缩列表(ziplist)的使用场景 2.如何达到节约内存的效果?3.压缩列表的存储格式 4. 连锁更新的问题  5. conf文件配置.在实践上的操作主要是对conf配置文件进行配置,具体上没有确切的一个值,更多是经验值.也有的项目会直接使用原本的默认值.此篇对于更好地理解一个数据库底层的存储逻辑会有一点帮助.修学储能,既要博,也要渊.希望这篇文章对同样也是在学习Redis的各位同伴有点用. 一.压缩列表(zi

Redis数据结构之压缩列表

压缩列表是Redis为了节约内存而开发的,由一系列特殊编码的连续内存块组成的顺序型数据结构.一个压缩列表可以包含任意多个节点,每个节点可以保存一个字节数组或者一个整数值. 一.压缩列表结构1. 压缩列表结构: 参数说明:zlbytes:记录整个压缩列表占用的内存字节数.zltail:记录压缩列表表尾节点距离压缩列表起始地址有多少字节.zllen:记录了压缩列表包含的节点数量.entryN:压缩列表的节点,节点长度由节点保存的内容决定.zlend:特殊值0xFF(十进制255),用于标记压缩列表的

redis 底层数据结构 压缩列表 ziplist

当一个哈希键只包含少量键值对,并且每个键值对的键和值要么就是小整数值,要么就是长度比较短的字符串,那么Redis就会使用压缩列表来做哈希键的底层实现. 压缩列表是Redis为了节约内存而开发的是由一系列特殊编码的连续内存块组成的顺序型数据结构,一个压缩列表可以包含任意多个节点,每个节点可以保存一个字节数组或者一个整数值 ziplist 数据结构 压缩列表节点的构成 每个压缩列表节点可以保存一个字节数组或者一个整数值,其中字节数组可以是以下三种长度的其中一种 长度小于等于63字节的字节数组 长度小

Redis实现之压缩列表

压缩列表 压缩列表(ziplist)是列表键和哈希键的底层实现之一,当一个列表键只包含少量列表项,并且每个列表项要嘛是整数值,要嘛是比较短的字符串,那么Redis就会使用压缩列表来做列表键的底层实现.例如,执行以下命令将创建一个压缩列表键的底层实现 127.0.0.1:6379> RPUSH lst 1 3 5 10086 "hello" "world" (integer) 6 127.0.0.1:6379> OBJECT ENCODING lst &q

学习笔记-Redis设计与实现-压缩列表

压缩列表(ziplist)是列表键和哈希键的底层实现之一. 7.1 压缩列表的构成 压缩列表是Redis为了节约内存而开发的,是由一系列特殊编码的连续内存块组成的顺序型(sequential)数据结构.一个压缩列表可以包含任意多个节点(entry),每个节点可以保存数组或者一个整数值. 7.2 压缩列表节点的构成 每个压缩列表节点可以保存一个字节数组或者一个整数值. 每个压缩列表节点都由previous_entry_length.encoding.content三个部分组成. 7.2.1 pre

Redis数据结构之压缩列表-ziplist

为了节约内存,在zset和hash容器对象元素个数较少时,Redis会采用压缩列表(ziplist)进行存储. 压缩列表是一块连续的内存空间,元素之间紧挨着存储,不存在冗余 一个压缩列表可以包含任意多个节点(entry),每个节点可以保存一个字节数组或者一个整数值 结构 // 压缩列表 struct ziplist<T> { int32 zlbytes; // 压缩列表占用的内存字节数 int32 zltail_offset; // 记录表尾节点距离起始地址有多少个字节,用于快速定位最后一个元

Redis设计与实现 - chapter7 压缩列表

Chapter7 压缩列表 列表键和哈希键的底层实现之一(列表键只包含少量元素,且元素为小整数或较短字符串:而哈希键之包含少量键值对,且每个键值对的key和value都是小整数或较短字符串). 为了节约内存. 压缩列表的组成 一系列特殊编码的连续内存块组成的顺序型(sequential)数据结构,包含多个节点entry,每个entry保存一个字节数组或一个整数. 内存组织: 具体含义: 压缩列表节点的组成 每个节点保存一个字节数组或者一个整数值,由 previous_entry_length .

Redis2.6源代码走读第007课:压缩列表02

身体被掏空了一星期, 前天终于挣扎着继续做这个代码走读 不得不说, 压缩列表的实现复杂程度还是超出了我的预计 破天荒的第一次, 我必须手动上注释, 才能防止自己迷失在代码里面. 今天还没有录制视频, 最近一直在做公司的事, 时间也比较紧, 所以今天只是把我经过注释的压缩列表部分的代码贴出来, 同时给出一个阅读建议 在学习压缩列表的过程中, 我也参考了黄健宏先生对Redis2.6源代码的注释, 发现了黄先生注释中的一个错误. 如下: unsigned char *ziplistFind(unsig

Redis源码分析(三十四)--- redis.h服务端的实现分析(1)

上次刚刚分析过了客户端的结构体分析,思路比较简答,清晰,最后学习的是服务端的实现,服务端在Redis可是重中之重,里面基本上囊括了之前模块中涉及到的所有知识点,从redis的头文件就可以看出了,redis.h代码量就已经破1000+行了,而且都还只是一些变量,宏定义的声明,和一些方法原型的声明.所以,今天的总结跟昨天一样,先不做具体的实现学习,先从全局的角度思考,服务端的整体设计思路,这从头文件的声明正好可以学习. /* ----------------------- 声明了一下所需的头文件,主