写点什么

架构训练 模块五

作者:小马
  • 2022 年 5 月 12 日
  • 本文字数:1110 字

    阅读完需:约 4 分钟

1 计算性能预估

【用户量】

1. 2020.9 月月活 5.11 亿,日活 2.24 亿(参考《微博 2020 用户发展报告》)。

【关键行为】

1. 微博评论

1.1 用户行为建模和性能估算

考虑到微博评论是一个看得多发得少的业务,假设平均每天每人评论 10 条微博(只考虑文字评论),则微博每天评论量约为 2.24*10=22.4 亿条。

大部分人互动活跃在早上 8:00~10:00 点,中午 12:00~13:00,傍晚 17:00~18:00,晚上 22:00~23:00,假设这几个时间段发微博总量占比为 90%,则这 5 个小时的平均发微博评论的 TPS 计算如下:

22.4 亿*90%/(5*3600)=112K/S

复制代码

从【看微博】性能估算来看,由于绝大部分微博用户看微博的对象是大 V 和明星,评论的也是大 V 和明星的微博,因此我们假设平均一条微博评论观看人数有 100 次,则观看微博评论的次数为:

2.24 亿* 100 = 224 亿

复制代码

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

(224 亿+22.4 亿)* 90% / (5*3600) = 1232K/s

复制代码

2 非热点事件时的高性能计算架构

2.1 业务特性分析

微博评论是一个典型的读写操作,既要读也要写,但整体读多写少。因此,由于微博评论之后不能修改,因此非常适合缓存架构,同时由于请求量大,也需要负载均衡架构。非热点事件时,评论量较少,也不会有流量尖峰,流量相对平稳。

2.2 架构分析

  1. 用户量过亿,应该要用多级负载均衡架构;

  2. 请求量达到 224 亿,应该要用多级缓存架构,尤其是 CDN 缓存,是缓存设计的核心。

  3. 非热点事件时,评论量较少,看微博评论次数也相对较少,没有流量尖峰

2.3 架构设计

2.3.1 发微博评论的多级负载均衡架构

2.3.2 看微博评论的多级负载均衡架构

2.3.3 看微博评论的多级缓存架构

2.4 微博评论的高性能计算方案-整体架构设计


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

热点事件指某个大 V 或者明星爆料或者官宣,虽然只有一两条微博,但引起大量用户在短时间内访问,给系统造成很大压力。

3.1 业务特性分析

  1. 转发评论的业务逻辑等同于发微博,但是业务上可以区分是“原创”还是“转发”,转发的微博评论重要性和影响力不如原微博评论。

  2. 热点事件发生后,绝大部分请求都落在了导致热点事件发生的那一条微博上面。而针对该条微博的请求量会非常大。

3.2 架构设计分析

1. 转发微博评论

转发的微博评论重要性和影响力不如原微博,可以考虑对“转发微博”限流,由于转发能带来更好的传播,因此尽量少丢弃请求,考虑用“漏桶算法”。

2. 看微博评论

很明显,热点事件微博存在缓存热点问题,热门评论也会存在缓存热点问题,可以考虑“多副本缓存”,由于原有的缓存架构已经采用了“应用内的缓存,总体上来看,缓存热点问题其实不一定很突出。


还可以考虑在热点事件微博进行业务降级,比如说不允许评论。


用户头像

小马

关注

还未添加个人签名 2017.12.26 加入

还未添加个人简介

评论

发布
暂无评论
架构训练 模块五_「架构实战营」_小马_InfoQ写作社区