php redis 存储大数据

2018-04-07 13:21:09 ZopaulCode 阅读数 31217

原文链接:http://www.cnblogs.com/colorfulkoala/p/5783556.html

问题导读:

1. 需求背景是什么?

2. 存储何种数据?

3. 数据特点是什么?

4. 存在哪些技术挑战?

5. 解决方案有哪些?

6. md5散列桶的方法需要注意哪些问题?

7. 测试结果是什么?

解决方案:

1 需求背景

    该应用场景为 DMP(Data Management Platform:数据管理平台,是把分散的多方数据进行整合纳入统一的技术平台,并对这些数据进行标准化和细分,让用户可以把这些细分结果推向现有的互动营销环境里的平台)缓存存储需求,DMP 需要管理非常多的第三方 id 数据,其中包括各媒体 cookie 与自身 cookie(以下统称supperid)的 mapping 关系,还包括了 supperid 的人口标签、移动端 id(主要是idfa(Identifier for Advertising:广告标识符)和 imei(International Mobile Equipment Identity:国际移动设备识别码的缩写。俗称“手机串号”、“手机串码”、“手机序列号”,用于在GSM移动网络中识别每一部独立的手机,相当于手机的身份证号码) )的人口标签,以及一些黑名单 id、 ip 等数据。

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

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

2 存储何种数据

    人口标签主要是 cookie、imei、idfa 以及其对应的 gender(性别)、age(年龄段)、geo(地域)等;mapping 关系主要是媒体 cookie 对 supperid 的映射。以下是数据存储示例:

1)  PC 端的ID:

媒体编号 - 媒体cookie => supperid

supperid => {

age => 年龄段编码,

gender => 性别编码,

geo => 地理位置编码

}

2)  Device 端的ID:

imei or idfa => {

age => 年龄段编码,

gender => 性别编码,

geo => 地理位置编码

}

    显然, PC 数据需要存储两种:key => value 和 key => hashmap,而 Device 数据需要存储一种 key => hashmap 即可。

3 数据特点

    短key短value,其中supperid为21位数字:比如 160524201514168952222;imei为小写md5:比如2d131005dc0f37d362a5d97094103633;idfa 为大写带 ”- ”md5:比如: 51DFFC83-9541-4411-FA4F-356927E39D04;媒体自身的 cookie 长短不一;需要为全量数据提供服务,supperid 是百亿级、媒体映射是千亿级、移动id是几十亿级;每天有十亿级别的 mapping 关系产生;对于较大时间窗口内可以预判热数据(有一些存留的稳定 cookie);对于当前 mapping 数据无法预判热数据,有很多是新生成的 cookie;

4 存在的技术挑战

1)长短不一容易造成内存碎片;

2)由于指针大量存在,内存膨胀率比较高,一般在7倍,纯内存存储通病;

3)虽然可以通过 cookie 的行为预判其热度,但每天新生成的 id 依然很多(百分比比较敏感,暂不透露);

4)由于服务要求在公网环境(国内公网延迟 60ms 以下)下 100ms 以内,所以原则上当天新更新的 mapping和人口标签需要全部 in memory,从而不会让请求落到后端的冷数据;

5)业务方面,所有数据原则上至少保留 35 天甚至更久;

6)内存至今也比较昂贵,百亿级Key乃至千亿级存储方案势在必行!

5 解决方案

5.1 淘汰策略

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

    网民的量级远远达不到几十亿的规模,id 有一定的生命周期,会不断的变化。所以很大程度上我们存储的 id 实际上是无效的。而查询其实(前端的逻辑)就是广告曝光,跟人的行为有关,所以一个 id 在某个时间窗口的(可能是一个 campaign(广告Campaign是指广告主在一段明确的期间里(如一年),推出一系列拥有共同主题或讯息的广告,以期建立广告讯息的累积效果,塑造品牌与企业一致的形象,并给予目标受众持续而深刻的刺激与冲击),半个月、几个月)访问行为上会有一定的重复性。

    数据初始化之前,我们先利用 hbase(HBase是一个分布式的、面向列的开源数据库,HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式) 将日志的 id 聚合去重,划定 TTL 的范围,一般是 35 天,这样可以砍掉近 35 天未出现的 id。另外在 Redis 中设置过期时间是 35 天,当有访问并命中时,对 key 进行续命,延长过期时间,未在 35 天出现的自然淘汰。这样可以针对稳定 cookie 或 id 有效,实际证明,续命的方法对 idfa 和imei 比较实用,长期积累可达到非常理想的命中。

