内存节省到极致！Redis中的压缩表，值得了解

前言

前面几周我们一起看了Redis底层数据结构，如动态字符串SDS，双向链表Adlist，字典Dict，跳跃表，整数集合intset，如果有对Redis常见的类型或底层数据结构不明白的请看上面传送门。

今天来说下zset的底层实现压缩表(在数据库量小的时候用)，如果有对zset不明白的，看上面的传送门哈。

压缩列表的概念提出

传统的数组

同之前的底层数据一样，压缩列表也是由Redis设计的一种数据存储结构。

他有点类似于数组，都是通过一片连续的内存空间来存储数据。但是其和数组也有点区别，数组存储不同长度的字符时，会选择最大的字符长度作为每个节点的内存大小。

如下图，一共五个元素，每个元素的长度都是不一样的，这个时候选择最大值5作为每个元素的内存大小，如果选择小于5的，那么第一个元素hello，第二个元素world就不能完整存储，数据会丢失。

 

存在的问题

上面已经提到了需要用最大长度的字符串大小作为整个数组所有元素的内存大小，如果只有一个元素的长度超大，但是其他的元素长度都比较小，那么我们所有元素的内存都用超大的数字就会导致内存的浪费。

那么我们应该如何改进呢？

引出压缩列表

Redis引入了压缩列表的概念，即多大的元素使用多大的内存，一切从实际出发，拒绝浪费。

如下图，根据每个节点的实际存储的内容决定内存的大小，即第一个节点占用5个字节，第二个节点占用5个字节，第三个节点占用1个字节，第四个节点占用4个字节，第五个节点占用3个字节。

 

还有一个问题，我们在遍历的时候不知道每个元素的大小，无法准确计算出下一个节点的具体位置。实际存储不会出现上图的横线，我们并不知道什么时候当前节点结束，什么时候到了下一个节点。所以在redis中添加length属性，用来记录前一个节点的长度。

如下图，如果需要从头开始遍历，取某个节点后面的数字，比如取“hello”的起始地址，但是不知道其结束地址在哪里，我们取后面数字5，即可知道"hello"占用了5个字节，即可顺利找到下一节点“world”的起始位置。

 

 

压缩列表图解分析

整个压缩列表图解如下，大家可以大概看下，具体的后面部分会详细说明。

 

 

表头

表头包括四个部分，分别是内存字节数