设计微博系统中”微博评论“的高性能高可用计算架构。

【作业要求】

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用计算架构，包括但不限于如下内容:

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

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

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

一、业务场景计算性能估算

• 【用户量】

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

• 【关键行为】

1. 发评论

2. 看评论

• 【性能估算】

• 发评论

微博每天的发送量假设为 2 亿条(实际应该看得多发的少)，平均每条微博 10 条评论，每天的评论量为 20 亿条。大部分的人写评论集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00 这些上下班途中以及休息时间，假设这几个时间段写的总量占比为 60%，则这 4 个小时的平均写评论的 TPS 计算如下：

20 亿* 60%/(4* 3600)=80K/s

• 看评论

假设平均一条微博观看人数有 20 次， 评论在点开微博详情的时候就默认是已经被观看了，因此观看的次数是 2 亿*20 =40 亿。大部分人看评论的时间段和发微博的时间段基本重合。

QPS ：

40 亿 *60%/(4* 3600)=160K/s

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

• 业务特性分析

发评论是一个典型的写操作，因此不能用缓存，可以用负载均衡。

• 架构分析

用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。

• 架构设计

1. 负载均衡算法选择

发微博评论依赖登录状态，登录状态一般保存在分布式缓存中。发微博评论时，可以把请求发送给任意服务器，这里选择“轮询”或者“随机”算法。

1. 服务器数量估算

假设每台服务器每秒处理能力是 1000 条，则需要 160K/1000 = 160 台服务器，加上一些备用的服务器，大概需要 180~200 台。

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

• 架构分析

发生热点事件时，点击率暴增，需要考虑 K8S 弹性扩容服务器，增加可读性副本。同时，微博本身的评论是要经过一定审核才能进行发表的，所以这时的评论显示未必需要实时性很强。为了避免服务器崩溃，可以采用限流，令牌桶算法等方式来对发评论进行控制。