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
- 上一篇: 记忆之北京马拉松
- 下一篇: PHP+Hadoop实现数据统计分析
解决一下如何登上ins比较靠谱[ali转]