关于redis的底层存储结构的几个问题

ziplist和 intse都是对小对象 比如小的set集合 小的dict 进行压缩存储的t底层数据结构，压缩队列 ziplist 是列表对象和哈希对象的底层实现之一。当满足一定条件时，列表对象和哈希对象都会以压缩队列为底层实现。

列表对象的编码可以是 ziplist 或 linkedlist，当列表对象可以同时满足以下两个条件时，列表对象使用 ziplist 编码：

• 列表对象保存的所有字符串元素的长度都小于 64 字节。

• 列表对象保存的元素数量数量小于 512 个。

哈希对象的编码可以使用 ziplist 或 dict。
当哈希对象可以同时满足以下两个条件时，哈希对象使用 ziplist 编码:

• 哈希对象保存的所有键值对的键和值的字符串长度都小于64字节。

• 哈希对象保存的键值对数量小于512个。

集合对象的编码可以使用 intset 或者 dict。

intset 编码的集合对象使用整数集合最为底层实现，所有元素都被保存在整数集合里边。
而使用 dict 进行编码时，字典的每一个键都是一个字符串对象，每个字符串对象就是一个集合元素，而字典的值全部都被设置为NULL

有序集合的编码可以为 ziplist 或者 skiplist。
有序集合使用 ziplist 编码时，每个集合元素使用两个紧挨在一起的压缩列表节点表示，前一个节点是元素的值，第二个节点是元素的分值，也就是排序比较的数值。压缩列表内的集合元素按照分值从小到大进行排序。有序集合使用 skiplist 编码时使用 zset 结构作为底层实现，一个 zet 结构同时包含一个字典和一个跳跃表。

在如下两个条件之一满足的时候，ziplist会转成dict：

• 当hash中的数据项（即field-value对）的数目超过512的时候，也就是ziplist数据项超过1024的时候

• 当hash中插入的任意一个value的长度超过了64的时候
  Redis的hash之所以这样设计，是因为当ziplist变得很大的时候，它有如下几个缺点：
  每次插入或修改引发的realloc操作会有更大的概率造成内存拷贝，从而降低性能。

• 一旦发生内存拷贝，内存拷贝的成本也相应增加，因为要拷贝更大的一块数据。

• 当ziplist数据项过多的时候，在它上面查找指定的数据项就会性能变得很低，因为ziplist上的查找需要进行遍历。

总之，ziplist本来就设计为各个数据项挨在一起组成连续的内存空间，这种结构并不擅长做修改操作。一旦数据发生改动，就会引发内存realloc，可能导致内存拷贝。

这又是一个需要找平衡点的难题。我们只从存储效率上分析一下：

• 每个quicklist节点上的ziplist越短，则内存碎片越多。内存碎片多了，有可能在内存中产生很多无法被利用的小碎片，从而降低存储效率。这种情况的极端是每个quicklist节点上的ziplist只包含一个数据项，这就蜕化成一个普通的双向链表了。

• 每个quicklist节点上的ziplist越长，则为ziplist分配大块连续内存空间的难度就越大。有可能出现内存里有很多小块的空闲空间（它们加起来很多），但却找不到一块足够大的空闲空间分配给ziplist的情况。这同样会降低存储效率。这种情况的极端是整个quicklist只有一个节点，所有的数据项都分配在这仅有的一个节点的ziplist里面。这其实蜕化成一个ziplist了。

那么为啥小对象不用hash结构 而用list set 作为底层存储 网上解释说 redis目标在于存储 小对象的即使遍历虽没有hash的o1 也性能可接受 但存储节约了。