阿里实现Redis亿级存储的方案

最新推荐文章于 2024-04-18 01:27:55 发布

OH五星上将

最新推荐文章于 2024-04-18 01:27:55 发布

阅读量1.4k

点赞数

文章标签： redis 阿里亿级

本文链接：https://blog.csdn.net/u012165769/article/details/88207923

版权

该博客介绍了阿里为应对DMP缓存存储需求，如何处理亿级数据的Redis存储问题。面临数据量巨大、内存碎片、高可用等问题，阿里采用了淘汰策略、减少膨胀和减少碎片等方法，包括预判热数据、使用Hash表减少key数量和通过信息摘要优化key存储，实现了高效内存利用和数据管理。测试结果显示，该方案显著减少了内存消耗。

摘要由CSDN通过智能技术生成

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是几十亿级；