微博评论高性能高可用计算架构设计

性能估算

【用户量】

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

【关键行为】

1. 发微博；

2. 看微博；

3. 评论微博。

【发微博】

考虑到微博是一个看得多发的少的业务，假设平均每天每人发 1 条微博（只考虑文字微博），则微博每天的发送量约为 2.5 亿条。

大部分的人发微博集中在早上 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。

【评论微博】

评论微博的用户都是看过微博的，基数是 250 亿,但不是每个人看完后都会发微博，假设平均 2/3 的用户看了后会参与评论：

250 亿 * 2/3 = 167 亿。

评论微博高性能架构设计

【业务特性分析】

评论微博虽然是一个写操作，可以容忍一定的丢失。因此可以用缓存架构，也需要用负载均衡架构。

【架构分析】

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

2.     请求量达到 167 亿，应该要用多级缓存架构，延用看微博时的多级缓存架构，其中 CDN 缓存，是缓存设计的核心。

【架构设计】

1.     负载均衡算法选择

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

2.     延用写微博的架构。机器数量为 120 台。

评论微博的多级负载均衡架构

评论微博的多级缓存架构

微博高性能计算方案- 整体架构设计

微博热点事件业务特性分析

【业务特性分析】

1. 转发微博

转发微博的业务逻辑基本等同于发微博，但是业务上可以区分是“原创”还是“转发”，转发的微博重要性和影响力不如原微博。

2. 看微博

热点事件发生后，绝大部分请求都落在了导致热点事件发生的那一条微博上面。

3. 评论微博

热点事件发生后，评论微博的业务大部分都落在热点事件发生的那一条微博上面，评论微博的重要性和影响里不如原微博。

微博热点事件计算高可用架构示意图