业务分析

业务描述：

• 用户可以对自己/他人的一条微博进行评论

• 用户也可以一条微博下的一条评论进行评论

• 用户可以对一条微博下的一条评论点赞

• 用户点开一条微博，默认按热度排序，显示评论和 1-2 条评论的热门回复。热度同评论的被点赞数、被回复数量、评论用户的活跃度相关。

• 用户点开一条评论的回复，默认按热度排序，显示这条评论相关的回复

综上所述，微博评论的主要行为有：

1. 发评论

2. 查看评论

3. 点赞评论

用户行为建模

用户量：

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

访问时段：

大部分的人刷微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00

性能估算：

假设 1：用户平均人每天发 1 条微博，每天发送 2.5 亿条，每条微博在 7 天内平均被观看 1000 次。每 1000 次阅读，被点赞 10 次，3 条评论。每天 60%的发评论集中在高峰访问的 4 小时内。

发评论的 TPS = 2.5 亿 X 3 条 X 60% / （7 天 X 4 X 3600 ) = 4464/s

假设 2：用户平均每天刷 100 条微博，平均每 20 条微博，用户会打开查看其中一个微博的评论查看。打开评论后，用户查看评论的回复的概率为 1/4。

查看评论的 QPS = (2.5 亿 x 5 + (2.5 x 5 / 4) ) x 60% / (4 x 3600) = 54k/s

假设 3： 用户每查看一次评论列表，点赞的概率为 1/2

点赞评论的 TPS = (2.5 亿 x 5 + (2.5 x 5 / 4) ) x 0.5 x 60% / (4 x 3600) = 27k/s

复杂度分析

虽然微博评论看似是个主要在“写评论”的业务，但实际上，读评论，以及点赞计数的请求量更大。

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

架构设计：

1. 存储设计

• 本方案存储选型为关系型数据库 mysql+redis 缓存。

• 评论存储时，根据评论的微博编号，sharding 到同一个数据库的同一张表内。

• mysql 根据 微博编号+ 评论对象 +评论时间 创建索引。

• 通过 redis 缓存，以评论对象的编号作为 key，缓存按热度排序的评论列表。

• 热度排序的评论列表按一定时间内被评论对象的是否有新评论/点赞触发刷新。

• 微博用户主要访问的时日期最新的微博内容。微博发布一段时间后，评论相关访问几乎为零。可以把超过一个季度的旧微博归档到访问频率较少的归档数据库内存储。

2. 负载均衡算法选择

任何用户都可以发评论和看评论，使用“轮询”和“随机”算法。

3. 服务器数量估算

发评论和点赞评论使用同一个系统，一共需要 31k/s 的 TPS。按照一个服务每秒处理 500 来估算，需要 62 台服务器，加上一定的预留量，需要大约 70 台服务器。

根据用户行为建模，查看评论需要使用 CDN 缓存承载用户流量。假设 90%的流量走缓存，10%进入请求系统。则请求 QPS 为 5400/s，读取评论主要是读缓存系统，此假设单台业务服务器处理能力是 1000/s，则需要 6 台，按 10 台预留。

可以看出虽然看评论的用户流量要大于发评论和点赞评论。但因为看评论可以走缓存，服务器的主要请求压力在 TPS 上。由于看微博的服务器需求远小于发评论，为了减少系统复杂度，可以把这三个子业务放在一个系统内，不做服务器单独拆分。一共需要服务器：80 台