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

• 媒体自身的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有一定的生命周期，会不断的变化