模块 5 作业 -”微博评论“的高性能高可用计算架构

1. 用户量

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

2. 用户行为建模和性能估算

2.1 发微博评论

假设平均一条微博观看人数有 100 次，20%的人看后会发表评论，则发微博评论每天的发送量为：

2.5 亿* 100* 10% = 25 亿。

大部分的人发评论集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段发评论总量占比为

60%，则这 4 个小时的平均发评论的 TPS 计算如下：

25 亿* 60% / (4 * 3600) ≈ 100 K/s。

2.2 看微博评论

看微博的人基本都看评论，因此观看微博评论的次数为：

2.5 亿* 100 = 250 亿。

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

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

3. 高性能计算架构设计

3.1 发微博评论

3.1.1 业务特性分析

发微博评论是一个典型的写操作，热点事件时高频发生，但用户对数据实时性要求不高。

3.1.2 架构分析

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

（2）数据实时性要求不高，可以用消息中间件进行消峰。

3.1.3 架构设计

（1）负载均衡算法选择

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

（2）业务服务器数量估算

发评论涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 500 来估算，完成 100K/s 的 TPS，需要 200 台服务器，考虑到使用消息队列进行了消峰，50 台服务器差不多了。

（3）考虑到总体用户量比较大，为了保证可用性，发评论服务独立部署。

3.2 看微博评论

看评论业务特性与看微博类似，架构设计相同。

3.2.1 架构设计

（1）负载均衡算法选择

游客都可以直接看评论，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

（2）业务服务器数量估算

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

（3）考虑到总体用户量比较大，为了保证可用性，看评论服务独立部署。

4.总体架构

41.多级负载均衡整体架构

4.2 多级缓存整体架构

5.热点事件的应对

（1）发评论服务由于使用了消息中间件，服务本身具有很好的应对热点事件的能力，如写请求量太大，可通过漏桶算法进行限流。

（2）整个微博系统进行服务降级，释放资源支持核心功能，保证看微博、看评论服务的正常，可依次降级转发、写评论、写微博服务。业务重要性如下：看微博 》看评论 》写微博 》写评论 》转发。