1. 计算性能预估

1.1 用户量

2020 年 9 月 MAU 约为 5.11 亿，DAU 2.24 亿。（参考《微博 2020 用户发展报告》）。

1.2 TPS 预估

根据官方数据做出如下假设：

1. 平均每天每人发送 10 条微博评论；

2. 微博评论时间段集中在早上 8:00 - 9:00，中午 12:00 - 13:00，晚上 20:00 - 22:00，这三个时段发送评论数占评论总数 60%；

估算 TPS ：$2.5亿\ast 10/(4\ast 3600)=100K/s$

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

2.1 业务特性分析

微博评论是写操作，不能使用缓存，但可以使用写缓冲或限流，可以使用负载均衡。

2.2 架构分析

用户量过亿，考虑使用多级负载均衡架构，覆盖 DNS > F5 > Nginx > 网关的多级负载均衡。另外考虑发微博的重要性与影响力较大，微博评论与发微博应该考虑任务分解，使用独立服务器处理。

1.3 架构设计

1.3.1 负载均衡算法选择

微博评论依赖登录状态，登录状态保存在分布式缓存中。因此微博评论时将请求发送给任意服务器，选择轮询或随机算法即可。

1.3.2 业务服务器数量估算

微博评论涉及的几个关键业务处理包括：

• 内容审核

• 数据写入存储

• 数据写入缓存

综上，假设每个服务每秒能处理 1000 个请求，完成 100K/s，需要 100 台服务器。

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

3.1 用户行为建模及性能估算

热点事件评论数远远大于非热点事件，曾经最大微博评论数在几千万上下。根据以往热点事件的评论数，假设事件发生后的 2 小时内产生了 90%的评论。

估算 TPS：$1亿/2/3600\approx 15K/s$

加上非热点事件微博评论 TPS，总量约为 115K/s。

3.2 架构分析

微博评论的重要性及影响力不及原微博且实时性要求不高，并且尽量不影响普通微博评论，可以对热门微博的评论请求进行限流处理。另外可以考虑基于容器的弹性伸缩，在请求量突增时自动扩容。

3.3 架构设计

3.3.1 限流算法选择

热点微博评论由于数量较多，实时性要求不高，可选择使用不限制队列长度的漏桶算法进行限流控制。