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

【作业要求】

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其

高性能高可用计算架构，包括但不限于如下内容：

1. 计算性能预估（不需要考虑存储性能）；

2. 非热点事件时的高性能计算架构，需要考虑是否要拆分独立的服务；

3. 热点事件时的高可用计算架构。

【提示】

1. 分析方法对照“看微博”和“发微博”的案例。

一、计算性能预估（不需要考虑存储性能）

【用户量】

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

【用户行为：微博评论】

计算预估

假设平均每天每人评论 2 条微博（只考虑文字评论），则微博每天评论量约为 2.24*2=4.48 亿条。

大部分人互动活跃在早上 8：00~10：00 点，中午 12：00~13：00，傍晚 17：00~18：00，晚上 22：00~23：00，假设这几个时间段发微博总量占比为 90%，则这 5 个小时的平均发微博评论的 TPS 计算如下：

4.48 亿*90%/(5*3600)=22.4K/S

二.、非热点事件时的高性能计算架构，需要考虑是否要拆分独立的服务；

1、业务分析

微博评论是一个典型的读写操作，既要读也要写，但整体读多写少。因此，由于微博评论之后不能修改，因此非常适合缓存架构，同时由于请求量大，也需要负载均衡架构。非热点事件时，评论量较少，也不会有流量尖峰，流量相对平稳。

2、计算架构分析

1. 用户量过亿，应该要用多级负载均衡架构；

2. 请求量达到 4.48 亿，应该要用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。

3. 非热点事件时，评论量较少，看微博评论次数也相对较少，没有流量尖峰

3、整体架构设计

3、 热点事件时的高可用计算架构

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

1、 业务特性分析

1.1 热点事件发生后，绝大部分请求都落在了导致热点事件发生的那一条微博上面。而针对该条微博的请求量会非常大。

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

2、 架构设计分析

1. 转发微博评论

转发的微博评论重要性和影响力不如原微博，可以考虑对“转发微博”限流，由于转发能带来更好的传播，因此尽量少丢弃请求，考虑用“漏桶算法”。

3、 看微博评论

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