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-ziplistzset-max-ziplist

标签: redis

仅有一条评论

  1. 11 11

    解决一下如何登上ins比较靠谱[ali转]