1.Redis降低内存占用方案

短结构

对于列表、散列、集合、有序集合在长度较短或者体积较小的时候，Redis可以使用一种名为 `压缩列表` 的紧凑存储方式来存储这些结构。
压缩列表会以序列化的方式存储数据，这些序列化数据每次被读取的时候都要进行解码，每次被写入的时候也要进行局部的重新编码，并且可能需要对内存里的数据进行移动

分片结构

基于某些简单规则将数据划分为更小的部分，然后根据数据所属的部分来决定将数据存储在具体的位置。需要应用程序自己来设计实现，同时它依赖于短结构的配置来进行配合使用

2.短结构

2.1 压缩列表

以列表为例，列表是由双向链表实现，它的每一个节点包含：前驱节点指针、后继节点指针、指向字符串的指针。每个节点包含的字符串的值分三部分进行存储：字符串的长度、存储的字符串数组中可用的字节数、以空字符结尾的字符串本身。
因此对于一个列表中的一个节点而言它需要占用：3个指针、2个整数、字符串自身的存储空间以及一个额外的字节（结尾符）。在32位平台上相当于多付出了21个字节的额外开销。
压缩列表中的节点由两个长度值、一个字符串组成。第一个长度值为前一个节点的长度，它将被用于对压缩列表进行从后向前的遍历，第二个长度值为当前节点的长度，而位于节点最后的则是字符串本身。因此压缩列表本身更加的节省空间。
Redis默认会开启对于不同数据结构使用压缩列表的配置。
具体配置参数如下：

#这些配置都由*-max-ziplist-entries和*-max-ziplist-value组成
#*-max-ziplist-entries说明列表、集合、散列被编码为压缩列表允许包含的最大元素数量
#*-max-ziplist-value说明的压缩列表每个节点最大的体积是多少个字节
#当这些选项中任何一个被突破的时候，Redis就会将相应的列表、集合、散列转化为其他的数据结构，相应的内存占用也会增加
list-max-ziplist-entries 512
list-max-ziplist-value 64

hash-max-ziplist-entries 512
hash-max-ziplist-value 64

zset-max-ziplist-entries 512
zset-max-ziplist-value 64

附：debug object命令可以查看特定对象的相关信息。

当压缩列表被转化为普通结构之后，即使将来重新满足压缩列表的要求也不会将其重新转化为压缩列表。