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设计者必定要考虑的事情。

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

在此我向你们推荐一个程序员交流群。交流讨论群号为：833145934 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源与最新的BAT面试题，目前受益良多

总结

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