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

1. 问题分析

微博评论与微博发送、查看场景类似，包含“发评论”和“看评论”两个场景。故架构设计分为“发”和“看”两个场景进行分析。本文不考虑存储性能。

场景描述：

“发评论”场景：当原创微博发出之后，用户对于感兴趣的微博内容发送追加信息，假设每条微博有 100 条评论

“看评论”场景：分页获取评论列表，每次请求 20 条

基础数据：

发微博：大部分的人发微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段发微博总量占比为 60%，则这 4 个小时的平均发微博的 TPS 为：2.5 亿 * 60% / (4 * 3600) ≈ 10 K/s。

看微博：由于绝大部分微博用户看微博的对象是大 V 和明星，因此我们假设平均一条微博观看人数有 100 次，则观看微博的次数为：2.5 亿 * 100 = 250 亿。

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

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

2. 微博业务场景计算性能估算

发评论：

发评论场景与发微博类似，当原创微博发出后，大部分人会紧接着会进行评论，所以，发微博的时间和性能估算为：在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段发评论总量占比为 60%，则这 4 个小时的平均发评论的 TPS 为：2.5 亿 * 60% / (4 * 3600) ≈ 10 K/s。

看评论：

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

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

3. 微博高性能计算架构设计

发评论

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

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