最近做的一个系统大量使用redis，我们将大量的用户信息存放在redis中，内存一申请就是几百G，体量也是相当庞大。所以我们也在不断的想方法优化减少redis的内存使用，把我们的优化实践也分享出来。

采用Hash代替<K,V>键值对存储

因为是存放用户维度的数据，用户id(uid)往往会作为key，而一个用户会有多个信息，比如年龄，生日等等，比较容易想到的存储结构会采用Hash，将一个用户的多个信息作为hash里的不同field来存放

善用Hash，List，ZSet的ziplist压缩特性

Redis针对Hash，List，ZSet都实现了ziplist的压缩存储，可以通过配置最大元素不超过512，每个元素大小不超过64bytes，来判断是否要采用!ziplist压缩格式存储。

注意:虽然这个ziplist是否启用做成了配置参数，但对这个配置参数的修改要谨慎，因为ziplist是一个连续的数组空间，查找效率不是O(1)的，如果设置元素超过512太多，可能导致查找效率降低，反而影响性能。那为什么Redis会采用512*64bytes这样的默认配置呢？据说是这个大小可以被加载进CPU的Cache里，所以即使不是O(1)，查找效率也是很快的。

优先使用数字类型，比String类型省空间

在Redis的内部，不管是数字类型，String类型，都会统一用一个叫redisObject的对象做一层封装:

typedefstructredisObject{unsignedtype:4;unsignedencoding:4;unsignedlru:LRU_BITS;/*lrutime(relativetoserver.lruclock)*/intrefcount;void*ptr;}robj;

可见，一个简简单单的”hello world”在redis里都不是直接11个bytes就搞定的，还有很多附加的属性，比如引用计数(内存回收)refcount，lru清理等信息。

但如果使用了上面提到的ziplist，redis对ziplist里元素做了裁剪，让数据更紧凑，所以针对数字，做了一些特别处理：

*|11000000|-1byte*Integerencodedasint16_t(2bytes).*|11010000|-1byte*Integerencodedasint32_t(4bytes).*|11100000|-1byte*Integerencodedasint64_t(8bytes).*|11110000|-1byte*Integerencodedas24bitsigned(3bytes).*|11111110|-1byte*Integerencodedas8bitsigned(1byte).*|1111xxxx|-(withxxxxbetween0000and1101)immediate4bitinteger.*Unsignedintegerfrom0to12.Theencodedvalueisactuallyfrom*1to13because0000and1111cannotbeused,so1shouldbe*subtractedfromtheencoded4bitvaluetoobtaintherightvalue.

先用1byte来表示不同的encode，针对大小不同的数字，分别采用不一样的内存空间来存储，比如0-127就是2个字节，128-32768就是4个字节等等。所以算下来，和String相比，大部分情况下更省内存。

另外，如果不是采用ziplist的存储方式，而是直接用redisObject这样相对庞大的对象存储呢？

如果能用数字，还是尽量使用数字类型，并且是小于10000的数字最好，因为：

#defineOBJ_SHARED_INTEGERS10000

redis考虑到redisObject这个庞大的对象占用过多内存的因素，将10000以下数字的redisObject做了一个对象池，其他地方都通过指针(4/8bytes)引用这个池里的redisObject，而不是各自存一份。

注: 以上都是针对Redis 3.2之前版本的分析，因为Redis 3.2对内存优化这部分做了很多改进，具体的改进点还未了解清楚。

最后，对坚持看完的同学送上一个非常有用的Redis内存分析工具:redis-rdb-tools，结合bgsave的dump文件，分析redis里的数据，可以看到底层存储是用的什么数据结构，占用了多少空间等信息。