极客时间【架构实战营】第二期 模块五作业

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

1. 计算性能预估

1.1 发评论

微博评论业务属于看多发少的业务，假设平均每人每天发 2 条评论（只考虑文字），微博每天的评论数量为 5 亿条。

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

5 亿 * 60% / (4 *3600) ≈ 20K/s。

1.2 看评论

假设平均每条评论观看人数有 100 次，则总观看次数为：

5 亿 * 100 = 500 亿。

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

500 亿 * 60% / (4 *3600) ≈ 2000K/s。

2. 非热点事件的高性能架构

2.1 发评论

2.1.1 业务特性分析

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

2.1.2 架构分析

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

2.1.3 架构设计

2.1.3.1 负载均衡算法选择

评论微博依赖用户登录状态，登录状态保存在分布式缓存中，因此发评论时，可以将请求发给任意服务器，使用“轮询”或“随机”算法。

2.1.3.2 业务服务器数量估算

评论微博设计几个关键处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照每台服务器 500 的 TPS 来估算，完成 20K 的 TPS，需要 40 台服务器，加上一定的预留量，可以使用 50 台服务器。

2.2 看评论

2.2.1 业务特性分析

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

2.2.2 架构分析

用户量过亿，应采用多级负载均衡架构；

请求量达到 500 亿，应采用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。

2.2.3 架构设计

2.2.3.1 负载均衡算法选择

游客也可以看评论，因此将请求发给任意服务器都可以，使用“轮询”或“随机”算法。

2.2.3.2 业务服务器数量估算

假设 CDN 可以承载 90%用户流量，剩下 10%的请求进入系统，则请求 QPS 为 2000K/s * 10% = 200K/s，由于读取评论的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力为 1000 的 QPS，则机器数量需要 200 台，加上一定的预留量，可以使用 240 台。

2.3 微博评论业务整体架构设计

任务分配：由于用户量较大，地域分布广，因此需要多机房。

任务分解：由于看评论与发评论的请求数量相差较大，因此需将写评论和看评论拆分为不同的服务。

3. 热点事件的高可用架构

3.1 架构设计分析

3.1.1 发评论

评论的重要性和影响力不如原微博，尽量少丢请求，考虑“漏桶算法”限流策略。

3.1.2 看评论

热点事件微博评论存在缓存热点问题，可以考虑“多副本缓存”。