架构实战 - 模块五

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

【作业要求】

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用计算架构，包括但不限于如下内容:

1. 计算性能预估(不需要考虑存储性能);

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

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

【提示】

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

1.现状

根据《微博 2020 用户发展报告》，2020.9 月月活 5.11 亿，日活 2.24 亿。大部分用户的互动时段在 8:00~10:00、12:00~13:00、17:00~18:00、22:00~23:00。

热点事件时，评论一般都集中在某几个大 V 的评论区或热门的话题中，访问量是时平时的 10~1000 倍。

2.复杂度分析

发评论：假设平均每天每人发 1 条评论，约有 60%的人都是在 8:00~10:00、12:00~13:00、17:00~18:00、22:00~23:00 这段时间发表的评论。

发表评论的 TPS = 2.5 亿 * 0.6 /(5*3600) ≈ 0.8 万/s

看评论：每人每天平均会看 100 条评论，看评论的时间段和发表评论的时间段大致相同。

看评论的 QPS = 2.5 亿 * 100 * 0.6/(5*3600) ≈ 80 万/s

3.高性能设计

3.1 发评论

3.1.1 业务特性分析

发评论是一个典型的写操作，因此不能用缓存，可以用负载均衡。发评论的实时性要求没有那么高，但如果评论丢失了就需要用户重新发，如果因为突发的热点事件导致发评论大量丢失将会影响用户体验，因此可以利用 kafka 采用异步的方式发表评论。

3.1.2 架构分析

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

2 四级负载均衡：DNS => F5/LVS => Nginx 集群 => 网关集群

3.1.3 架构设计

• 负载均衡算法选择

发评论的时候依赖登录状态，登录状态一般是保存在分布式缓存中的，因此发表评论的请求可以发送给任意的服务器，负载均衡可以采用轮询或随机的算法。

• 业务服务器数量估算

假设一个服务器的处理能力是 500 每秒，则处理 0.8 万/s 的 TPS 需要 16 台服务器，加上一定量的预留量，共 20 台即可。

3.2 看评论

3.2.1 业务特性分析

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

3.2.2 架构分析

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

2 请求量达到 250 亿，应该用四级缓存架构：APP/浏览器缓存=>CDN 缓存=>Web 容器缓存=>redis 分布式缓存。

3.2.3 架构设计

• 负载均衡算法选择

任何人在任何登录状态下都可以查看评论，因此查看评论的请求可以发送给任意的服务器，负载均衡可以采用轮询或随机的算法。

• 业务服务器数量估算

微博的评论列表是通过热度降序分页的形式展示的，而大部分人都只会查看评论的前 10 页。假设利用 CDN 技术能够承载 90%的用户流量，剩余的 10%用户进入系统，则请求的 QPS=80 万/s *0.1 = 8 万/s。因为进入系统的用户，主要是读系统的缓存，因此假设每台服务器的处理能力是 1000 每秒，则需要 80 台服务器，加上一定量的预留量，共 100 台即可。