架构训练营 - 模块五

【评论微博】

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

【评论微博】

假设大部分人看微博发评论的时间集中在 8：00~22：00，，则这 14 个小时的平均发评论的 TPS 计算如下

2.5 亿 * 60% / (14 * 3600) ≈ 3 K/s。

假设热点事件出现时有 500 万人在一个小时内评论, TPS 计算如下

500 万 / 3600  ≈ 2K/S

【看评论】

由于大 V 和明星微博的评论数比较大，每次动态加载一部分评论，假设用户每天看评论请求数为 100，QPS 计算如下

2.5 亿 *10 * 60% / (14 * 3600) ≈ 300K/s。

假设热点事件出现时有 1000 万人同一个小时内同时看评论, 按每人 50 次读请求，QPS 计算如下

1000 万 * 50 / 3600  ≈ 140K/S

【业务特性分析】 

发微博评论对实时要求比较低，可以采用队列异步写入。 

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

【架构设计】

1. 负载均衡算法选择

需要考虑热点信息和非热点信息，所以采用基于请求数的权重算法

2. 业务服务器数量估算

正常情况下：

写评论按照一个服务每秒处理 1000 来估算，完成 3K/s 的 TPS，需要 5 台服务器。

假设 CDN 能够承载 90%的用户流量，那么剩下 10%的读微博的请求进入系统。读评论按照一个服务每秒处理 3000 来估算，完成 30K/S 的 QPS，需要 100 台服务器。

总计需要 105 台服务器

热点事件情况下：

读写请求数暴涨，为了保障系统稳定运行，采用独立集群处理热点事件的读写。

写评论按照一个服务每秒处理 1000 来估算，完成 2K/s 的 TPS，需要 3 台服务器。

假设 CDN 能够承载 90%的用户流量，那么剩下 10%的读微博的请求进入系统。读评论按照一个服务每秒处理 3000 来估算，完成 14K/S 的 QPS，需要 50 台服务器。

总计需要 53 台服务器

架构图如下