Redis 内存优化案例

在Redis的配置文件中有这么两项配置： hash-max-ziplist-entries 512 hash-max-ziplist-value 64 其中的‘ziplist’代表数据结构，是一种数据压缩方式，作用是减少内存的使用空间 在某个阀值范围内，hashtable会使用ziplist，对数据进行压缩，超出阀值后，会自动转为使用正常的hashmap结构 上面这两项就是定义这个阀值 hash-max-ziplist-entries 512 当hashtable中的条目数量在512以下时，使用ziplist hash-max-ziplist-value 64 当hashtable中每个key/value的长度都小于64字节时，使用ziplist 以上2个条件中，任意一个条件超过设置值时，就不再使用ziplist了 案例 之前在网上看过一个案例，介绍了Instagram使用这项配置的实践经验 Instagram是一个超大型的图片类应用，他们有一个需求：

根据图片ID得到作者ID 最简单的实现方式就是使用string类型

图片ID为KEY，作者ID为VALUE，一条一条的set/get 经测试，图片量为3亿时，一共需要20G左右的内存 经过一些优化后，效果不明显，他们便向Redis的一个开发者咨询解决方案

得到的建议是： 对数据进行分段，使用hash结构 因为hash结构在一定数据量下会进行压缩存储，可以节约很多内存 经过反复测试，在他们的环境下，entries阀值为1000时最合适，超过的话，CPU的压力较大 所以，数据分段的方式为： 1000条数据为一段，放在一个hash表中 例如 图片ID为1234888 他在一个hash表中，这个hash表的key为 1234，里面有1000个field，其中就包括了 888，值为其作者ID

取1234888的作者ID时，就是取得key为1234的hashtable中field为888的值 经过测试，使用这种方式后，内存的使用量降到了5G左右，效果非常明显 类似的配置项还有：

list-max-ziplist、zset-max-ziplist