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高可用架构图