redis存储大小

‘壹’ redis存储对象大小2m

Redis 存储字符串和对象
1 测试类
import redis.clients.RedisClinet;
import redis.clients.SerializeUtil;
import redis.clients.jedis.Jedis;

public class Test {

/**
* Administrator
* @param args
*/
public static void main(String[] args) {

// 操作单独的文本串
Jedis redis= new Jedis( "10.2.31.38", 6379);

redis.set( "key", "value");
System. out.println(redis.get( "key"));
System. out.println(redis.del( "key"));

// 操作实体类对象
Goods good= new Goods(); // 这个Goods实体我就不写了啊
good.setName( "洗衣机" );
good.setNum(400);
good.setPrice(19l);
redis.set( "good".getBytes(), SerializeUtil. serialize(good));
byte[] value = redis.get( "good".getBytes());
Object object = SerializeUtil. unserialize(value);
if(object!= null){
Goods goods=(Goods) object;
System. out.println(goods.getName());
System. out.println(goods.getNum());
System. out.println(goods.getPrice());
}
System. out.println(redis.del( "good".getBytes()));

// 操作实体类对象2（实际上和上面是一样的）
String key= "goods-key";
Goods g= new Goods();
g.setName( "电风扇--d" );
g.setNum(200);
String temp=RedisClinet. getInstance().set(g, key);
System. out.println(temp);

Object o=RedisClinet. getInstance().get(key);
if(o!= null)
{
Goods g1=(Goods)o;
System. out.println(g1.getName());
System. out.println(g1.getNum());
}
System. out.println(RedisClinet. getInstance().del(key));

}
}

2 RedisClinet 客户端类
package redis.clients;
import redis.clients.jedis.Jedis;
/**
*
* @author ajun
*
*/
public class RedisClinet {
private static final String ip= "10.2.31.38";
private static final int port=6379;
protected static RedisClinet redis = new RedisClinet ();
protected static Jedis jedis = new Jedis( ip, port);;
static {

}
protected RedisClinet(){
System. out.println( " init Redis ");
}
public static RedisClinet getInstance()
{
return redis;
}

/**set Object*/
public String set(Object object,String key)
{
return jedis.set(key.getBytes(), SerializeUtil.serialize(object));
}

/**get Object*/
public Object get(String key)
{
byte[] value = jedis.get(key.getBytes());
return SerializeUtil. unserialize(value);
}

/**delete a key**/
public boolean del(String key)
{
return jedis.del(key.getBytes())>0;
}

}

3 序列化工具类

/**
*
*/
package redis.clients;

import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;

/**
* @author Administrator
*
*/
public class SerializeUtil {
public static byte[] serialize(Object object) {
ObjectOutputStream oos = null;
ByteArrayOutputStream baos = null;
try {
// 序列化
baos = new ByteArrayOutputStream();
oos = new ObjectOutputStream(baos);
oos.writeObject(object);
byte[] bytes = baos.toByteArray();
return bytes;
} catch (Exception e) {

}
return null;
}

public static Object unserialize( byte[] bytes) {
ByteArrayInputStream s = null;
try {
// 反序列化
s = new ByteArrayInputStream(bytes);
ObjectInputStream ois = new ObjectInputStream(s);
return ois.readObject();
} catch (Exception e) {

}
return null;
}
}

‘贰’ redis存储几个g的数据

首先看到 Redis 官方的说法是：‘A String value can be at max 512 Megabytes in length.’。过大的 key 和 value 有两个问题：Redis 是一个内存数据库，如果容量过大的 key 和 value 首先会导致服务器中的内存碎片。这会影响 Redis 的内存分配的效率，进一步导致内存的使用率下降。容量过大的 key 和 value 还有这样几个影响：a. 这些过大的数据需要更多的时间去传输数据b. 过大的数据传输可能会导致其他的请求超时如果 A 的响应数据过大，它可能会吃掉其他请求的超时时间。如下图例子，如果 A 的响应数据过大，它会吃掉其他请求的超时时间

‘叁’ redis缓存服务器 建议内存多大

