写点什么

微博评论背后的高性能高可用计算架构

用户头像
面朝大海
关注
发布于: 刚刚

要求

分析“微博评论”这个核心场景的业务特性,然后设计其高性能高可用计算架构,包括但不限于如下内容:

1. 计算性能预估(不需要考虑存储性能);

2. 非热点事件时的高性能计算架构,需要考虑是否要拆分独立的服务;

3. 热点事件时的高可用计算架构

数据评估

发评论

微博本身是一个看多发少的业务,微博评论也是蕾丝,假设平均每天每人发 1 条微博(只考虑文字微博),则微博每天的发送量约为 2.5 亿条,而考虑到更多的人会进行点赞操作,实际真正会去评论的人仅占部分(还有很多人的微博基本没有互动),按照 2 倍计算,预估每天发评论 5 亿条

大部分的人写评论集中在早上 8:00~9:00 点,中午 12:00~13:00,晚上 20:00~22:00,假设这几个时间段发微博总量占比为 60%,则这 4 个小时的平均发微博的 TPS 计算如下:

5 亿 * 60% / (4 * 3600) ≈ 20 K/s

看评论

由于大部分人都是看热点微博,很多发了的微博并不会被太多人可见,也不会点开看微博评论,假设没人每天读 100 条微博,其中 3/4 会查看评论

2.5 亿 * 100 * 0.75 = 187.5 亿

大部分人微博活跃时间基本重合,因此看评论的平均 QPS 计算如下:

187.5 亿 * 60% / (4*3600) ≈ 780K/s

架构设计

  • 写评论和看评论,一个核心是读,一个核心是写,功能场景差异较大,需要考虑拆分为看服务和写服务,其中写服务重点是计算能力,读服务则更侧重缓存性能

  • 同一时间段的热点事件往往比较聚焦,可能就是 top10 的热点,假如热点事件时读微博的性能扛得住,那对于评论而已,可以提供限流控制或写缓冲机制,降低评论的并发,提高系统处理效率,对于读评论则可以采用多副本机制

整体架构


用户头像

面朝大海

关注

我们终会上岸,阳光万里 2019.06.02 加入

互联网金融从业者

评论

发布
暂无评论
微博评论背后的高性能高可用计算架构