1.计算性能预估

1.1 用户量预估

【用户量】

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

【关键操作】

评论微博功能分解功能可以的到发布评论和查看评论

1. 发布评论

2. 查看评论

1.2 用户行为建模和性能估算

假设平均每天每人发 1 条微博（只考虑文字微博），则微博每天的发送量约为 2.5 亿条。大部分的人发微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段发微博总量占

比为 60%，由于绝大部分微博用户看评论的对象是大 V 和明星，假设一般评论的人数只有查看人数的 1/10，那么发表评论微博大概有 10 条。

那么时间内发布的评论

2.5 亿 * 10= 25 亿

时间内的发布评论的 TPS

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

又一般微博会刷新自己的前 10 条评论，因此时间内的查询 QPS

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

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

2.1 业务特性分析

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

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

2.2 架构分析

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

查看评论，与查看微博有一样的读写压力，因此需要使用 CDN 缓存来拦截大部分的访问压力，在以多级负载均衡架构平均剩下压力。

2.3 架构设计

2.3.1 发布评论

1. 负载均衡算法选择

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

2. 业务服务器数量估算

发布评论相比发布微博是一个简单的操作，因此单台服务器的处理能力会比平均水平高，按照 2000 来估算，完成 100K/s 的 TPS，需要 50 台服务器，加上一定的预留量，大概预备 60 台服务器。

2.3.2 查看评论

1. 负载均衡算法选择

首 10 条评论不需要登录就可以查看，将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

2. 业务服务器数量估算

CDN 缓存可以减轻大概 90%的请求压力，因此 1000K/s *10%=100K/s，由于每条评论的体量不大，并且整个逻辑相对简单，按照 2000 来估算，完成 100K/s 的 QPS，需要 50 台服务器，加上一定的预留量，大概 60 台服务器。

2.4 整体架构

2.4.1 整体架构设计

对于微博这样的国民级别的系统，最好对服务进行拆分，可以根据实际情况分别进行动态扩容

2.4.2 微博评论多级负载均衡架构图

2.4.3 查看评论多级缓存架构图

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

3.1 业务特性分析

1.发布评论

评论的价值其实没有热点微博本身高，因此是允许丢失的

2.查看评论

查看评论的请求通常会集中在当时的热点微博当中

3.2 架构分析

1.发布评论

评论的价值其实没有热点微博本身高，可以考虑对“发布评论”限流，因此尽量少丢弃请求，考虑用“漏桶算法”。

2.查看评论

一切热点问题，只要数据本身容量不大，就可以使用“多副本缓存”。

3.3 架构示意图