微博评论计算架构设计

业务场景性能评估

用户量

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

用户行为

• 发微博

• 看微博

• 评论微博（本次作业）

用户行为性能评估

• 评论微博

考虑到微博是一个看的多发的少的业务，假设没人一天发表一条微博（只考虑文字微博），根据用户量日活数据作为参考，则每天发送的微博约为 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

• 微博评论的时间和发微博、看微博的时间段基本重合，并且不是每个发的微博都有评论，假设这个时间段进行评论的微博总量占比为 20%，每个微博评论的数量为 10 个

• 这 4 个小时的平均评论微博的 TPS 计算： 2.5 亿 * 20% * 10 / (4 * 3600) ≈ 3.5 K/s

• 看微博评论

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

2.5 亿 * 100 = 250 亿。

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

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

• 看评论和看微博有所不同，看到的每条微博能看到评论总数，这个和看微博的 QPS 是一样 1000K/s，但是不涉及到评论具体内容，只有当用户感兴趣的时候才会去点击评论的具体内容，因此我们假设平均每一条微博评论看的人数有 20 个，

• 则观看微博评论的次数为：2.5 亿 * 20 = 50 亿。

• 因此看微博评论的平均 QPS 计算：50 亿 * 60% / (4*3600) ≈ 200K/s。

• 微博的评论总数 QPS :1000K/s ，这个算在微博的读场景里(新浪微博的 CounterService，用于转发、评论、赞的计数)

高性能架构设计

评论微博

业务特性分析

• 评论微博和发微博一样都是写的场景，不用缓存，可以用缓冲和负载均衡

• 看微博评论是一个典型的读场景，由于评论发了后不能修改，要么删除，因此非常适合用缓存架构，同时由于请求量很大，负载均衡架构也需要。

架构分析

• 用户量过亿，考虑用多级负载均衡架构，覆盖 DNS -> F5/LVS -> Nginx -> 服务网关多级负载均衡

• 看微博评论超过 50 亿，考虑使用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。

架构设计

• 负载均衡算法选择

• 评论微博的时候起始和发微博的场景类似，依赖登录状态，登录状态一般都是保存在分布式缓存中的，评论微博的时候，将请求发送给任意服务器都可以，则其算法选择“轮询”或者“随机”。

• 游客可以直接看微博评论，因此和评论微博一样，采用“轮询”或者“随机”算法

• 业务服务器数量估算（40 台）

• 评论微博，按照一个服务每秒处理 500 来估算, 完成 3.5K/s 的 TPS ，则需要 7 台，按照 20%的预留量，机器数量 10 台服务器差不多了

• 看微博，假设 CDN 能够承载 90%的用户流量，那么剩下 10%的读微博的请求进入系统，则请求 QPS 为 200K/s * 10% = 20K/s，读取微博评论主要是读缓存系统，因此假设单台业务服务器处理能力是 1000/s，则机器数量为 20 台，按照 20%的预留量，机器数量为 25 台。

微博评论高性能总体架构图

• 负载均衡

• 缓存

高可用架构设计

基于微博热点事件做微博评论高可用架构。

热点事件指某个大 V 或者明星爆料或者官宣，虽然只有一两条微博，但引起大量用户在短时间内访问，给系统造成很大压力。

正对热点微博进行评论，很难预估哪个热点事件的影响范围，只能做预防。可以用类似接口限流、排队、熔断、降级等方法。保证系统不会挂掉，保证核心业务（发微博、看微博）使用

评论微博

评论微博的重要性和影响力不如发微博，可以用漏桶算法（写缓冲），把评论内容全部缓冲起来异步处理，业务系统慢慢消费处理，用户自己发的评论不能及时看到，可以通过刷新获取，不影响使用

看微博评论

热点事件微博存在缓存热点问题，可以考虑“多副本缓存”，由于原有的缓存架构已经采用了“应用内的缓存，总体上来看，缓存热点问题其实不一定很突出。

微博评论高可用总体架构图