本文主要是介绍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：一个整形或者字节数组。
注：
previous_entry_length保存上一个entry的长度，当上一个entry长度小于等于263字节时，previous_entry_length只占一个字节；大于263字节时，previous_entry_length占5个字节。- 可以通过
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的更新，也不会占用大量时间。
这篇关于Redis Ziplist（压缩列表）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
