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命令可以查看特定对象的相关信息。
当压缩列表被转化为普通结构之后，即使将来重新满足压缩列表的要求也不会将其重新转化为压缩列表。
2.2 集合的整数集合编码
如果整数包含的所有成员都可以被解释为十进制整数，而这些整数又处于平台的有符号整数范围之内，并且集合成员的数量又足够少（可配置）的情况之下，那么Redis就会以有序整数数组的形式存储集合，这种存储方式被成为整数集合
配置整数集合可包含的最大元素数量：
set-max-intset-entries 512
2.3 使用短结构的问题
使用短结构可以有效的节省内存，但是由于短结构存储了过少的元素信息，导致查询、插入等操作的时间复杂度上涨，因此对于使用短结构的配置一定尽量合理。不能为了准求低内存而忽略的程序的性能。
