性能估算

背景

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

2. 假设平均每天每人发 1 条微博（只考虑文字微博），则微博每天的发送量约为 2.5 亿条

3. 大部分的人发微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段发微博总量占比为 60%

发评论

1. 假设平均 1 条微博有 10 条评论，则平均 TPS 为：2.5 亿 * 10 * 60 % / （4*3600） = 10 万/s。

2. 发评论是写操作，不能用缓存，可以使用负载均衡。

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

4. 负载均衡算法选择：同一条微博的评论尽量发到同一台服务器上，这样读取评论信息较为方便，使用 Hash 算法，根据微博 Id 计算 Hash。

5. 评论内容不用立即可见，可以使用消息队列暂存评论消息，服务器按一定速度消费。

6. 服务器数量估算：发评论将消息暂存至消息队列，服务器异步处理，因此按照一个服务每秒处理 2000 来估算，完成 10 万/s 的 TPS，需要 50 台服务器，加上一定的预留量，60 台服务器差不多了

看评论

1. 大部分人看评论只看前 3 页，可以在读微博信息的时候，同时读取前 3 页的评论信息，则平均 QPS 为：2.5 亿 * 100 * 60% / (4*3600) = 100 万/s。

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

3. 负载均衡算法选择：同一条微博的评论通过 Hash 算法发到同一台服务器上了，读取也采用 Hash 算法。

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

多级负载均衡整体架构

多级缓存整体架构