架构训练营模块五作业

计算性能估算

用户量

月活 5.11 亿，日活 2.24 亿

评论微博

微博评论是看得多发得少的业务，评论数量又比微博数量要大，假设平均每人每天发布 4 条评论，则微博每天的评论数量约为 10 亿条。

大部分人发表评论的时间集中在早上 8：00~9：00，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段评论微博总量占比为 60%，则这 4 个小时的平均评论微博的 TPS 约为 42k/s。

看评论

看评论通常与看微博同时发生，因此我们假设看评论与看微博情况基本相同，假设平均一条评论观看人数有 100 次，则观看评论的次数为 250 亿。

看评论 TPS 约为 1000k/s。

架构设计

评论微博

业务特性分析

评论发表是写操作，评论本身的交互性与扩展性均弱于微博内容，对实时性的需求较弱。可以使用写缓存提示系统吞吐量。可以使用负载均衡。

架构分析

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

架构设计

1. 负载均衡算法选择

评论发布依赖登陆状态，登录状态一般保存在分布式缓存中，因此没有要发送至特定机器的需求。可以使用“轮询”或“随机”算法。

2. 写缓存

采用数据分片+缓存来提升评论写于性能。

3. 业务服务器数量估算

发评论设计几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此安装一个服务每秒处理 500 来估算，完成 42k/s 的 TPS，需要 84 台服务器，加一些预留量，共需 100 台服务器。

发评论的多级负载均衡架构

看评论

业务特性分析

看评论是典型的读场景，同时评论发布之后无法修改，因此非常适合用缓存架构，同时请求量很大，负载架构也需要

架构分析

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

请求量 250 亿，要使用多级缓存架构，尤其是 CDN 缓存，可以帮助消化大量的流量

架构设计

1. 负载均衡算法选择

评论均可以查看，因此没有要发送至特定机器的需求。可以使用“轮询”或“随机”算法。

2. 业务服务器数量估算

假定 CDN 能够承载 90%的流量，则 QPS 为 100k/s。又业务逻辑主要为读取缓存系统，因此假设单台服务器处理能力为 1000/s，按照 20%的预留量，则机器数量为 120 台。

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

看评论的多级缓存架构