redis——数据结构（整数集合，压缩列表）
4、整数集合
整数集合（intset）是 Redis 用于保存整数值的集合抽象数据结构， 可以保存 int16_t 、 int32_t 、 int64_t 的整数值， 并且保证集合中不会出现重复元素。
实现较为简单：
typedef struct intset {
// 编码方式
uint32_t encoding;
// 集合包含的元素数量
uint32_t length;
// 保存元素的数组
int8_t contents[];
} intset;各个项在数组中从小到大有序地排列， 并且数组中不包含任何重复项。
虽然 intset 结构将 contents 属性声明为 int8_t 类型的数组， 但实际上 contents 数组并不保存任何 int8_t 类型的值 —— contents 数组的真正类型取决于 encoding 属性的值：
如果 encoding 属性的值为 INTSET_ENC_INT16 ， 那么 contents 就是一个 int16_t 类型的数组， 数组里的每个项都是一个 int16_t 类型的整数值 （最小值为 -32,768 ，最大值为 32,767 ）。
如果 encoding 属性的值为 INTSET_ENC_INT32 ， 那么 contents 就是一个 int32_t 类型的数组， 数组里的每个项都是一个 int32_t 类型的整数值 （最小值为 -2,147,483,648 ，最大值为 2,147,483,647 ）。
如果 encoding 属性的值为 INTSET_ENC_INT64 ， 那么 contents 就是一个 int64_t 类型的数组， 数组里的每个项都是一个 int64_t 类型的整数值 （最小值为 -9,223,372,036,854,775,808 ，最大值为 9,223,372,036,854,775,807 ）。
升级
c语言是静态类型语言，不允许不同类型保存在一个数组。这样第一，灵活性较差，第二，有时会用掉不必要的内存
比如用long long储存1
为了提高整数集合的灵活性和节约内存，我们引入升级策略。
当我们要将一个新元素添加到集合里， 并且新元素类型比集合现有元素的类型都要长时， 集合需要先进行升级。
分为三步进行：
- 根据新元素的类型， 扩展整数集合底层数组的空间大小， 并为新元素分配空间。
- 将底层数组现有的所有元素都转换成与新元素相同的类型， 并将类型转换后的元素放置到正确的位上
- 将新元素添加到底层数组里面。
因为每次添加新元素都可能会引起升级， 每次升级都要对已有元素类型转换， 所以添加新元素的时间复杂度为 O(N) 。
因为引发升级的新元素比原数据都长，所以要么他是最大的，要么他是最小的。我们把它放在开头或结尾即可。
降级
略略略，不管你们信不信，整数集合不支持降级操作。。我也不知道为啥
5、压缩列表
压缩列表是列表键和哈希键的底层实现之一。
当一个列表键只包含少量列表项，并且列表项都是小整数或者短字符串，redis就会用压缩列表做列表键底层实现。
压缩列表是 Redis 为了节约内存而开发的， 由一系列特殊编码的连续内存块组成的顺序型（sequential）数据结构。
一个压缩列表可以包含任意多个节点（entry）， 每个节点可以保存一个字节数组或者一个整数值。
具体实现：
具体说一下entry：
由三个部分组成：
1、previous_entry_length:记录上一个节点的长度，这样我们就可以从最后一路遍历到开头。
2、encoding：记录了content所保存的数据类型和长度。（具体编码不写了，不重要）
3、content：保存节点值，可以是字节数组或整数。（具体怎么压缩的等我搞明白再补）
连锁更新
前面说过， 每个节点的 previous_entry_length 属性都记录了前一个节点的长度：
- 如果前一节点的长度<
254KB， 那么previous_entry_length需要用1字节长的空间 - 如果前一节点的长度>=
254KB， 那么previous_entry_length需要用5字节长的空间
现在， 考虑这样一种情况： 在一个压缩列表中， 有多个连续的、长度介于 250 字节到 253 字节之间的节点 ，这时， 如果我们将一个长度大于等于 254 字节的新节点 new 设置为压缩列表的表头节点。。。。
然后脑补一下，就会导致连锁扩大每个节点的空间对吧？e(i)因为e(i-1)的扩大而扩大，i+1也是如此，以此类推。。。
删除节点同样会导致连锁更新。
这个事情只是想说明一个问题：插入删除操作的最坏时间复杂度其实是o(n*n)，因为每更新一个节点都要o(n)。
但是，也不用太过担心，因为这种特殊情况并不多见，这些命令的平均复杂度依旧是o(n)。