模块五作业

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

【作业要求】

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其

高性能高可用计算架构，包括但不限于如下内容：

1. 计算性能预估（不需要考虑存储性能）；

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

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

【提示】

1. 分析方法对照“看微博”和“发微博”的案例。

计算性能预估

【用户量】

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

【关键行为】

1. 发微博；

2. 看微博；

3. 评论微博

用户行为建模和性能估算

【评论微博】

微博用户绝大部分评论的是大 V 和明星的微博的，因此假设平均一条微博评论人数有 1000 次，则评论微博的次数为：

2.5 亿 * 1000 = 2500 亿。

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

2500 亿 * 60% / (4*3600) = 10000K/s。

非热点事件时的评论微博高性能计算架构设计

微博服务拆分为：发微博、评论微博、看微博

1. 【业务特性分析】：评论微博是典型写操作，不能用缓存，但可使用负载均衡、消息队列降低压力

2. 【架构分析】：用户量过亿，用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关

3. 【架构设计】：

负载均衡算法选择：这里选择“轮询”或者“随机”算法

业务服务器数量估算：需要 40 台服务器，预留量 50 台服务器左右

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

热点事件时的评论微博高可用计算架构设计

用户行为建模和性能估算

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

难预估，和事件的影响力和影响范围有关

【业务特性】一般原微博的评论会特别多，衍生或转发的微博影响力会低于原微博

【架构分析】还是按照之前的评论逻辑，直接按排队处理即可，这里影响不是很大——服务按需消费即可

引入消息队列来减负