【作业详情】 设计微博系统中”微博评论“的高性能高可用计算架构

【作业要求】 分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用计算架构，包括但不限于如下内容： 1）计算性能预估（不需要考虑存储性能） 2）非热点事件时的高性能计算架构，需要考虑是否要拆分独立的服务 3）热点事件时的高可用计算架构

1 计算性能预估

用户量预估

用户行为建模

性能需求计算

用户量预估

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

用户行为建模

從發微博、看微博類推到微博評論的用戶行為模式：

本作业假设的是只针对文字微博，现实有图和影音的不在少数，架构设计会有所不同。

发微博

考虑到微博是一个看得多发的少的业务，假设平均每天每人发 1 条微博(只考虑文字微博)，则微博每天的发送量约为 2.5 亿条。 大部分的人发微博集中在早上 8:00~9:00 点，中午 12:00~13:00，晚上 20:00~22:00，假设这几个时间段发微博总量占 比为 60%。

看微博

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

微博评论

什么情况会发微博评论？

读微博评论和发微博评论的时间和读微博，发微博的时间基本上是重合的。

看微博也可能会看微博评论，会做

• 发微博评论

• 发微博评论的评论

其它的可能的动作

收藏微博评论

对微博评论点赞

转发微博

性能需求计算

從發微博、看微博類推到微博評論加上预备的所需服务器大约 140 台。

计算如下：

发微博：

平均发微博的 TPS 计算如下:2.5 亿 * 60% / (4 * 3600) ≈ 10 K/s

看微博：

看微博的次数为:

2.5 亿 * 100 = 250 亿.

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

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

微博评论：

发微博评论：

看微博评论：

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

微博是一个读多写少，而且发了就鲜少更动。

但微博评论有点不同，一般是看微博之后，才会顺道看评论，和发评论

以评论区会处在一个写的动作较原发博文来得高。

评论微博可考虑与以下服务独立拆分：

读微博：挑大 V，明星或是自己感兴趣的主题读

发微博：一般人较少发微博，除了记日志

转发微博：针对大 V, 明星的微博会有大量的(百万以上)的转发，应可独立拆分

3 热点事件

热点事件很难预估

高可用套路用预防

有以下几种：

限流/排队/降级/熔断

也會有双机房、三机房增加高可用

微博评论

适合用

限流

漏桶算法变种 - 写缓冲 (Buffer)

漏桶的容量无限，漏桶可以用来写缓冲

例如：Kafka 的消息队列

做到所有的评论都不丢失

也不像秒杀活动涉及到顺位和商品的有限

所以可以不用到排队

但对于热点事件

可以有熔断和降级的机制预防万一