5.2 减少膨胀

    Hash 表空间大小和 Key 的个数决定了冲突率(或者用负载因子衡量),在合理的范围内,key 越多自然 hash 表空间越大,消耗的内存自然也会越大。再加上大量指针本身是长整型,所以内存存储的膨胀十分可观。先来谈谈如何把 key 的个数减少,大家先来了解一种存储结构。我们期望将 key1 => value1 存储在 redis 中,那么可以按照如下过程去存储:先用固定长度的随机散列 md5(key1) 值作为 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的长度可以缩短到一半。下面是具体的实现方式:

public static byte[] getBucketId(byte[] key, Integer bit) {
	MessageDigest mdInst = MessageDigest.getInstance("MD5");
	mdInst.update(key);
	byte[] md = mdInst.digest();
	byte[] r = new byte[(bit - 1) / 7 + 1]; // 因为一个字节中只有7位能够表示成单字符
	int a = (int) Math.pow(2, bit % 7) - 2;
	md[r.length - 1] = (byte) (md[r.length - 1] & a);
	System.arraycopy(md, 0, r, 0, r.length);
	for (int i = 0; i < r.length; i++) {
		if (r[i] < 0)
			r[i] &= 127;
	}
	return r;
}

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

5.3 减少碎片

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

    另外提一下,减少碎片还有个很 low 但是有效的方法,将 slave重启,然后强制的 fail over 切换主从,这样相当于给 master 整理了内存的碎片。推荐 Google-tcmalloc, facebook-jemalloc内存分配,可以在value不大时减少内存碎片和内存消耗。有人测过,大value情况下反而libc更节约。

6  md5散列桶的方法需要注意的问题

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

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

3)典型的时间换空间的做法,由于我们的业务场景并不是要求在极高的 qps(每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准) 之下,一般每天亿到十亿级别的量,所以合理利用CPU租值,也是十分经济的。

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

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

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

7  测试结果

    人口标签和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 租值也是可以考虑的。

 

原文链接:http://www.cnblogs.com/colorfulkoala/p/5783556.html

2017-09-18 18:03:50 ahjxhy2010 阅读数 631

以前做过实验,但是不及这个文章详细。转载记录。


Redis持久化是有两种方式:RDB和AOF

对这两种方式的官方文档的翻译请看:

http://latteye.com/2011/11/redis-persistence.html

RDB就是快照存储,比如“每1个小时对redis进行快照存储”。那么,

save这个参数就应该设置save 3600 1000 //前一次快照3600秒后,当有超过1000个key被改动的时候就进行一次快照更新RDB快照产生dump.rdb文件,当每到快照时间,更新文件。

AOF是存储所有的写操作,分两个步骤:fsync和rewritefsync是把内存中的写操作写入aof文件中rewrite是将写操作合并,比如set aa 1; set aa 2; 两个操作应该写成一个操作set aa 2;

如果数据量小的话,啥问题也没有

现在假设服务器是20G内存,而且服务器上仅仅只有跑redis一个占内存的进程,就是说redis最多可以跑20G物理内存现在压入13G的redis数据(可以使用phpredis循环压入,但是要注意设置php的运行内存大小,最好使用pipeline的方式,否则php出现内存不足的error)

尝试1,我们只使用RDB的方式当进行快照的时候(测试时候可以把快照间隔时间定成30秒或更短)top查看进程

26376 test 16 0 13.5g 13g 7488 D 0.0 42.8 6:48.24 redis-server

32459 test 18 0 13.5g 13g 7200 D 1.3 42.8 0:23.22 redis-server

看到有两个进程,同时在运行,并且占用同样大小的内存数,和起来竟然占用26G之大~!

现在redis服务端上两个进程都运行,看看客户端:测试redis-cli set操作:

redis 10.1.0.108:6379> set test2 22

耗时(40.47s)近1分钟

就是说在大数据量的时候,做RDB,redis服务会暂停近1分钟!这个就是redis持久化的时候的服务暂停现象。

好吧,为了保证数据容错性,我们的快照一般是要频繁快照的,所以暂停一分钟是不可容忍的。

现在尝试使用AOF+RDB

1 将RDB的快照时间设置为1天(由于加上了AOF,所以这个时间是合理的)。

2 1次性压入1000w左右的string数据到redis中(大概有5G数据量)

3 查看性能表现:

第一个步骤fsync:

redis会从内存中逐渐生成appendonly.aof 在这个过程我试了下set和get操作都是没有暂停现象的(很好~!)

好了,现在appendonly.aof生成了,有5.7个G

-rw-r--r-- 1 root root 4186238374 Mar 6 15:50 appendonly.aof

第二个步骤:调用BGREWRITEAOF重写aof文件

这个时候top查看:

看到也是两个redis-server服务开着。说明rewrite的时候是fork一个子进程在rewrite的,主进程是进行着redis服务的。

这个时候redis-cli调用检查

get操作:无延时

