用户量

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

关键行为

1.评论微博(本次作业内容)。

用户行为建模和性能估算

【评论微博】

基于看微博的数据：

我们假设平均一条微博观看人数有 100 次。

观看微博的次数为:

2.5 亿 * 100 = 250 亿。

假设平均一条微博，被写评论的次数有 30 次（包含对评论的评论）。

则总的写评论的次数为：

2.5 亿 * 30 = 75 亿。

同时假设评论的事件和看微博的时间也基本重合，则写评论的平均 QPS:

75 亿 * 60% / (4*3600) = 320K/s

既然是写评论，就对应有看评论。

假设一条评论的查看次数平均为 10 次

则看评论的 QPS:

320K * 10 = 3200K/s

写评论

【业务特性分析】

写评论也是写操作，因此不能用缓存，可以用负载均衡。

【架构分析】

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

【架构设计】

1. 负载均衡算法选择

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

2. 业务服务器数量估算

写评论涉及几个关键的处理:内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统)，因 此按照一个服务每秒处理 500 来估算，完成 320K/s 的 TPS，需要 64 台服务器，加上一定的预留量，70 台服务器差不多了。

看评论

【业务特性分析】

看评论是一个典型的读场景，由于微博发了后不能修改，因此非常适合用缓存架构，同时由于请求量很大，负载均衡架构也需要。

【架构分析】

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

2. 请求量非常高，应该要用多级缓存架构。但是由于评论一般只看前几页，所以只需要对前面几页的评论进行 CDN 缓存即可。

【架构设计】

1.负载均衡算法选择 游客都可以直接看评论，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

2. 业务服务器数量估算

查看评论主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 3200 台，按照 20%的预留量,最终机器数量为 640 台。

服务拆分

由于评论的查看请求比写评论的请求多的多，需要将服务进行拆分，避免读请求过大影响到写请求。

热点事件

以上针对非热点事件的架构分析。

针对热点事件：

热点事件对应的评论也可能会增加，使用漏桶算法来进行写缓冲。