Redis Ziplist (一)

redis的压缩列表(ziplist)是列表键和哈希键的底层实现之一。当一个列表键只包含少量列表项,并且每个列表项要么就是小整数值,要么就是长度比较短的字符串,那么Redis就会使用压缩列表来做列表键的底层实现。这个在redis配置文件里有几个配置选项。

hash-max-zipmap-entries 512  //entry的总数不能大于512,否则就采用hashmap/链表/跳跃表结构存储
hash-max-zipmap-value 64 //每个entry值的长度不能大于64个字节,
list-max-ziplist-entries 512
list-max-ziplist-value 64
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

上面的几个选项都可以调整,压缩表的存在也是为了提升性能,毕竟是一个内存存储数据。

ziplist结构

一个压缩表的结构由以下几个部分构成:

zlbytes zltail zllen entry entry ... zlend
结构 类型 布局说明
zlbytes uint32_t (4个字节) ziplist总字节数
zltail uint32_t (4个字节) 列表中最后一个entry元素起始距离的偏移量,也就是距离开始由多少个字节
zllen uint16_t (2个自己 列表里有多少个entry,当有超过216-2个条目,此值设置为216-1,超过的话需要遍历整个ziplist才知道
entry 列表里的每一个存储的值
zlend uint8_t(1个字节) 表示ziplist结尾的一个特殊值,编码为单字节等于255

压缩表中的每个entry都大体上包含以下3个部分:

上一个entry的长度 编码 数据(0-12小的整数时没有)
prevlen encoding entry-data
  1. prevlen存储是为了能够逆序遍历,有了上一个。

  2. entry编码是为了区分字符串和整数,如果是整数(0-12),值也是存储在编码中的。

  3. entry-data 这个部分存储字符串类型的值。

prevlen 上一个entry长度

如果entry的长度如果小于254个字节,它只占用一个单字节表示长度为8个位的无符号数,当长度大约或等于254时,占用5个字节,第一个字节是设置为254(fe)作为一个标记,代表后边有一个大的值,其余4个字节表示上一个entry长度的值。看起来大概会是这样

小于254个字节
prevlen encoding entry-data

或者

0xFE(标记)+prevlen(4个字节的数代表entry真正的长度)
prevlen encoding entry-data

但这有个问题,如果已有的压缩表中每个元素的长度都小于254个字节,现在在表头添加一个元素entry,并且这个元素长度大于了254,那么这个时候一个单字节明显就存储不下,需要5个字节存储,那后边的每个元素都需要重新分配存储空间,除了更新,删除也是因为每个元素都会存储上一个元素的长度,所以同样存在这种问题。

虽然看起来每次都要重新分配存储空间很浪费性能,其实不然,首先压缩表这种数据结构本身存储的数据就很少,其次也得有很多连续存在的元素的长度都是小于254个字节的才有可能引发更新,再者更新也是针对需要重新分配空间的节点,不多的情况下也不会影响性能。

encoding

entry的编码取决于他的值,如果是整数那encoding的前2个bit(位)都是11,后边的2个bit用户指定后边存储哪种整数,如果是字符串的话,那前2个bit表示存储字符串长度的编码类型,后边跟上字符串的实际长度。

字符串:
整数:
11000000 长度
|11000000| 1个字节 代表后边的entry-data的值存储int16_t的整数值
|11010000| 1个字节 int32_t整数类型的值
|11100000| 1个字节 int64_t整数类型的值
|11110000| 1个字节 24 bit,也就是3个字节的整数的值
|11111110| 1个字节 8 bit,1个字节的整数的值
|1111xxxx| 1个字节 这种的话entry-data就为空了,整数的值在编码里包含了,xxxx介于0000到1101之间,也就是0-12之间。实际是1-13,因为0000和1111不能使用,所以应该从4位值中减去以获得正确的值。(1111会跟zlend冲突,试想如果是最后一个元素。0000是因为会跟前面几个类型冲突,当然1110也会冲突,这也就是为什么只能表示介于0000到1101之间)
entry-data:

这里存储的就是真正的值了,可以是一个字节数组或者整数,值的类型和长度由节点的encodingb编码决定。

prevlen encoding entry-data
假设上一个长度12 00001011 hello world

官方的例子:

假设有2和5两个字符串需要存储,那么压缩表的结构如下(16进制表示):

zlbytes zltail zllen entry entry zlend
0f 00 00 00 0c 00 00 00 02 00 00 f3 02 f6 ff
占用15个字节数 偏移量为12 2个元素 prevlen为0,(占用1个单字节) prevlen占用2个字节所以为2 结束标记
encoding对应1111xxxx,XXXX介于 0001和1101之间,也就是1到12之间,f3的二进制11110011根据1111xxxx去掉 1111剩下0011减去1等于2,2的二进制 00000010加1,00000011 2属于0到12之间满足1111xxxx 编码,那么存储就是11110011 转为16进制就是f3(占用一个字节) 和上一个entry一样
entry-data 丢失

如果继续查入一个字符串,比如"hello world",那么entry表示如下:

prevlen encoding entry-data
02 0b 48 65 6c 6c 6f 20 57 6f 72 6c 64
上一个entry的字节长度为2 小于254占用一个字节,匹配00pppppp,00代表编码pppppp表示实际长度 字符长度11,11的二进制是1011, 001011转为16进制就是0b

ziplist API

未完待续。。。

你可能感兴趣的:(Redis Ziplist (一))