UDN-企业互联网技术人气社区

板块导航

浏览  : 555
回复  : 1

[讨论交流] Redis内存优化实践

[复制链接]
genie1003的头像 楼主
发表于 2016-7-20 10:46:19 | 显示全部楼层 |阅读模式
   最近做的一个系统大量使用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的对象做一层封装:
  1. typedef struct redisObject {
  2.     unsigned type:4;
  3.     unsigned encoding:4;
  4.     unsigned lru:LRU_BITS; /* lru time (relative to server.lruclock) */
  5.     int refcount;
  6.     void *ptr;
  7. } robj;
复制代码

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

  但如果使用了上面提到的ziplist,redis对ziplist里元素做了裁剪,让数据更紧凑,所以针对数字,做了一些特别处理:
  1. * |11000000| - 1 byte
  2. * Integer encoded as int16_t (2 bytes).
  3. * |11010000| - 1 byte
  4. * Integer encoded as int32_t (4 bytes).
  5. * |11100000| - 1 byte
  6. * Integer encoded as int64_t (8 bytes).
  7. * |11110000| - 1 byte
  8. * Integer encoded as 24 bit signed (3 bytes).
  9. * |11111110| - 1 byte
  10. * Integer encoded as 8 bit signed (1 byte).
  11. * |1111xxxx| - (with xxxx between 0000 and 1101) immediate 4 bit integer.
  12. * Unsigned integer from 0 to 12. The encoded value is actually from
  13. * 1 to 13 because 0000 and 1111 can not be used, so 1 should be
  14. * subtracted from the encoded 4 bit value to obtain the right value.
复制代码

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

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

  如果能用数字,还是尽量使用数字类型,并且是小于10000的数字最好,因为:
  1. #define OBJ_SHARED_INTEGERS 10000
复制代码

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

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

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

原文作者:Henry Ford 来源:github

相关帖子

发表于 2016-7-20 11:41:33 | 显示全部楼层
赞一个
使用道具 举报

回复

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部