性能预估

基于第六课中对于发微博的预估，每个用户每天发一条微博，然后为 4 个小时主要活动时间，发微博的 TPS 为 10k/s。

这里预估发微博：评论 = 1：10，那么发评论的 TPS 为：2.5 亿*10*60%/(4*3600) = 100k/s。

阅读评论，一条微博有 100 个人看评论,发微博和阅读评论比例为 1：100，那么阅读评论的 TPS 为：2.5 亿*100*60%/(4*3600) = 1000k/s。

发评论

高性能架构设计

业务特性

评论是写操作，不涉及缓存，可以使用负载均衡到不同的后端服务分摊写压力

架构分析

用户量过亿，需要使用多级负载均衡架构，DNS，F5，Nginx

架构设计

1. 负载均衡算法

选择随机，轮训任选一种

2. 业务服务器估算

写评论也涉及内容审核，持久化。但是评论，可以只针对发送评论的用户先本地，然后其他用户延时可看，所以，可以使用客户端缓存加审核和持久化异步处理方式，减少业务服务器的成本投入。假设一台服务器一秒能处理 500 条，每秒 100k 的写评论请求，但是 90%的评论很多人都是不会看的，所以每秒实时处理 10k 评论，剩余 90k 异步处理即可。需要的服务器为 20 台实时处理，考虑到备用和异步处理，则选择 40 台服务器即可。

热点事件

异步写评论使用的是 MQ，理论上 MQ 可以支撑海量写事件。使用限流，防止同一时间过多的评论请求打到后台服务器。

看评论

高性能架构设计

业务特性

看评论读操作，涉及大量缓存，使用 5 层缓存架构和负载均衡

架构分析

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

2. 使用 DNS

架构设计

1. 负载均衡算法

选择随机，轮训任选一种

2. 业务服务器估算

DNS 可以拦截 90%的请求，实际请求到后台的 QPS 为 100k/s。一台服务器能处理的 QPS 为 1000/s，那么需要的服务器数量为 100 台，加上 20%的预留，选择 120 台服务器。

热点事件

缓存复制到不同的节点上，实行限流，防止打垮整个集群。