基本概述
ZipList 是一种特殊的“双端链表” ，由
一系列特殊编码的连续内存块组成。可以在任意一端进行压入/弹出操作, 并且该操作的时间复杂度为 O(1)。
基本结构：
各部分所占字节、基本介绍：
entry，节点占用字节不固定（按需分配、节省内存）
ZipListEntry
ZipList 中的Entry并不像普通链表那样记录前后节点的指针，因为记录两个指针要占用16个字节，浪费内存。而是采用了下面的结构：
previous_entry_length：前一节点的长度，占1个或5个字节。- 如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值
- 如果前一节点的长度大于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据
encoding：编码属性，记录content的数据类型（字符串还是整数）以及长度，占用1个、2个或5个字节contents：负责保存节点的数据，可以是字符串或整数
ZipListEntry中的encoding编码分为字符串和整数两种：
详细见 p150（黑马redis）
- 字符串： 如果encoding是以“00”、“01”或者“10”开头，则证明content是字符串（一般用上面两种）
- 整数： 如果encoding是以“11”开始，则证明content是整数，且encoding固定只占用1个字节
虽节省内存但遍历有一定缺陷，只能从前向后或者从后向前，使用时对节点个数会有一定限制
ZipList的连锁更新问题
ZipList的每个Entry都包含previous_entry_length来记录上一个节点的大小，长度是1个或5个字节：
- 如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值
- 如果前一节点的长度大于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据
有这样一种出现概率极低的场景：有N个连续的、长度为250~253字节之间的entry，因此entry的previous_entry_length属性用1个字节即可表示，如图所示：
此时，在列表节点头部插入一个254bytes的节点，会导致连续更新节点previous_entry_length字节长度（连续多个字节长度由1变为5），多出许多挪动节点位置以及申请额外空间的开销
ZipList这种特殊情况下产生的连续多次空间扩展操作称之为连锁更新（Cascade Update）。新增、删除都可能导致连锁更新的发生。
特性
① 压缩列表的可以看做一种连续内存空间的"双向链表"
② 列表的节点之间不是通过指针连接，而是记录上一节点和本节点长度来寻址，内存占用较低
③ 如果列表数据过多，导致链表过长，可能影响查询性能（只能从前向后或者从后往前遍历）
④ 增或删较大数据时有可能发生连续更新问题（概率极低）
