Redis Ziplist（压缩列表）

简述

ziplist是Redis list、hash、zset的底层实现结构之一，当list、hash、zset中节点数量较少，并且存储的大多节点为小整数型，较短的字符串时，Redis就会使用ziplist作为list、hash、zset的底层实现。

牺牲时间换取空间

拿list来说，实现有双向链表、ziplist。当实现为双向链表时，节点会有pre和next指针，每一个指针占8个字节。而ziplist的entry中，用previous_entry_length保存上一个entry的长度，当上一个entry长度小于等于263字节时，previous_entry_length只占一个字节；大于263字节时，previous_entry_length占5个字节，并且ziplist存储是连续的内存空间，可以做压缩。当设计计算时，ziplist明显会比双向链表的指针检索慢，因此ziplist是牺牲时间换取空间的结构。

结构

• zlbytes：记录整个ziplist的大小。
• zltail：ziplist开始指针与最后一个entry之间的偏移量，通过该偏移量可以获得最后一个entry。
• zllen：entry数量。
• entry：存储具体数据的节点。
• zlend：ziplist结尾标识。

entry

每一个entry由以下三个部分组成。

• previous_entry_length：上一个entry的大小。
• encoding：记录content的类型以及长度。
• content：一个整形或者字节数组。
  注：

1. previous_entry_length保存上一个entry的长度，当上一个entry长度小于等于263字节时，previous_entry_length只占一个字节；大于263字节时，previous_entry_length占5个字节。
2. 可以通过previous_entry_length得到上一个entry，ziplist就是这样实现从尾到头的检索。

ziplist连续更新

假如现在ziplist中每一个entry的大小都是263字节，那么每一个entry的previous_entry_length都只占一个字节。假如此时在ziplist头部插入一个大于263的entry，那么，该entry往后的entry要把previous_entry_length修改为5个字节，而此时修改之后entry长度变为267，那么再下一个entry也要修改previous_entry_length的长度，以此类推。。。
删除节点的时候也会出现连续更新的情况。
虽然，发生连续更新时，ziplist的性能会大大的降低，但是实际情况下，极少会发生连续更新，而且ziplist都是存储少量的节点，哪怕发生一整个ziplist的更新，也不会占用大量时间。