业务架构训练营，模块 5 作业，微博评论高性能架构

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

【作业要求】基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用计算架构，包括但不限于如下内容：1）计算性能预估（不需要考虑存储性能）2）非热点事件时的高性能计算架构，需要考虑是否要拆分独立的服务 3）热点事件时的高可用计算架构

【提示】分析方法对照“看微博”和“发微博”的案例。

1. 用户行为和性能估算

1. 2020.9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》）。假设平均每天每人发 1 条微博（只考虑文字微博），则微博每天的发送量约为 2.5 亿条。大部分人（60%）发微博集中在早 8:00-9:00，中午 12:00-13:00，晚上 20:00-22:00。也就是 4 个小时。假设平均每条微博被评论 10 次，则评论数是 2.5 亿*10=25 亿。

2. 如果评论微博时间和发微博时间重合，微博评论的 TPS 是：25 亿*60%/（4*3600）=100K/s

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

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

2. 非热点事件高性能架构设计

核心业务功能分为发评论和看评论两部分。

2.1 发评论

2.1.1 需求分析

发评论的需求是，不需要马上看到，所以可以用写缓存的方式。写缓存通过 Redis 的方式，先写入 Redis，返回成功，再写入数据库。

2.1.2 架构分析

数据流需要是 DNS->F5->LVS->Nginx->网关->Redis->database。

客户端有本地缓存，服务端有 Reids 缓存。

2.1.3 架构设计

因为是非热点事件，负载均衡算法采用简单的 round robin 轮询即可。如果是 64 核服务器，每台机器 1.6k/s 的处理速度，完成 100k/s 的处理，需要 63 台服务器，安排预留 20%的服务器，大致需要 76 台服务器。

2.2 看评论

2.1.1 需求分析

QPS 很高，需要缓存和负载均衡架构。

2.1.2 架构分析

数据流需要是 DNS->CDN->F5->LVS->Nginx->网关->Redis->database。先通过 CDN，没搜到再往后处理。Redis 直接读数据。Redis 没有的时候，再访问 database。

客户端有本地缓存，服务端有 Reids 缓存。

2.1.3 架构设计

CDN 要达到过滤 90%流量的要求，实际进系统的是 100K/s。同时两台 Redis 服务器挡住大于 50%的流量，所以，大概是 50K/s 的流量。如果是 64 核服务器，每秒处理 2k/s 的读请求。则大约 25 台机器即可。

3. 热点事件高可用架构设计

可以基于非热点事件，增加额外的处理。

比如服务降级，当流量太大的时候，使用 QoS 的方式，按客户重要性配置服务的级别，给某些 VIP 用户先看，普通用户后刷新。

比如放到多个 CDN，这样可以及时得到数据。

比如放多个 key，这样用户可以直接根据他能访问到的 key 来确定。