开发者社区> 付磊-起扬> 正文

美团在Redis上踩过的一些坑-4.redis内存使用优化

简介:   转载请注明出处哈:http://carlosfu.iteye.com/blog/2254154       一、背景: 选择合适的使用场景    很多时候Redis被误解并乱用了,造成的Redis印象:耗内存、价格成本很高:    1. 为了“赶时髦”或者对于Mysql的“误解”在一个并发量很低的系统使用Redis,将原来放在Mysql数据全部放在Redis中。
+关注继续查看
 

转载请注明出处哈:http://carlosfu.iteye.com/blog/2254154


    

 一、背景: 选择合适的使用场景
   很多时候Redis被误解并乱用了,造成的Redis印象:耗内存、价格成本很高:
   1. 为了“赶时髦”或者对于Mysql的“误解”在一个并发量很低的系统使用Redis,将原来放在Mysql数据全部放在Redis中。
     ----(Redis比较适用于高并发系统,如果是一些复杂Mis系统,用Redis反而麻烦,因为单从功能讲Mysql要更为强大,而且Mysql的性能其实已经足够了。)
   2. 觉得Redis就是个KV缓存
     -----(Redis支持多数据结构,并且具有很多其他丰富的功能)
   3. 喜欢做各种对比,比如Mysql, Hbase, Redis等等
    -----(每种数据库都有自己的使用场景,比如Hbase吧,我们系统的个性化数据有1T,此时放在Redis根本就不合适,而是将一些热点数据放在Redis)
    总之就是在合适的场景,选择合适的数据库产品。
  附赠两个名言:
Evan Weaver, Twitter, March 2009 写道
Everything runs from memory in Web 2.0!
Tim Gray 写道
Tape is Dead, Disk is Tape, Flash is Disk, RAM Locality is king.
(磁带已死,磁盘是新磁带,闪存是新磁盘,随机存储器局部性是为王道)
  
二、一次string转化为hash的优化
1. 场景:
    用户id: userId,
    用户微博数量:weiboCount    
userId(用户id) weiboCount(微博数)
1 2000
2

10

3

288

.... ...
1000000 1000
 
2. 实现方法:
(1) 使用Redis字符串数据结构, userId为key, weiboCount作为Value
(2) 使用Redis哈希结构,hashkey只有一个, key="allUserWeiboCount",field=userId,fieldValue= weiboCount
(3) 使用Redis哈希结构,  hashkey为多个, key=userId/100, field=userId%100, fieldValue= weiboCount
前两种比较容易理解,第三种方案解释一下:每个hashKey存放100个hash-kv,field=userId%100,也就是
userId hashKey field
1 0 1
2 0

2

3 0

3

... .... ...
99 0 99
100 1 0
101 1 1
.... ... ...
9999 99 99
100000 1000 0

 

注意:

为了排除共享对象的问题,在真实测试时候所有key,field,value都用字符串类型。

 

3. 获取方法:

 

#获取userId=5003用户的微博数
(1) get u:5003
(2) hget allUser u:5003
(3) hget u:50 f:3

 

 

4. 内存占用量对比(100万用户 userId u:1~u:1000000) 

  

#方法一 Memory
used_memory:118002640
used_memory_human:112.54M
used_memory_rss:127504384
used_memory_peak:118002640
used_memory_peak_human:112.54M
used_memory_lua:36864
mem_fragmentation_ratio:1.08
mem_allocator:jemalloc-3.6.0
---------------------------------------------------
#方法二 Memory
used_memory:134002968
used_memory_human:127.80M
used_memory_rss:144261120
used_memory_peak:134002968
used_memory_peak_human:127.80M
used_memory_lua:36864
mem_fragmentation_ratio:1.08
mem_allocator:jemalloc-3.6.0
--------------------------------------------------------
#方法三 Memory
used_memory:19249088
used_memory_human:18.36M
used_memory_rss:26558464
used_memory_peak:134002968
used_memory_peak_human:127.80M
used_memory_lua:36864
mem_fragmentation_ratio:1.38
mem_allocator:jemalloc-3.6.0

  

 那么为什么第三种能少那么多内存呢?之前有人说用了共享对象的原因,现在我将key,field,value全部都变成了字符串,仍然还是节约很多内存。

 之前我也怀疑过是hashkey,field的字节数少造成的,但是我们下面通过一个实验看就清楚是为什么了。当我将hash-max-ziplist-entries设置为2并且重启后,所有的hashkey都变为了hashtable编码。

 同时我们看到了内存从18.36M变为了122.30M,变化还是很大的。

 

127.0.0.1:8000> object encoding u:8417
"ziplist"
127.0.0.1:8000> config set hash-max-ziplist-entries 2
OK
127.0.0.1:8000> debug reload
OK
(1.08s)
127.0.0.1:8000> config get hash-max-ziplist-entries
1) "hash-max-ziplist-entries"
2) "2"
127.0.0.1:8000> info memory
# Memory
used_memory:128241008
used_memory_human:122.30M
used_memory_rss:137662464
used_memory_peak:134002968
used_memory_peak_human:127.80M
used_memory_lua:36864
mem_fragmentation_ratio:1.07
mem_allocator:jemalloc-3.6.0
127.0.0.1:8000> object encoding u:8417
"hashtable"
 

 

 

 

 

  内存使用量:

 

  

5. 导入数据代码(不考虑代码优雅性,单纯为了测试,勿喷)
    注意:
为了排除共享对象的问题,这里所有key,field,value都用字符串类型。
 
package com.carlosfu.redis;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Random;

import org.junit.Test;

import redis.clients.jedis.Jedis;

/**
 * 一次string-hash优化
 * 
 * @author carlosfu
 * @Date 2015-11-8
 * @Time 下午7:27:45
 */
public class TestRedisMemoryOptimize {

    private final static int TOTAL_USER_COUNT = 1000000;

    private final static String HOST = "127.0.0.1";

    private final static int PORT = 6379;

    /**
     * 纯字符串
     */
    @Test
    public void testString() {
        int mBatchSize = 2000;
        Jedis jedis = null;
        try {
            jedis = new Jedis(HOST, PORT);
            List<String> kvsList = new ArrayList<String>(mBatchSize);
            for (int i = 1; i <= TOTAL_USER_COUNT; i++) {
                String key = "u:" + i;
                kvsList.add(key);
                String value = "v:" + i;
                kvsList.add(value);
                if (i % mBatchSize == 0) {
                    System.out.println(i);
                    jedis.mset(kvsList.toArray(new String[kvsList.size()]));
                    kvsList = new ArrayList<String>(mBatchSize);
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (jedis != null) {
                jedis.close();
            }
        }
    }

    /**
     * 纯hash
     */
    @Test
    public void testHash() {
        int mBatchSize = 2000;
        String hashKey = "allUser";
        Jedis jedis = null;
        try {
            jedis = new Jedis(HOST, PORT);
            Map<String, String> kvMap = new HashMap<String, String>();
            for (int i = 1; i <= TOTAL_USER_COUNT; i++) {
                String key = "u:" + i;
                String value = "v:" + i;
                kvMap.put(key, value);
                if (i % mBatchSize == 0) {
                    System.out.println(i);
                    jedis.hmset(hashKey, kvMap);
                    kvMap = new HashMap<String, String>();
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (jedis != null) {
                jedis.close();
            }
        }
    }

    /**
     * segment hash
     */
    @Test
    public void testSegmentHash() {
        int segment = 100;
        Jedis jedis = null;
        try {
            jedis = new Jedis(HOST, PORT);
            Map<String, String> kvMap = new HashMap<String, String>();
            for (int i = 1; i <= TOTAL_USER_COUNT; i++) {
                String key = "f:" + String.valueOf(i % segment);
                String value = "v:" + i;
                kvMap.put(key, value);
                if (i % segment == 0) {
                    System.out.println(i);
                    int hash = (i - 1) / segment;
                    jedis.hmset("u:" + String.valueOf(hash), kvMap);
                    kvMap = new HashMap<String, String>();
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (jedis != null) {
                jedis.close();
            }
        }
    }

}
 
三、结果对比
 redis核心对象 数据类型 + 编码方式 + ptr  分段hash也不会造成drift
方案 优点 缺点
string

直观、容易理解

  1. 内存占用较大
  2. key值分散、不变于计算整体
hash

直观、容易理解、整合整体

  1. 内存占用大
  2. 一个key占用过大内存,如果是redis-cluster会出 现data drift

 

segment-hash

内存占用量小,虽然理解不够直观,但是总体上是最优的。

理解不够直观。

 
四、结论:
   在使用Redis时,要选择合理的数据结构解决实际问题,那样既可以提高效率又可以节省内存。所以此次优化方案三为最佳。
 
附图一张:redis其实是一把瑞士军刀:
 
 
 
 
 
 
 

 

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
cetos sysctl.conf优化参考之一
简单的说明上面的参数的含义: net.ipv4.tcp_syncookies = 1 #表示开启SYN Cookies。
823 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
30363 0
《vSphere性能设计:性能密集场景下CPU、内存、存储及网络的最佳设计实践》一1.1.1 确定参数
本节书摘来华章计算机《vSphere性能设计:性能密集场景下CPU、内存、存储及网络的最佳设计实践》一书中的第1章 ,第1.1节,[美] 克里斯托弗·库塞克(Christopher Kusek) 著 吕南德特·施皮斯(Rynardt Spies)姚海鹏 刘韵洁 译, 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1033 0
一个价值“千万”的秒杀场景参数优化
       秒杀最早来自天猫双11各种商品的促销活动中,现在已经有很多业务场景在使用,比如抢红包,抢票等。其特点有三高:瞬时并发高,数据一致性高,热点更新频度高。这样三高的场景下往往给数据库造成极大的压力,大量更新数据库中的同一行,这样必然会产生锁等待,导致数据库的性能急剧下降的问题,很容易容易.
12839 0
PostgreSQL 11 内核优化 - 降低vacuum cleanup阶段index scan概率 ( vacuum_cleanup_index_scale_factor , skip index vacuum cleanup stage)
PostgreSQL 11 内核优化 - 降低vacuum cleanup阶段index scan概率 ( vacuum_cleanup_index_scale_factor , skip index vacuum cleanup stage)
774 0
Redis缓存、MemCached和.Net内部缓存的切换使用
接口文件: //IDataCache.cs using System; using System.Collections.Generic; using System.
648 0
在生产环境中使用Graylog日志系统所踩过的坑
在生产环境中使用Graylog日志系统所踩过的坑
3385 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
21322 0
+关注
付磊-起扬
阿里云数据库技术专家(Redis方向)
84
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载