缓存每个电脑都会自动设置，一般不用设置；如果要设置，可以设置到2g以上，设置方法“我的电脑”点右键，系统属性中选择高级，点击性能。然后再点击高级，在虚拟内存框中点更改，把要设置的虚拟内存大小更改上。然后点确定，重启计算机就可以了

‘肆’ redis中的数据占用内存大小分析

如今越来越来的系统中使用 redis 作为缓存系统，但是随着用户量的增长，业务数据不断增多，redis服务器的内存空间有可能会到瓶颈了，及时观察redis中的各种键内存占用多少，会方便我们评估何时升级redis服务器规格，以及对于是否需要进行程序优化来设计合理的存储结构都会有很大帮助，下面给大家介绍两款工具 rdr 和 redis-rdb-tools ，可以很好的满足我们的需要

详细使用参考官方仓库：https://github.com/xueqiu/rdr

rdr提供了linux/OSX/Windows下的可执行文件，直接点击下载，我这里演示Windows下的使用方式

下载下来后存储到d:/dev路径下

1.首先要去redis服务器端将rdb文件复制到本地，为了方便，我将rdb文件放到了rdr工具所在目录

这里再说下redis rdb文件该怎么找到，通过查看redis服务器配置文件 redis.conf ，搜索 dbfilename 可以快速定位到该配置，按照路径就可以找到redis rdb备份文件了

2.在rdr工具所在的路径下打开命令行窗口，执行指令

可以看到指令执行成功后，在本地启动了server，监听端口8080

3.打开浏览器，访问http://localhost:8080/，能看到详细的内存占用数据报告，包括键数量、不同的数据类型、元素计数等

不过通过网页版的数据报告中有个小问题，对于redis中的不同数据库没有明显的区分展示~，混在一起，不是太清晰

详细使用参考官方仓库：https://github.com/sripathikrishnan/redis-rdb-tools/

1.安装python环境，我这里安装了python2.7.15

2.通过pip安装redis-rdb-tools

我这里python-lzf库没有安装成功，不过不影响实际使用，这个库是为了加速rdb文件解析速度~

3.安装完成后就可以在命令行中使用了，输入指令生成内存报告文件

等待一段时间，命令阻塞执行完成后，就会在-f参数指定的路径下生成对应的文件
用excel打开生成的csv文件，可以看到详细的统计结果，包含了所有数据库下所有key的内存占用情况~

redis-rdb-tools中还带了一个很有用的命令，能帮助我们直接查询单个key的内存占用情况，命令格式如下

执行测试下效果，可以看到命令执行完成后，直接回显出指定key对应的内存占用情况了

注意该操作在生产环境下慎用，视key大小情况再行决定是否执行，有可能会阻塞执行很长时间才能计算出结果~

‘伍’ redis的数据是存在内存里吗

Redis就是基于内存可持久化的key-value数据库。

1、性能问题，Hashmap存储大量数知据时需要不断扩容，Redis支持2的32次方个key，每个key或者value大小最大512M。

2、Hashmap是线程不安道全的，redis因为操作原子性不需要考虑这个。

3、Redis可持久化，Hashmap虽然也可以序列专化，但是Java的序列化因为安全问题说是要废除了，效率也没有Redis高，而且Redis有多属种持久化策略。

4、Redis可扩展可分布式部署。

(5)redis存储大小扩展阅读：

redis的存储分为内存存储、磁盘存储和log文件三部分，配置文件中有三个参数对其进行配置。

save seconds updates，save配置，指出在多长时间内，有多少次更新操作，就将数据同步到数据文件。这个可以多个条件配合，比如默认配置文件中的设置，就设置了三个条件。

appendonly yes/no ，appendonly配置，指出是否在每次更新操作后进行日志记录，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面的save条件来同步的，所以有的数据会在一段时间内只存在于内存中。

‘陆’ Redis百亿级Key存储设计方案

该应用场景为DMP缓存存储需求，DMP需要管理非常多的第三方id数据，其中包括各媒体cookie与自身cookie（以下统称supperid）的mapping关系，还包括了supperid的人口标签、移动端id（主要是idfa和imei）的人口标签，以及一些黑名单id、ip等数据。

