架构实战 - 模块 5 作业

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

【作业要求】

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

计算架构，包括但不限于如下内容：

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%，则这 4 个小时的平均发微博的 TPS 计算如下：

2.5 亿 * 60% / (4 * 3600) ≈ 10 K/s

看微博: 我们假设平均一条微博观看人数有 100 次, 则观看微博的次数为：

2.5 亿 * 100 = 250 亿.

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

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

评论微博: 基于看微博的量，针对点赞、文字评论分析:

我们假设平均一条微博观看点赞的概率为: 10 个人有 4 人点赞，那么总量是 2.5 亿 *100*40%=100 亿

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

100 亿 * 60% / (4*3600) ≈ 450K/s

文字评论概率: 假设 100 个人有 5 人评论，那么总量是 2.5 亿*100*5%=12.5 亿，时间段重合，因此评论微博的 TPS 计算如下:

12.5 亿*60%/(4*3600) ≈ 52K/s

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

【 业务特性分析 】

评论微博是一个典型的写操作，可以用负载均衡。写缓存应用与否，具体需要看业务容忍度分析。

【 架构分析 】

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

【 架构设计 】

2.1) 负载均衡算法选择:

评论微博的时候依赖登录状态、被评论微博状态，登录状态、微博评论信息，一般都是保存在分布式缓存中

的。点赞评论微博、文字评论微博的体量差距较大，对服务器的性能要求差别较大，需要分拆任务服务器：

前提: 这里会涉及到微博信息的储存位置，由于体量较大，会采用分片储存来应对增量，以上评论服务器需要具备与分片储存集群交互的能力。

点赞服务器: 点赞评论发给任意服务器都可以，这里选择“轮询”或者“随机”算法

文字评论服务器: 将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法

2.2) 业务服务器数量估算:

评论微博涉及几个关键的处理：

点赞评论: 数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 10K 来估算，完成 450K/s 的 TPS，需要 45 台服务器，加上一定的预留量， 50 台服务器 差不多了。

文字评论: 内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 500 来估算，完成 52K/s 的 TPS，需要 100 台服务器，加上一定的预留量， 120 台服务器 差不多了。

根据评论业务丢失/响应的容忍度不同，可考虑采用写缓存 + 限流的算法(漏桶算法), 同步改成异步方式，可降低服务器的机器成本 2-3 倍。

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

3.1) 用户行为建模与性能估算

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

【评论微博】

评论量上很难预估，和事件的影响力和影响范围有关。

评论时间，假设 80%的评论，集中在时间发生 1 周内。

3.2) 业务特性分析

热点时间发生后，大量的看微博请求落在该事件，点赞、内容评论等行为也会聚集在热点那几条微博上面。

3.3) 高可用架构分析

评论微博:

评论业务具备较强的容忍度、实时性要求一般，可允许丢失部分，考虑用“漏桶算法”

3.4) 架构示意图