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

假设平均每天每人发一条微博，则微博的发送量是约为 2.5 亿条。

由于绝大部分微博用户看微博的对象是大 V 和明星，评论微博的对象也是大 V 和明星，大 V 和明星占发送微博总量的 50%。我们假设平均一条微博评论的人数有 100 次，则评论微博的次数为：

2.5 亿* 50%*100 = 125 亿。

大部分的人发微博集中在早上 8：00~9：00 点，中午 12：00~13：00，晚上 20：00~22：00，假设这几个时间段评论微博总量占比为 60%，则这 4 个小时的平均评论微博的 TPS 计算如下：

大部分人看微博的时间段和评论微博的时间段基本重合，因此评论微博的平均 TPS 计算如下：

125 亿* 60% / (4*3600) = 520K/s。

2.   业务特性分析

微博评论是写操作，可以用负载均衡

3.   架构分析

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

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

4.   架构设计

1. 负载均衡算法选择

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

2. 业务服务器数量估算

假设 CDN 能够承载 90%的用户流量，那么剩下 10%的评论微博的请求进入系统，则请求 TPS 为 520K/s * 10% = 52K/s，

假设单台业务服务器处理能力是 500/s，则机器数量为 104 台，按照 20%的预留量，

最终机器数量约为 130 台

5.   微博负载整体架构

6. 热点事件高可用计算架构

考虑使用 AI 算法来预估可能成为热点事件的微博。

热点事件转发或者评论，考虑使用限流和漏桶算法。如果是云原生部署，可以考虑根据热点微博发生预测和服务的性能评估，自动增加微博评论服务 pod。