ziplist是Redis list、hash、zset的基本实现结构之一，list、hash、zset中节点数少，而且存储的许多节点为小整数型，对于短字符串，Redis为ziplist
以时间为代价，用list换取空间，实现双向链表、ziplist。 实现为双向链表时，节点上有一个pre和next指针，每个指针占用8个字节。 另一方面，在ziplist的entry中，前面的entry的长度用previous_entry_length保存，如果前面的entry的长度在263字节以下，则previous_entry_length只占1字节如果大于263字节，则previous_entry_length占5字节，ziplist存储是连续的内存空间，可以压缩。 ziplist是一种以时间为代价与空间交换的机制，因为在设计计算时，ziplist明显慢于双向链表的指针搜索。
构成
ZL bytes :记录整个zip列表的大小。 zltail:ziplist开始指针与最后一个条目之间的偏移量。 从这个偏移量中得到最后一个entry。 zll en :条目的数量。 entry :存储特定数据的节点。 zlend:ziplist结尾徽标。 entry的每个entry由以下三部分组成：
previous_entry_length :上一个entry的大小。 编码：记录内容的类型和长度。 内容：整形或字节数组。 3358 www.Sina.com/previous _ entry _ length保存最后一个条目的长度。 如果最后一个entry的长度小于或等于263字节，则previous_entry_length只占1字节。 如果大于263字节，则previous_entry_length将占用5个字节。 上次的输入是在previous_entry_length中获得的。 ziplist以这种方式实现从末尾到末尾的搜索。 ziplist连续更新当前，如果ziplist中每个条目的大小为263字节，则每个条目的previous_entry_length仅占1字节。 此时，如果在ziplist头部中插入大于263的条目，则该条目之后的条目将previous_entry_length改变为5字节，并且如果改变后的条目的长度为267，则返回下一个条目。
删除节点可能会连续更新。
如果发生连续更新，ziplist的性能会大幅下降，但实际上很少发生连续更新。 此外，由于ziplist包含少量节点，因此即使发生整个ziplist的更新，也不会占用大量时间。