作业：

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

【作业要求】

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

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

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

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

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

【提示】

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

答

【用户量】

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

计算性能预估

由于绝大部分微博用户看微博的对象是大 V 和明星，因此我们假设平均一条微博被评论 10 次，则评论微博的次数为

2.5 亿*10=25 亿每天

大部分的人评论微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段发微博总量占比为 60%，与这则这 4 个小时的平均发微博的 TPS 计算如下：

25*0.6/(4X60X60)≈100K/s

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

评论微博，是典型的写操作，不用缓存，可用负载均衡架构

架构分析

用户过亿，多级负载均衡 DNS->F5->Nginx->网关多级负载均衡

架构设计

负载均衡算法：

发微博依赖于用户登陆状态，用户登录状态存储在分布式缓存中，请求发送到任意服务器都可以，这里使用“轮询”或者“随机”算法

业务服务器数量估算

评论微博，设计，内容审核，写入库，写入缓存，因此单台按照每秒处理 500 计算，要支撑 tps：100K/S 需要 200 台机器，考虑余量 250 台机器。

评论与其他功能耦合不大，采取单独部署。

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

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

热点事件指某个大 V 或者明星爆料或者官宣，虽然只有一两条微博，但引起大量用户在短时间内大量评论。

评论微博，实时性要求不高，可采用排队策略，消息队列削峰填谷。

架构示意图