在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
点击
阅读原文 查看
文章列表
