1 需求背景redis
该应用场景为AdMaster DMP缓存存储需求，DMP须要管理很是多的第三方id数据，其中包括各媒体cookie与自身cookie（如下统称admckid）的mapping关系，还包括了admckid的人口标签、移动端id（主要是idfa和imei）的人口标签，以及一些黑名单id、ip等数据。 在hdfs的帮助下离线存储千亿记录并不困难，然而DMP还须要提供毫秒级的实时查询。因为cookie这种id自己具备不稳定性，因此不少的真实用户的浏览行为会致使大量的新cookie生成，只有及时同步mapping的数据才能命中DMP的人口标签，没法经过预热来获取较高的命中，这就跟缓存存储带来了极大的挑战。 通过实际测试，对于上述数据，常规存储超过五十亿的kv记录就须要1T多的内存，若是须要作高可用多副本那带来的消耗是巨大的，另外kv的长短不齐也会带来不少内存碎片，这就须要超大规模的存储方案来解决上述问题。算法
2 存储何种数据后端
人⼝标签主要是cookie、imei、idfa以及其对应的gender（性别）、age（年龄段）、geo（地域）等；mapping关系主要是媒体cookie对admckid的映射。如下是数据存储⽰示例： 1) PC端的ID： 媒体编号-媒体cookie=>admckid admckid => { age=>年龄段编码，gender=>性别编码，geo=>地理位置编码 } 2) Device端的ID： imei or idfa => { age=>年龄段编码，gender=>性别编码，geo=>地理位置编码 } 显然PC数据须要存储两种key=>value还有key=>hashmap，⽽而Device数据须要存储⼀一种 key=>hashmap便可。缓存
3 数据特色cookie
短key短value：其中superid为21位数字：好比1605242015141689522；imei为小写md5：好比2d131005dc0f37d362a5d97094103633；idfa为大写带”-”md5：好比：51DFFC83-9541-4411-FA4F-356927E39D04； 媒体自身的cookie长短不一； 须要为全量数据提供服务，admckid是百亿级、媒体映射是千亿级、移动id是几十亿级； 天天有十亿级别的mapping关系产生； 对于较大时间窗口内能够预判热数据（有一些存留的稳定cookie）； 对于当前mapping数据没法预判热数据，有不少是新生成的cookie；app
4 存在的技术挑战dom
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，因此咱们须要有一种机制计算出合适位数的散列，并且为了节约内存，咱们须要利用所有字符类型（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位可以表示成单字符inta = (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重启，而后强制的failover切换主从，这样至关于给master整理的内存的碎片。
推荐google-tcmalloc，facebook-jemalloc内存分配，能够在value不大时减小内存碎片和内存消耗。有人测过大value状况下反而libc更节约。
6. md5散列桶的方法须要注意的问题
1）kv存储的量级必须事先规划好，浮动的范围大概在桶个数的十到十五倍，好比我就想存储百亿左右的kv，那么最好选择30bit~31bit做为桶的个数。也就是说业务增加在一个合理的范围（10~15倍的增加）是没问题的，若是业务太多倍数的增加，会致使hashset增加过快致使查询时间增长，甚至触发zip-list阈值，致使内存急剧上升。
2）适合短小value，若是value太大或字段太多并不适合，由于这种方式必需要求把value一次性取出，好比人口标签是很是小的编码，甚至只须要三、4个bit（位）就能装下。
3）典型的时间换空间的作法，因为咱们的业务场景并非要求在极高的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租值也是须要考虑的。