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

1.1. 用户量

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

1.2. 关键行为

1. 发微博

2. 看微博

3. 评论微博

1.3. 看评论

假设用户看 1 条微博，会看 3 页评论，则观看评论的次数为

2.5 亿 * 100 * 3 = 750 亿

60%的流量集中在 4 小时内，因此看的平均 QPS 计算如下:

750 亿 * 60% / (4*3600) = 3000K/s

1.3. 发评论

假设用户每看 10 条微博，约发表 1 次评论

2.5 亿 * 100 / 10 = 25 亿

60%的流量集中在 4 小时内，因此发评论的平均 TPS 计算如下:

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

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

2.1. 看评论

2.1.1. 业务特性分析

看评论是一个典型的读场景，由于评论发了后不能修改，因此非常适合用缓存架构，同时由于请求量很大，负载均衡架构也需要

2.1.2. 架构分析

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

2. 请求量达到 750 亿，应该要用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心

2.1.3. 架构设计

1. 负载均衡算法选择 游客都可以直接看评论，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

2. 业务服务器数量估算假设 CDN 能够承载 90%的用户流量，那么剩下 10%的读评论的请求进入系统，则请求 QPS 为 3000K/s * 10% = 300K/s，由于读取 微博的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 5000/s，则机器数量为 60 台，按照 20%的预留量，最终机器数量为 70 台。

2.2. 发评论

2.2.1. 业务特性分析

发评论是一个典型的写操作，因此不能用缓存，可以用负载均衡。 

2.2.2. 架构分析

用户量过亿，应该要用多级负载均衡架构，覆盖 DNS->F5->Nginx->网关的多级负载均衡。

2.2.3. 架构设计

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

2. 业务服务器数量估算 发评论涉及几个关键的处理:内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统)， 因此按照一个服务每秒处理 2000 来估算，完成 100K/s 的 TPS，需要 50 台服务器，加上一定的预留量，55 台服务器差不多了。
   

2.3. 服务拆分

看评论、发评论业务应该拆分服务，支持灵活提供计算资源

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

3.1. 微博热点事件用户行为建模和性能估算

热点事件指某个大 V 或者明星爆料或者官宣，虽然只有一两条微博，但引起大量用户在短时间内访问，给系统 造成很大压力。

3.1.1. 发评论

很难预估，和事件的影响力和影响范围有关。

3.1.2. 看评论

很难预估，和事件的影响力和影响范围有关。

3.2. 微博热点事件业务特性分析

3.2.1. 发评论

热点事件发生后，绝大部分评论都在了导致热点事件发生的那条微博上面。

3.2.2. 看评论

热点事件发生后，绝大部分请求都落在了导致热点事件发生的那一条微博上面。

3.3. 微博热点事件计算高可用架构分析

3.3.1. 发评论

发布评论并不是核心业务场景，业务逻辑相对简单，可以考虑对“发评论”限流，APP/H5 收到发布失败响应后，允许用户 3 秒后重试发布。由于发评论能带来更好的传播，因此尽量少丢弃请求，考虑用“漏桶算法”。

3.3.2. 看评论

很明显，热点事件微博评论存在缓存热点问题，可以考虑“多副本缓存”，由于原有的缓存架构已经采用了“应用内的缓存，总体上来看，缓存热点问题其实不一定很突出。