redis_列表对象
《Redis设计与实现》中说：redis列表对象有两种底层编码格式：ziplist、linkedlist，其中ziplist用压缩列表实现、linkedlist用双向链表实现
但我在实践中，没有发现linkedlist的使用，而发现了一种叫"quicklist"的type，意为一个由ziplist组成的双向链表
首先了解列表对象的结构
// redis对象内存分配，列出主要相关的属性
redisObject {
// 对于列表对象，type = REDIS_LIST
type
// 列表对象的底层编码格式，有三种：ziplist、linkedlist、quicklist
encoding
// 指向实际保存列表内容的空间
ptr
// 还有其他属性
......
}
上面的redisObject不实际保存列表内容，而是通过ptr指向实际保存列表内容的空间
根据编码格式的不同，ptr所指向的空间的结构会有所区别
ziplist编码
ziplist的实现为压缩列表，这个结构在redis中经常用到，
核心思想：能不用指针就不用指针，尽量依靠"记录各个节点、头尾之间的字节偏移量，来达到指针的效果"
一个基本的压缩列表其空间分配如下：
zlbytes：4字节，记录整个压缩列表占用的字节大小
zltail：4字节，记录"tail数据节点的起止地址"距离"整个压缩列表起始地址"的字节偏移量
zllen：2字节，记录节点数量（2直接最大只能存65536，所以当zllen<65536时是准确值，zllen=65536时，需要遍历才能知道准确值）
entryX：实际保存的数据，长度就不固定了
zlend：1字节，内容为0xFF，是压缩列表的结束标志
其中每个entryX，其内部结构由 previous_entry_length 、 encoding 、 content 三个部分组成：
previous_entry_length：保存了前一个entry节点的总长度
- 如果前驱的长度<254字节，那么previous_entry_length采用 1字节
- 如果前驱的长度>=254字节，那么previous_entry_length采用 5字节，其中第一字节内容固定为0xFE（254），后四个字节来保存前驱的长度。（好像没有考虑过前驱超级长，比 2^8 * 5 还长的情况）
encoding：保存content中数据的类型
content：存数据。整数就直接是整数、字符串是字符串对象
ziplist这种结构的好处：
- 数据连续且很紧凑，空间利用效率好
存在的问题：
- 不利于增删数据，需要频繁修改内存
- 存在"连锁更新"问题：
- 有这样一种情况，列表中有一串节点，大小比如都是253字节
- 突然在其中插入了一个大小为600字节的节点，这时其next节点本身只用1字节来保存pre节点的大小，现在不行了，需要改成5字节
- 改成5字节后，next节点大小变成了253-1+5=257字节，next的next也不能再用1字节了，也得扩
- ......
- 当在一串大小临界的节点中插入一个大数据时，会出现连锁更新现象，导致频繁分配内存
- 在一串大小刚刚超过254的节点中删除一个小数据时，也会出现类似的情况，频繁缩小内存
- 问题本身不常遇到
应用场景：
- 列表较短，并且数据都是小整数值、短字符串
- 当一个哈希键只包含少量kv对、且key和value都是小整数值、短字符串时，redis也会使用压缩列表来做
-
127.0.0.1:6379> hmset profile "name" "jack" "age" 28 OK 127.0.0.1:6379> object encoding profile "ziplist"
linkedlist编码
没有很特别，ptr指向一个双端链表
quicklist编码
《Redis设计与实现》中没有具体写。其结构为 A doubly linked list of ziplists，一个由ziplist组成的双向链表
其本身还是一个双向链表，但链表的每个节点不只保存一个数据，而是保存着一个ziplist
我理解是ziplist和linkedlist的一种结合：从整体上看整个list是不连续的，每个节点之间依靠指针访问。从局部上看数据是连续的，每个节点内依靠压缩列表实现，提高空间利用效率
micheal.li > mikeve@163.com
