1. 计算性能预估

从模块五课件可知：

【用户量】

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

【发微博】

考虑到微博是一个看得多发的少的业务，假设平均每天每人发 1 条微博(只考虑文字微博)，则微博每天的发送量约为 2.5 亿条。

大部分的人发微博集中在早上 8:00~9:00 点，中午 12:00~13:00，晚上 20:00~22:00，假设这几个时间段发微博总量占比为 60%，则这 4 个小时的平均发微博的 TPS 计算如下:2.5 亿 * 60% / (4 * 3600) ≈ 10 K/s。

【看微博】

由于绝大部分微博用户看微博的对象是大 V 和明星，因此我们假设平均一条微博观看人数有 100 次，则观看微博的次数为:

2.5 亿 * 100 = 250 亿。

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

250 亿 * 60% / (4*3600) = 1000K/s。

【微博评论量】

假设平均每条微博评论数为 10，则微博每天评论数为 25 亿。

• 热点时段评论 TPS：25 亿 * 60% / (4 * 3600) ≈ 100 K/s

假设平均一条评论观看人数有 20 次，则评论每天被观看次数为 500 亿。

• 热点时段评论 QPS：500 亿 * 60% / (4*3600) = 2000K/s

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

微博评论的多级负载均衡架构可以直接套用发微博/看微博的架构，只需将服务集群数量扩大至相应的数量：

• 满足 100K TPS：250 台

• 满足 2000K QPS：240 台

缓存整体架构同发微博/看微博，不再赘述。

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

微博评论高可用计算架构也和发微博/看微博相似。不同点在于评论没有转发，但是有回复。回复的特点是不会主动被加载，所以被阅读的概率大大降低。但是此特点只影响高性能计算架构的 QPS，并不影响高可用计算架构。所以评论的高可用计算架构同微博热点事件。