作业题目

设计微博系统中”微博评论“的高性能高可用计算架构。

【作业要求】

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其

高性能高可用计算架构，包括但不限于如下内容：

1. 计算性能预估（不需要考虑存储性能）；

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

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

【提示】

1. 分析方法对照“看微博”和“发微博”的案例。

作业内容

性能预估

发微博人均每天一条，看微博平均每条 100 次，微博评论介于这两者直接，预估为每条微博评论为 10 条，则每天评论总量为：

2.5 亿*10=25 亿条

微博评论和发微博看微博时间分布一致，都是集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段发微博总量占比为 60%，则这 4 个小时的平均微博评论的 TPS 计算如下：

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

高性能计算架构

服务拆分

考虑到微博评论数量的不确定性，热门微博的评论数量远远高于普通微博，故将评论拆分为独立的服务，以提升性能和可用性。

业务特性分析

微博评论和写微博类似，使用负载均衡。

架构分析

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

架构设计

1. 负载均衡算法选择

微博评论的时候依赖登录状态，可选择“轮询”或者“随机”算法。

2. 业务服务器数量估算

微博评论和写微博类似，但业务复杂度更低，故按照一个服务每秒处理 1000 来估算，完成 100K/s 的 TPS，需要 100 台服务器，加上一定的预留量，最终为 120 台服务器。

负载架构图

多级负载架构基本和发微博一致，基本如下：

高可用计算架构

微博评论重要性和影响力不如原微博，当发生热点事件时，可以考虑对“微博评论”限流，尽量少丢弃评论请求，考虑用“漏桶算法”。

为降低对业务的影响，尽可能减少丢弃评论请求的数量，考虑将消息队列的长度尽可能设置大，提高系统冗余性。

其漏桶算法的高可用架构图和发微博高可用架构图基本一致，不再赘述。