Redis 大数据量（百亿级）Key存储需求及解决方案

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

二 存储何种数据

---

人⼝标签主要是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即可。

三 数据特点

---

• 短key短value：

• • 其中superid为21位数字：比如1605242015141689522；

• 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，半个月、几个月）访问行为上会有一定的重复性。

数据初始化之前，我们先利用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(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（2的33次方），所以我们需要有一种机制计算出合适位数的散列，而且为了节约内存，我们需要利用全部字符类型（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位能够表示成单字符，ascii码是7位

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
开发知识点，不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！**

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！