架构训练 模块五

1 计算性能预估

【用户量】

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

【关键行为】

1. 微博评论

1.1 用户行为建模和性能估算

考虑到微博评论是一个看得多发得少的业务，假设平均每天每人评论 10 条微博（只考虑文字评论），则微博每天评论量约为 2.24*10=22.4 亿条。

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

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

复制代码

从【看微博】性能估算来看，由于绝大部分微博用户看微博的对象是大 V 和明星，评论的也是大 V 和明星的微博，因此我们假设平均一条微博评论观看人数有 100 次，则观看微博评论的次数为：

2.24 亿* 100 = 224 亿

复制代码

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

（224 亿+22.4 亿）* 90% / (5*3600) = 1232K/s

复制代码

2 非热点事件时的高性能计算架构

2.1 业务特性分析

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

2.2 架构分析

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

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

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

2.3 架构设计

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

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

2.3.3 看微博评论的多级缓存架构

2.4 微博评论的高性能计算方案-整体架构设计

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

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

3.1 业务特性分析

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

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

3.2 架构设计分析

1. 转发微博评论

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

2. 看微博评论

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

还可以考虑在热点事件微博进行业务降级，比如说不允许评论。