简述
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的更新,也不会占用大量时间。