实现Redis亿级存储的方案

1 需求背景

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

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

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

2 存储何种数据

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

PC端的ID：
媒体编号-媒体cookie=>supperid

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

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

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

key=>hashmap即可。

3 数据特点

短key短value：其中superid为21位数字：比如1605242015141689522；imei为小写md5：比如2d131005dc0f37d362a5d97094103633；idfa为大写带”-”md5：比如：51DFFC83-9541-4411-FA4F-356927E39D04；
媒体自身的cookie长短不一；
需要为全量数据提供服务，supperid是百亿级、媒体映射是千亿级、移动id是几十亿级；
每天有十亿级别的mapping关系产生&#