在hdfs的帮助下离线存储千亿记录并不困难，然而DMP还需要提供毫秒级的实时查询。由于cookie这种id本身具有不稳定性，所以很多的真实用户的浏览行为会导致大量的新cookie生成，只有及时同步mapping的数据才能命中DMP的人口标签，无法通过预热来获取较高的命中，这就跟缓存存储带来了极大的挑战。

经过实际测试，对于上述数据，常规存储超过五十亿的kv记录就需要1T多的内存，如果需要做高可用多副本那带来的消耗是巨大的，另外kv的长短不齐也会带来很多内存碎片，这就需要超大规模的存储方案来解决上述问题。

人⼝标签主要是cookie、imei、idfa以及其对应的gender（性别）、age（年龄段）、geo（地域）等；mapping关系主要是媒体cookie对supperid的映射。以下是数据存储⽰示例：

媒体编号-媒体cookie=>supperid

supperid => { age=>年龄段编码，gender=>性别编码，geo=>地理位置编码 }

imei or idfa => { age=>年龄段编码，gender=>性别编码，geo=>地理位置编码 }

显然PC数据需要存储两种key=>value还有key=>hashmap，⽽而Device数据需要存储⼀一种

key=>hashmap即可。

存储吃紧的一个重要原因在于每天会有很多新数据入库，所以及时清理数据尤为重要。主要方法就是发现和保留热数据淘汰冷数据。

网民的量级远远达不到几十亿的规模，id有一定的生命周期，会不断的变化。所以很大程度上我们存储的id实际上是无效的。而查询其实前端的逻辑就是广告曝光，跟人的行为有关，所以一个id在某个时间窗口的（可能是一个campaign，半个月、几个月）访问行为上会有一定的重复性。

数据初始化之前，我们先利用hbase将日志的id聚合去重，划定TTL的范围，一般是35天，这样可以砍掉近35天未出现的id。另外在Redis中设置过期时间是35天，当有访问并命中时，对key进行续命，延长过期时间，未在35天出现的自然淘汰。这样可以针对稳定cookie或id有效，实际证明，续命的方法对idfa和imei比较实用，长期积累可达到非常理想的命中。

Hash表空间大小和Key的个数决定了冲突率（或者用负载因子衡量），再合理的范围内，key越多自然hash表空间越大，消耗的内存自然也会很大。再加上大量指针本身是长整型，所以内存存储的膨胀十分可观。先来谈谈如何把key的个数减少。

大家先来了解一种存储结构。我们期望将key1=>value1存储在redis中，那么可以按照如下过程去存储。先用固定长度的随机散列md5(key)值作为redis的key，我们称之为BucketId，而将key1=>value1存储在hashmap结构中，这样在查询的时候就可以让client按照上面的过程计算出散列，从而查询到value1。

过程变化简单描述为：get(key1) -> hget(md5(key1), key1) 从而得到value1。

如果我们通过预先计算，让很多key可以在BucketId空间里碰撞，那么可以认为一个BucketId下面挂了多个key。比如平均每个BucketId下面挂10个key，那么理论上我们将会减少超过90%的redis key的个数。

具体实现起来有一些麻烦，而且用这个方法之前你要想好容量规模。我们通常使用的md5是32位的hexString（16进制字符），它的空间是128bit，这个量级太大了，我们需要存储的是百亿级，大约是33bit，所以我们需要有一种机制计算出合适位数的散列，而且为了节约内存，我们需要利用全部字符类型（ASCII码在0~127之间）来填充，而不用HexString，这样Key的长度可以缩短到一半。

下面是具体的实现方式

参数bit决定了最终BucketId空间的大小，空间大小集合是2的整数幂次的离散值。这里解释一下为何一个字节中只有7位可用，是因为redis存储key时需要是ASCII（0~127），而不是byte array。如果规划百亿级存储，计划每个桶分担10个kv，那么我们只需2^30=1073741824的桶个数即可，也就是最终key的个数。

碎片主要原因在于内存无法对齐、过期删除后，内存无法重新分配。通过上文描述的方式，我们可以将人口标签和mapping数据按照上面的方式去存储，这样的好处就是redis key是等长的。另外对于hashmap中的key我们也做了相关优化，截取cookie或者deviceid的后六位作为key，这样也可以保证内存对齐，理论上会有冲突的可能性，但在同一个桶内后缀相同的概率极低(试想id几乎是随机的字符串，随意10个由较长字符组成的id后缀相同的概率*桶样本数=发生冲突的期望值<<0.05,也就是说出现一个冲突样本则是极小概率事件，而且这个概率可以通过调整后缀保留长度控制期望值)。而value只存储age、gender、geo的编码，用三个字节去存储。

