【架构实战营】第 5 模块作业

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

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

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

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

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

【发微博评论】

微博评论：看微博的人，只有少数人会发评论，一般都只是看看。根据发微博每天平均 2.5 亿条，假设观看人数 100 人中，平均只有 10%的人发表了评论，那么每条微博就有 10 条评论，则微博评论每天的发送量约为 25 亿条。

大部分人发送微博评论的时间段和发微博的时间段基本重合，因此在这 4 个小时内，发送微博评论的平均 TPS 计算如下：

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

这个 TPS 的数量，是发微博的 10 倍。

【看微博评论】

看微博时，一般都会看一下评论，因此看微博评论的 QPS 和看微博的 QPS 相同：

250 亿 * 60% / (4*3600) = 1000K/s

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

发微博评论是一个写操作，但数据实时性要求不高（自己可以先看到，其他人可以延时一段时间再看到）。因为发微博评论的 TPS 较高，因此可以用负载均衡 + 缓存来实现，负载均衡用来将评论写请求分配到不同的应用服务器，缓存用来延缓大量写操作请求对应用服务器造成的冲击，减少处理服务器数量。

【架构分析】

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

2. 请求量达到 100K/s，应该要用多级缓存架构，评论不是所有人都会看，存在 CDN 上不合适。使用 App 缓存 + Web 容器缓存，减少到达服务器请求的的 TPS。

【架构设计】

1. 负载均衡算法选择

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

2. 业务服务器数量估算

发微博评论涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统）。

不考虑使用缓存，按照一个服务每秒处理 500 来估算，完成 100K/s 的 TPS，需要 200 台服务器，加上一定的预留量，250 台服务器差不多了；

如果使用写缓存，每个评论请求处理被缓存，TPS 可能下降 1/4，达到 75K/s，这样就只需要 150 台，加上预留量，大概需要 200 台服务器。

多级负载均衡整体架构 —— 同发微博的负载均衡架构。

多级缓存整体架构：

【服务拆分】

发微博评论的 TPS 比较高，尤其是遇到热点事件，因此发微博评论的服务需要拆分出来。

看微博评论的服务可以和看微博放在一起，因为只是多增加了一个微博对应评论的查询操作。

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

【架构设计分析】

1. 发微博评论

对“发微博评论”限流，尽量少丢弃请求，考虑用写缓冲架构，在接入服务器中使用写缓冲。