写点什么

微博每日数十亿级业务下的计数器如何扩展 Redis?

2020 年 4 月 09 日

微博每日数十亿级业务下的计数器如何扩展Redis?

在 Feed 系统中,有简单数据类型的缓存,有集合类数据的。还有一些个性业务的缓存。比如大量的计数器场景,存在性判断场景等。微博解决存在性判断业务的缓存层叫 EXISTENCE 缓存层,解决计算器场景的缓存叫 COUNTER 缓存。


EXISTENCE 缓存层主要用于缓存各种存在性判断的业务,诸如是否已赞(liked)、是否已阅读(readed)这类需求。


Feed 系统内部有大量的计数场景,如用户维度有关注数、粉丝数、feed 发表数,feed 维度有转发数、评论数、赞数以及阅读数等。前面提到,按照传统 Redis、Memcached 计数缓存方案,单单存每日新增的十亿级的计数,就需要新占用百 G 级的内存,成本开销巨大。因此微博开发了计数服务组件 CounterService。下面以计数场景来管中窥豹。


提出问题


对于计数业务,经典的构建模型有两种:1 db+cache 模式,全量计数存在 db,热数据通过 cache 加速;2 全量存在 Redis 中。方案 1 通用成熟,但对于一致性要求较高的计数服务,以及在海量数据和高并发访问场景下,支持不够友好,运维成本和硬件成本较高,微博上线初期曾使用该方案,在 Redis 面世后很快用新方案代替。方案 2 基于 Redis 的计数接口 INCR、DECR,能很方便的实现通用的计数缓存模型,再通过 hash 分表,master-slave 部署方式,可以实现一个中小规模的计数服务。


但在面对千亿级的历史海量计数以及每天十亿级的新增计数,直接使用 Redis 的计数模型存在严重的成本和性能问题。首先 Redis 计数作为通用的全内存计数模型,内存效率不高。存储一个 key 为 8 字节(long 型 id)、value 为 4 字节的计数,Redis 至少需要耗费 65 字节。1000 亿计数需要 100G*65=6.5T 以上的内存,算上一个 master 配 3 个 slave 的开销,总共需要 26T 以上的内存,按单机内存 96G 计算,扣掉 Redis 其他内存管理开销、系统占用,需要 300-400 台机器。如果算上多机房,需要的机器数会更多。其次 Redis 计数模型的获取性能不高。一条微博至少需要 3 个计数查询,单次 feed 请求如果包含 15 条微博,仅仅微博计数就需要 45 个计数查询。


解决问题


在 Feed 系统的计数场景,单条 feed 的各种计数都有相同的 key(即微博 id),可以把这些计数存储在一起,就能节省大量的 key 的存储空间,让 1000 亿计数变成了 330 亿条记录;近一半的微博没有转、评论、赞,抛弃 db+cache 的方案,改用全量存储的方案,对于没有计数为 0 的微博不再存储,如果查不到就返回 0,这样 330 亿条记录只需要存 160 亿条记录。然后又对存储结构做了进一步优化,三个计数和 key 一起一共只需要 8+43=20 字节。总共只需要 16G20=320G,算上 1 主 3 从,总共也就只需要 1.28T,只需要 15 台左右机器即可。同时进一步通过对 CounterService 增加 SSD 扩展支持,按 table 滚动,老数据落在 ssd,新数据、热数据在内存,1.28T 的容量几乎可以用单台机器来承载(当然考虑访问性能、可用性,还是需要 hash 到多个缓存节点,并添加主从结构)。


计数器组件的架构如图 13-14,主要特性如下:


1) 内存优化:通过预先分配的内存数组 Table 存储计数,并且采用 double hash 解决冲突,避免 Redis 实现中的大量指针开销。


2) Schema 支持多列:一个 feed id 对应的多个计数可以作为一条计数记录,还支持动态增减计数列,每列的计数内存使用精简到 bit;


3) 冷热数据分离,根据时间维度,近期的热数据放在内存,之前的冷数据放在磁盘,降低机器成本;


4) LRU 缓存:之前的冷数据如果被频繁访问则放到 LRU 缓存进行加速;


5) 异步 IO 线程访问冷数据:冷数据的加载不影响服务的整体性能。



图 13-14 基于 Redis 扩展后的计数器存储架构


通过上述的扩展,内存占用降为之前的 5-10%以下,同时一条 feed 的评论/赞等多个计数、一个用户的粉丝/关注/微博等多个计数都可以一次性获取,读取性能大幅提升,基本彻底解决了计数业务的成本及性能问题。


本文转载自 IT 民工闲话 公众号。


原文链接:https://mp.weixin.qq.com/s/hY8q2acx9JMZFjZNbz-TjA


2020 年 4 月 09 日 16:01226

评论

发布
暂无评论
发现更多内容

【架构师训练营 - week1 -1】食堂就餐卡系统设计

早睡早起

第一周学习总结

Vincent

极客时间

命题架构设计 - 食堂就餐卡系统

知识乞丐

极客大学架构师训练营

架构师第一周学习小结

K先生

架构师训练营week1-学习记录

lijia_toby

极客大学架构师训练营

架构设计心得

吴吴

食堂就餐卡系统设计

atlasman

食堂就餐卡系统设计

谭焜鹏

架构homework1

蜡笔小晗

就餐卡系统架构文档

Geek_bobo

食堂就餐卡系统设计

哼哼

架构师如何做架构

atlasman

【Week01】架构师如何做架构

Aldaron

食堂就餐卡系统设计

桔子

架构师课程第一周总结

dongge

食堂就餐卡系统设计

Vincent

极客时间

架构师训练营(第1周作业)

李德政

极客大学架构师训练营

食堂就餐卡系统设计

Ph0rse

极客大学架构师训练营

架构师训练营第一周作业

fenix

架构师训练营第一周总结

will

架构学习之架构图设计(1)

Paula_l

食堂就餐卡系统设计

大咪发

架构学习

呱呱

极客大学架构师训练营 作业

食堂就餐卡系统设计

周冬辉

「架构师训练营」架构方法:架构师如何做架构-总结

隆隆

【极客大学】【架构师训练营】【第一周】 食堂就餐卡系统设计

NieXY

极客大学 极客大学架构师训练营

脑子不够怎么学架构

紫极

闲谈 极客大学架构师训练营

食堂就餐卡系统设计

食堂就餐卡系统设计

Aldaron

架构师训练Week1 - 食堂就餐卡系统架构设计

伊利是个圈

架构设计 极客大学架构师训练营 UML 作业

第一周作业二:学习总结

iHai

极客大学架构师训练营

NLP领域的2020年大事记及2021展望

NLP领域的2020年大事记及2021展望

微博每日数十亿级业务下的计数器如何扩展Redis?-InfoQ