重学架构之微博评论高性能高可用计算架构

计算性能估算

用户量

2020.9 月月活 5.11 亿，日活 2.24 亿(参考《微博 2020 用户发展报告》)。

评论关键行为

1. 发评论

2. 看评论

发评论

大部分的人发微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，看微博、发微博、评论的时间段基本重合，假设这几个时间段评论总量占比为 60%，且大多数用户都是看多发少，假设平均一条微博有 10 条评论，则这 4 个小时的平均发评论的 TPS 计算如下：

评论次数为

2.5 亿 * 10 = 25 亿。

评论微博的平均 QPS 为

25 亿 * 60% / (4*3600) = 100K/s。

看评论

假设平均每条微博看评论的次数为 50 次

2.5 * 50 = 120 亿

看微博评论的评价 QPS 为

120 * 60% / （4*3600）= 500K/s

业务特性分析

1. 评论微博是是一个典型的写操作，因此不使用缓存，可使用负载均衡。

2. 看微博评论是一个典型的读操作，发送之后不会再修改，非常适合使用缓存架构，由于 QPS 非常高，同时也需要负载均衡。

架构分析

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

2. 看微博评论，需要使用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。

架构设计

1. 负载均衡算法选择

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

2.发微博评论业务服务器数量估算

发微博评论涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 500 来估算，完成 100K/s 的 TPS，需要 200 台服务器，加上 20%的预留量，240 台服务器差不多了。

3. 看微博评论业务服务器数量估算

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

4. 服务拆分

发评论与看评论在架构设计是差异较大，将评论业务拆分为发评论与看评论比较合适。

多级负载均衡整体架构

缓存整体架构