【Redis学习笔记】2018-03-20 压缩列表概念

作者：李乐 顺风车运营研发团队
压缩列表是列表键和哈希键的底层实现之一。

当一个列表键只包含少量列表项，并且每个列表项要么是小整数，要么是长度较短的字符串时，Redis就会使用压缩列表来作为列表键的底层实现；

当一个哈希键只包含少量键值对，并且每个键值对的键和值要么就是小整数值要么就是长度较短的字符串时，Redis就会使用压缩列表来作为哈希键的底层实现；

1. 压缩列表结构（ziplist）

压缩列表是为了节约内存而开发的，其就是一个字节数组（char *）；

而一个压缩列表可以包含任意多个节点（entry），每个节点可以保存一个字节数组或一个整数；

zlbytes：4字节，压缩列表的长度；因此压缩列表最大(2^32)-1字节；

zltail：4字节，尾节点偏移量；

zllen：2字节，压缩列表节点数目，其最大只能表示65535个节点；当压缩列表节点数目超过65535后，此字段无就没有任何意义了；

entryX：节点

zlend：压缩列表结尾标志，固定为0xFF；

假设char * zl指向压缩列表首地址；

注意：zl指针的类型为char*，因此通过zl获取相应字段时，首先需要强制类型转换；

zl指向zlbytes字段；((uint32_t) zl)取出zlbytes字段内容；

zl+4指向zltail字段；((uint32_t) (zl+4))取出zltail字段内容；

((uint32_t) (zl+4)) + zl （就是zl+zltail）指向最后一个节点首地址

zl+8指向zllen字段；((uint16_t) (zl+8))取出zllen字段内容；

zl + ((uint32_t) zl) （就是zl+zlbytes）指向zlend字段

1. 节点（entry）结构

了解了压缩列表结构，我们可以很容易获得压缩列表空间大小，压缩列表拥有节点数目，压缩列表开始和结束位置指针；

那么如何遍历压缩列表的所有节点呢？

对于每一个entry节点，存储的可能是字节数组或整数值；

假设我们知道节点首地址指针，我们如何知道存储的是什么类型？对于字节数组，我们又如何知道字节数组的长度？

redis是对每一个entry是这样编码的：

2.1 首先回答上面一个问题：压缩列表如何遍历所有节点？

答案就在previous_entry_length字段，其表示前一个节点的长度（单位字节）；

假如我知道当前节点的首地址为p，那么（p-previous_entry_length）就是前一个节点的首地址；通过这种方式实现了从尾到头的遍历；

previous_entry_length字段为1个或者5个字段（为了节约内存）；

当前一个节点的长度小于254字节时，previous_entry_length字段用一个字段表示；

当前一个节点的长度大于等于254时，previous_entry_length字段用5个字节来表示；而这时候previous_entry_length的第一个字节是固定的标志0xFE，后面4个字节才真正表示前一个节点的长度；

假设当前节点首地址为p；p[0]为第一个字节内容；

当p[0]<0xFE时，说明previous_entry_length字段只占一个字节，p[0]就是前一个节点的长度；

当p[0]=0xFE时，说明previous_entry_length字段占5个字节，p[1]~p[4]表示前一个节点的长度；而p+5则只encoding字段首地址；

2.2 下面回答第二个问题：

如何区分当前节点存储数据是什么类型，字节数组还是整数？字节数组长度？

最简单的方法：使用1个比特表示数据是字节数组还是整数，假如是字节数组，再用7+4*8表示字节数组的长度；

但是，redis为了节约内存并没有这么做；（减少encoding字段长度）

字节数组分为三种，最大长度63字节，最大长度(2^14)-1，最大长度(2^32)-1；

整数分为6种：8比特整数，24比特整数，int16，int32，int64，0~12立即数；

而具体的数据内容存储在content字段；

我们发现encoding第一个字节的前2比特可以区分是字节数组（以及字节数组类型）还是整数；

是整数时，第3、4比特可以区分整数的类型；当content的前4个比特都是1时，后4个比特才能区分整数类型；

假设encoding字段首地址为p；p[0]为第一个字节内容；

p[0] & 0xc0 可以获得前两个比特bit[1:2]，当其不等于11B时，说明content是字节数组；再根据其是00B、01B还是10B可以知道字节数组类型，从而取出字节数组实际长度；

整数类型的判断同理可得；

1. 预备知识

2.1 大端小端

redis在存取压缩列表字段（如zlbytes、zltail时，会进行大小端转换；如果是小端不做处理，如果是大端，会转换为小端字节顺序）；

大小端转换其实就是交换字节顺序；

void memrev32(void *p) {
    unsigned char *x = p, t;
    t = x[0];
    x[0] = x[3];
    x[3] = t;
    t = x[1];
    x[1] = x[2];
    x[2] = t;
}

问题：为什么在存取压缩列表字段时需要做大小端转换？

解答：redis集群，各机器的CPU架构可能不相同；有些机器是大端，有些机器是小端；假如不进行大小端转换，当压缩列表数据在集群中机器间传递时，不同机器解析情况会不相同。

1. 连锁更新

如图，位置p处的节点为X；其previous_entry_length字段为1个字节，0x80，表明前一个节点长度为128；假设位置p之后的所有节点的长度为253字节；

现在往位置p新添加一个节点，其长度为1024字节；显然节点X的previous_entry_length需要改变为5个字节，那么此时节点X的长度为257字节；

节点X的长度从253改变为257字节；那么节点X的后驱节点的previous_entry_length也需要从一个字节改变为5个字节；

以此类推；因为在位置P新添加了一个节点，可能导致P后面得所有节点都需要依次更新previous_entry_length字段长度；

这就是连锁更新；他会导致N次内存分配，效率很低；

但是需要指出的是，这种情况出现的概率是很低的；而且一般情况下压缩列表存储的节点数目比较少；因此redis并没有对这种情况做特殊处理；