另外提一下，减少碎片还有个很low但是有效的方法，将slave重启，然后强制的failover切换主从，这样相当于给master整理的内存的碎片。

推荐Google-tcmalloc， facebook-jemalloc内存分配，可以在value不大时减少内存碎片和内存消耗。有人测过大value情况下反而libc更节约。

1）kv存储的量级必须事先规划好，浮动的范围大概在桶个数的十到十五倍，比如我就想存储百亿左右的kv，那么最好选择30bit _{31bit作为桶的个数。也就是说业务增长在一个合理的范围（10} 15倍的增长）是没问题的，如果业务太多倍数的增长，会导致hashset增长过快导致查询时间增加，甚至触发zip-list阈值，导致内存急剧上升。

2）适合短小value，如果value太大或字段太多并不适合，因为这种方式必须要求把value一次性取出，比如人口标签是非常小的编码，甚至只需要3、4个bit（位）就能装下。

3）典型的时间换空间的做法，由于我们的业务场景并不是要求在极高的qps之下，一般每天亿到十亿级别的量，所以合理利用CPU租值，也是十分经济的。

4）由于使用了信息摘要降低了key的大小以及约定长度，所以无法从redis里面random出key。如果需要导出，必须在冷数据中导出。

5）expire需要自己实现，目前的算法很简单，由于只有在写操作时才会增加消耗，所以在写操作时按照一定的比例抽样，用HLEN命中判断是否超过15个entry，超过才将过期的key删除，TTL的时间戳存储在value的前32bit中。

6）桶的消耗统计是需要做的。需要定期清理过期的key，保证redis的查询不会变慢。

人口标签和mapping的数据100亿条记录。

优化前用2.3T，碎片率在2左右；优化后500g，而单个桶的平均消耗在4左右。碎片率在1.02左右。查询时这对于cpu的耗损微乎其微。

另外需要提一下的是，每个桶的消耗实际上并不是均匀的，而是符合多项式分布的。

上面的公式可以计算桶消耗的概率分布。公式是唬人用的，只是为了提醒大家不要想当然的认为桶消耗是完全均匀的，有可能有的桶会有上百个key。但事实并不没有那么夸张。试想一下投硬币，结果只有两种正反面。相当于只有两个桶，如果你投上无限多次，每一次相当于一次伯努利实验，那么两个桶必然会十分的均匀。概率分布就像上帝施的魔咒一样，当你面对大量的桶进行很多的广义的伯努利实验。桶的消耗分布就会趋于一种稳定的值。接下来我们就了解一下桶消耗分布具体什么情况：

通过采样统计

31bit（20多亿）的桶，平均4.18消耗

100亿节约了1.8T内存。相当于节约了原先的78%内存，而且桶消耗指标远没有达到预计的底线值15。

对于未出现的桶也是存在一定量的，如果过多会导致规划不准确，其实数量是符合二项分布的，对于2 ^30桶存储2 32kv，不存在的桶大概有（百万级别，影响不大）：

Math.pow((1 - 1.0 / Math.pow(2, 30)), Math.pow(2, 32)) * Math.pow(2, 30);

对于桶消耗不均衡的问题不必太担心，随着时间的推移，写入时会对HLEN超过15的桶进行削减，根据多项式分布的原理，当实验次数多到一定程度时，桶的分布就会趋于均匀（硬币投掷无数次，那么正反面出现次数应该是一致的），只不过我们通过expire策略削减了桶消耗，实际上对于每个桶已经经历了很多的实验发生。

总结：信息摘要在这种场景下不仅能节约key存储，对齐了内存，还能让Key按照多项式分布均匀的散列在更少量的key下面从而减少膨胀，另外无需在给key设置expire，也很大程度上节约了空间。

这也印证了时间换空间的基本理论，合理利用CPU租值也是需要考虑的。

关注分布式存储技术以及分布式计算方法