Redis数据结构详解（4）-为了节约内存的数据结构（压缩列表ziplist） Redis数据结构详解（4）-为了节

前提知识
前面几个文章里我们介绍到了字典dict和跳表skiplist，它们都是redis为了追求性能而开发的基本数据结构，里面或多或少都借助了一些辅助的元素；例如字典dict在rehash时会同时存在两个哈希表，又或者跳表skiplist里节点多了层的结构，这些设计都是为了追求性能而牺牲了内存空间。
【Redis数据结构详解（4）-为了节约内存的数据结构（压缩列表ziplist）】如果你多多少少了解HashMap的底层原理的话，你就知道：
在JDK1.8中，随着元素越来越多，HashMap发生hash冲突，桶中元素大于等于8个，并且容量大于等于64时，会由链表形式转化为红黑树结构；而当桶中元素降到6时又会转换回链表。
为什么有这样的变化呢？因为这体现了时间和空间平衡的思想，元素刚开始并不多时，链表的空间占用是比较少的，并且由于链表短，查询需要的时间也没有太大问题；可是随着链表越来越长，查询的需要的时间也就越来越长，就需要用占用空间大但是查询更高效的红黑树来帮忙了。
时间or空间，看来所有的数据结构都离不开这个命题。
而我们今天要说的压缩列表ziplist就是redis为了节约内存而设计开发的数据结构，并且作为列表键和哈希键的底层实现之一。
压缩列表ziplist的“登场时机”

hash（下面条件满足其一，hash会由压缩列表ziplist结构转成字典dict结构）
- 键值对数目超过512。
- 插入一个value长度超过64的键值对。
sorted set（下面条件满足其一，sorted set会由压缩列表ziplist结构转成zset结构——包含一个dict和一个skiplist）
- 键值对数目超过128。
- 插入一个value长度超过64的键值对。

PS：在ziplist转成其他数据结构后，不会再退为ziplist结构。
压缩列表的结构