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

【作业要求】

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

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

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

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

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

【提示】

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

1. 性能估算

1.1 用户量预估

【用户量】

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

【关键行为】

1. 发评论；

2. 看评论。

1.2 用户行为建模和性能估算

【发评论】

考虑到评论是一个看得多发的少的业务，假设每人每天评论次数为 4 次，则评论总次数 2.5 亿*4=10 亿次。

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

10 亿 * 60% / (4 * 3600) ≈ 40k/s。

【看评论】

假设看评论的请求量与看微博的请求量一样，则 QPS 约为 1000k/s。

2. 高性能计算架构设计

2.1 发评论高性能计算架构设计

【业务特性分析】

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

【架构分析】

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

【架构设计】

1. 负载均衡算法选择

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

2. 业务服务器数量估算

由于发评论与发微博的处理流程类似，因此按照每秒处理 500 来估算，完成 40k/s 的 tps，需要 80 台服务器，加上一定的预留量，使用 100 台服务器。

【发评论的多级负载均衡架构】

2.2 看评论高性能计算架构设计

【业务特性分析】

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

【架构分析】

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

2. 请求量达到 250 亿，应该要用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。

【架构设计】

1. 负载均衡算法选择

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

1. 业务服务器数量估算

假设 CDN 能够承载 90%的用户流量，那么剩下 10%的看评论的请求进入系统，则 QPS 为 1000K/s * 10% = 100K/s，由于看评论的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 100 台，按照 20%的预留量，最终机器数量为 120 台。

【看评论的多级负载均衡架构】

【看评论的多级缓存架构】

2.3 评论高性能计算方案-整体架构设计

任务分配：双机房，三机房。

任务分解：将发评论和看评论拆分到不同服务。

【评论的多级负载均衡整体架构】

【评论的多级缓存整体架构】

与看评论的多级缓存架构一致

3. 评论高可用计算架构设计

3.1 评论热点事件用户行为建模和性能估算

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

【发评论】

造成热点事件的微博自己只有 1~2 条，但是用户围观后会有很多评论。

【看评论】

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

3.2 评论热点事件计算高可用架构分析

1. 发评论

当出现一个热点微博时，相关的写评论会随之飙升，由于丢失评论对用户的体验不太好，所以使用“漏桶算法”的“写缓冲”来应对海量评论，尽可能少丢失用户评论。

2. 看评论

很明显，热点事件评论存在缓存热点问题，可以考虑“多副本缓存”，由于原有的缓存架构已经采用了“应用内的缓存，总体上来看，缓存热点问题其实不一定很突出。考虑使用 CDN 缓存首页热门评论列表。

3.3 评论热点事件计算高可用架构示意图