set操作:出现了延迟现象 !!

这个说明AOF在重写的时候会占用服务器的大量CPU和内存资源,导致服务出现短暂暂停现象!但是为什么get操作没有出现延迟现象呢?参考官网文章,看到一个配置项:no-appendfsync-on-rewrite

这个配置项是设置在rewrite的时候是否对新的写操作进行fsync。no表示进行fsync,yes表示不进行

默认是设置为no

现在将这个配置项设置为yes(我们对于rewrite的aof文件硬盘大小没有很大要求)

重新进行测试:

对同样的5.7G的AOF操作进行一次BGREWRITEAOF。

get操作:无延迟

set操作:无延迟

很好!说明在rewrite的时候如果不进行fsync操作,主进程和子进程是互不干扰的。

那么如果rewrite的时候对新的写操作不进行fsync,那么新的aof文件里面是否会丢失这个写操作呢?

答案是不会的,redis会将新的写操作放在内存中,等待rewrite操作完成的时候,将新操作直接挂在aof中。

好了,至此,这个问题应该已经可以过去了。

推荐几个文章:

对数据持久化的一些想法:http://www.yiihsia.com/2011/04/%E5%AF%B9redis%E6%95%B0%E6%8D%AE%E6%8C%81%E4%B9%85%E5%8C%96%E7%9A%84%E4%B8%80%E4%BA%9B%E6%83%B3%E6%B3%95/

(这个文章提供了一个非常好的方法,当数据量大,内存足够的情况,一台机子上尽量多开几个redis,甚至可以考虑有几个cpu就开几个redis,这样,每个redis的内存量不会太大,就不会有大数据量服务暂停问题,这个也是考虑到了redis是单线程的,能尽量利用CPU)

redis的内存陷阱:http://www.iteye.com/topic/808293

(这个文章很好解释了问什么大数据量的时候会出现服务暂停)

Copy on write does not seem to work.: http://code.google.com/p/redis/issues/detail?id=150

出处:http://www.cnblogs.com/yjf512/

本文版权归yjf512和cnBlog共有,欢迎转载,但未经作者同意必须保留此段声明


2019-04-17 18:29:00 weixin_30329623 阅读数 53

Redis集合:集合是什么,就是一堆确定的数据放在一起,数学上集合有交集、并集的概念,这个就可以用来做大数据的筛选功能。

以商品为例,假如商品有颜色和分类、价格区间等属性。

给所有统一颜色的商品放一个集合,分类、价格也同样。

那么想要一个红色的沙发,就应该是红色的商品和沙发的分类的交集,而想要既是红色又是绿色的沙发,就应该是红色与绿色的合集再与沙发取交集。

代码上,以php为例

php操作redis

  连接

$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
存储集合
$redis->zAdd('红色',$k,$goods);
$redis->zAdd('红色',$k,$goods);
$redis->zAdd('绿色',$k,$goods);
$redis->zAdd('沙发',$k,$goods);
取交集
$redis->zInter('红色沙发', array('红色', '沙发'));

使用zadd存的是有序集合,方便数据取出后排序等操作。







转载于:https://www.cnblogs.com/mengzhilva/p/10725371.html

2019-05-26 21:37:41 weixin_40598838 阅读数 175

Redis的下载安装

通过wget下载redis
wget http://download.redis.io/releases/redis-3.2.12.tar.gz

将压缩包执行解压操作

tar xzf redis-3.2.12.tar.gz

解压缩后进入redis-3.2.12目录编译源码


cd redis-3.2.12
make install

ps:由于redis是由C语言编写的,需要安装C环境,如下所示

yum install gcc-c++

进入bin目录启动bin目录下的redis-server,得到如下图的结果,说明,启动成功:

在这里插入图片描述

接下来对redis进行操作,如下图所示,完成了redis的一次简单操作
在这里插入图片描述

2015-01-08 19:20:34 educast 阅读数 15185
这里的大量,不是指数据单元的大小,而是key-value对的数量庞大。 Redis 一直被当作是一个小巧灵活的瑞士军刀在用,虽然其通过条件化的 snapshot 和 appendonlylog 等方式在一定程度上保证了数据的可靠性,但利用 Redis 进行大量数据的存储还是比较少。下面

这里的大量,不是指数据单元的大小,而是key-value对的数量庞大。

Redis 一直被当作是一个小巧灵活的瑞士军刀在用,虽然其通过条件化的 snapshot 和 appendonlylog 等方式在一定程度上保证了数据的可靠性,但利用Redis进行大量数据的存储还是比较少。下面的三篇文章,是用Redis进行大量数据存储的应用和测试。还不敢用Redis来放大量数据的同学,可以先壮壮胆。

大数据技术--Redis

阅读数 1172