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

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

课上得出观看微博的次数为：250 亿，平均 QPS 为：1000K/s。

写微博评论：

写微博评论依赖看微博，假设看完一条微博，用户写评论的概率为 10%，则写微博评论次数为：25 亿，平均 TPS 为：100K/s。

看微博评论：

看微博评论依赖看微博，一般看完一条微博后，都会刷一下评论，所以看微博评论次数为：250 亿，平均 QPS 为：1000K/s。

2. 非热点事件时的高性能计算架构

将写微博评论、看微博评论拆分为独立的服务。

写微博评论：

【业务特性分析】

写微博评论是一个典型的写操作，但是用户对评论的实时性一般要求不高，但是写好的评论数据不能丢失，否则会引起用户的不满。

【架构分析】

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

由于写微博评论的实时性要求不高，可以引入漏桶或消息队列作为写缓冲。

【架构设计】

1.负载均衡算法选择

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

2.业务服务器数量估算

写微博评论涉及几个关键的处理：内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统)，因此按照一个服务每秒处理 500 来估算，完成 100K/s 的 TPS，需要 200 台服务器，加上一定的预留量，250 台服务器差不多了。

看微博评论：

【业务特性分析】

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

【架构分析】

用户量过亿，应该要用多级负载均衡架构。

请求量达到 250 亿，应该要用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。

【架构设计】

1.负载均衡算法选择

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

2.业务服务器数量估算

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

 负载均衡整体架构设计

多级缓存整体架构设计

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

由于写微博评论和看微博评论的重要性不高，可以对其进行限流、降级或熔断。