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

【评论微博】

考虑到大部分人只看微博不评论微博，假设有 40%的人看完微博后会评论微博，且评论微博和看微博的时间段基本一致，因此评论微博的 TPS 大概为看微博 QPS 的 40%：

1000K/s × 40% = 400K/s

【看评论】

考虑到绝大部分人看微博后会顺便查看评论，假设有 80%的人看完微博后会查看评论，且看微博和看评论的时间段基本一致，因此看评论的 QPS 大概为看微博 QPS 的 80%：

1000K/s × 90% = 800K/s

2. 高性能计算架构设计

2.1 评论微博

【业务特性分析】

1. 评论微博是一个典型的写操作，因此不能用缓存，可以用负载均衡。

2. 评论微博不像写微博一样，评论后可能被刷屏了，不需要立马看到评论内容，即用户对实时性的要求不是很高，因此可以考虑使用写缓冲来适当降低成本。

【架构分析】

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

【架构设计】

1. 负载均衡算法选择

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

2. 业务服务器数量估算

评论微博涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 500 来估算，完成 40K/s 的 TPS，需要 80 台服务器，加上一定的预留量，90 台服务器差不多了。考虑可以采用写缓冲，实际部署的服务器可以减少，假设可以容忍 1 倍的时间延迟，服务器数量可以缩减到 45 台。

【评论微博的多级负载均衡架构】

同写微博的，服务集群中“写微博”服务改成“评论微博”服务即可，数量改为 45 台

2.2 看评论

【业务特性分析】

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

【架构分析】

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

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

【架构设计】

1.负载均衡算法选择

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

2. 业务服务器数量估算

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

【看评论的多级负载均衡架构】

同看微博的，服务集群中“看微博”服务改成“看评论”服务即可，数量改为 100 台

【看评论的多级缓存架构】

同看微博的

2.3 整体架构

任务分配：双机房、三机房

任务分解：将评论微博和看评论分拆到不同服务

【多级负载均衡整体架构】

同课程的，“写微博”改为“评论微博”，“看微博”改为“看评论”即可

【多级缓存整体架构】

3. 高可用计算架构设计