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

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

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

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

一、计算性能预估

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

a. 2020.9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》）。

b. 假设平均每天每人发 1 条微博（只考虑文字微博），则微博每天的发送量约为 2.5 亿条。大部分人（60%）发微博集中在早 8:00-9:00，中午 12:00-13:00，晚上 20:00-22:00。也就是 4 个小时。假设平均每条微博被评论 10 次，则评论数是 2.5 亿*10=25 亿。如果评论微博时间和发微博时间重合，都集中在 4 小时内，微博评论的 TPS 是：25 亿*60%/（4*3600）=100K/s.

c. 假设每条评论被观看 10 次，则 QPS 是：25 亿*10*60%/(4*3600) = 1000K/s

业务特点是，用户能立刻看到自己发的评论。其他人可以延迟看到某个用户发的评论。评论发出后不能丢失。

二、非热点事件高性能计算架构

1.业务特性分析

a. 写微博评论是一个典型的写场景，不能用缓存，可用用多级负载均衡架构。

b. 看微博评论是一个典型的读操作，适用于缓存架构，请求量过亿，也要用负载均衡架构。

2.架构分析

a. 写微博评论，用户量过亿，应该用到多级负载均衡架构，覆盖 DNS->F5->Nginx->网关

b.看微博评论，同上用到多级负载均衡架构，同时用到 CDN 缓存。

3.架构设计

a.写评论依赖登录状态，登录状态保存在分布式缓存中，发评论时将请求发送给任意服务器都可以，选择轮询或随机。看微博评论不需要登录，随机发给哪个服务器都可以，用随机或轮询都行。

b. 评论内容相对微博内容简单，按照一个服务器每秒处理 2000 来估算，完成 100K/s 的 TPS，需要 50 台，加上一定的预留，写评论一共使用 55 台。

c. 看评论按一个服务器每秒处理 5000 计算，需要 200 台，加上预留 10%，一共 220 台。

d.整体架构设计

任务分配：双机房

任务分解：将写评论和看评论拆分到不同的服务。

4. 架构图

a.看微博评论的多级缓存架构

b.微博评论多级负载均衡整体架构

三、热点时间的高可用计算架构

1.架构设计分析

a.写评论和转发评论

假设有百分之 10 的用户会在事件发生后 60 分钟内转发。写评论的实时性要求不高，可采用排队+限流的办法，缓冲队列大小为 10 万；可以对转发限流，尽量少丢弃请求，用“漏桶算法”

b.看评论

热点事件存在缓存热点问题，使用“多副本缓存”。可设置看评论的阅读量阈值，根据不同等级的阅读量复制多份评论缓存到不同的缓存节点。

2.热点事件高可用架构