1.性能估算

[发评论]

假设平均每天每人发 2 条评论，日活用户量为 2.5 亿，则微博发评论的发送量为 5 亿条，而且大部分的人发评论集中在早上 8:00-9:00，中午 12:00-13:00，晚上 8:00-10:00，假设这几个时间段的发评论占总量的 80%，则这四小时的平均发评论的 TPS：5 亿 * 80% / （4 * 3600）= 3w/s

[看评论]

由于绝大部分用户看评论的对象是一些热点事件和大 v 明星，因此假设一个人平均看 10 条评论，平均每条评论观看人数为 100 次，则观看评论的次数为 2.5 亿 * 10 条 * 100 次 = 2500 亿

大部分人看评论的时间和发评论的时间基本一致，因此看评论的平均 QPS 为

2500 亿 * 80% / (4 * 3600) = 1500w/s

2.发评论

2.1 业务特征分析

发评论是一个写操作，不需要缓存

2.2 架构分析

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

2.3 架构设计

2.3.1 负载均衡算法选择

发评论依赖于登陆的状态，登陆状态一般保存在分布式缓存中，因此发评论的时候，可以将请求转发到任意服务器，所以负载均衡算法可以选择"轮询"或者"随机"算法

2.3.2 业务服务器数量的估算

发评论涉及到：内容审核，数据写入存储，数据写入缓存。因此按照一个服务器每秒处理 300 来估算，完成 3w/s 的 TPS，大约需要 130 台服务器

2.3.3 发评论的多级负载均衡架构

3.看评论

3.1 业务特征分析

看评论是一个读操作，由于一般评论发完之后不能修改，因此可以用缓存架构，由于请求量大，也需要负载均衡架构

3.2 架构分析

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

请求量达到 2.5 万亿，应该要用多级缓存架构，使用 CDN 缓存

3.3 架构分析

3.3.1 负载均衡算法选择

游客可以看前几条评论，因此将请求发送到任意服务器都可以，采用"轮询"或"随机"算法

3.3.2 业务服务器数量估算

一般评论只会看一条微博的前 100 条，假设 CDN 能够承载 95%的用户流量，那么剩下的读评论的请求进入系统，则请求 QPS 为 1500w/s * 10% = 150w/s，假设单台业务服务器处理能力是 1000/s，则机器数量为 1500 台，按照 20%的预留量，最终机器数量为 1800 台

3.3.3 看评论的多级负载均衡架构

3.3.4 看评论的多级缓存架构

4.微博评论高性能计算方案

4.1 整体架构设计

4.2 多级负载均衡整体架构

4.3 多级缓存整体架构

5.微博评论计算高可用架构设计

5.1 高可用架构分析

1.发评论的重要性一般不如微博内容，可以对发评论进行限流，采用"漏桶算法"尽量降低丢弃请求

2.看评论一般可以通过分布式缓存整一个评论列表，热点评论可以采用 CDN 缓存进行每小时定时刷新数据，一般缓存 10 页左右的评论列表数据

5.2 高可用架构图