第五周作业 - 微博评论高性能高可用的计算架构

作业要求：

1.计算性能预估

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

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

性能估算

1.用户量预估

1.1 用户量：

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

1.2 关键行为：

发评论：支持回复楼层、楼中楼

2.用户行为建模

2.1 发评论

微博是一个看得多发的少的业务，假设平均每天每人发 1 条微博，则微博每天的发送量约为 2.5 亿条。假设每条微博评论为 3 条，则评论数为 7.5 亿条。

大部分的的人发微博在早上 8：00-9：00，中午 12：00-13：00，晚上 20：00-22：00，假设这几个时间段的发微博总量占比 60% 且微博会有评论的情况占比也是 60%，则这 4 个小时平均发评论的 TPS 计算如下：

7.5 亿 * 0.6*0.6 / (4*3600) ≈ 18K/s

2.2 看评论

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

7.5 亿*100 = 750 亿。

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

750 亿 * 0.6 /(4*3600) = 3000K/s

3.性能需求计算

3.1 发评论

业务特性区别于发微博，因为用户发完评论可能已经被刷到自己也看不到的情况，因此可以用写缓存。架构分析用户过亿，应该用多级负载均衡架构，覆盖 DNS->CDN->Nginx->网关的多级负载均衡。负载均衡算法选择发评论的时候依赖登录状态，登录状态一般都是保存在分布式缓存中的，因此发评论的时候，可以将请求发送给任意的服务器，选择轮询或者随机算法。

业务服务器估算发评论设计几个关键的处理：内容审核、数据写入存储、数据写入缓存，因此按照一个服务器每秒处理 500 来估算，完成 18K/s 的 TPS，需要 36 台服务器，加上一定的预留量，选择 40 台服务器。

多级负载架构图

多级缓存架构图

3.2 看评论

业务特性分析看评论是一个典型的读场景，由于评论发了不能修改，因此非常适合用缓存架构，同时由于请求量很大，负载均衡也需要。

架构分析用户量过亿，应该使用多级负载均衡架构和 CDN 服务

负载均衡算法选择游客可以直接看评论，因此将请求发送给任务服务器都可以，选择轮询或者随机算法

业务服务器数量估算假设 CDN 的命中率在 98%，剩下的 2%读评论系统请求进入系统，则请求 QPS 为 3000K/s * 2% = 60K/s,由于读评论的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 1K/s,则机器数量为 60 台，按照 20%的预留量，最终机器为 80 台。

多级负载架构图

多级缓存架构图

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

任务分配：双机房、三机房

任务分解：基于业务场景关联度和请求量将发评论和看评论分拆到不同服务

合并总体负载架构图

多级缓存图，和读写缓存架构一致

4.热点事件设计

• 业务特性分析

发评论和一般的发评论类似

看评论热点事件发生后，绝大部分评论都落在了热点事件的那一条微博下的评论

• 架构设计分析

发评论可以考虑对评论进行限流，由于评论最好不要丢弃，因此尽可能少的丢弃请求，考虑用漏桶算法

看评论热点事件的评论也可能存在热点问题，可以使用多副本缓存，由于原来的架构本身已经采用了应用内的缓存，总体上来看，缓存热点问题不一定很突出

看评论如下

写评论如下：