微博评论高性能高可用架构

一、评论微博

【性能预估】

评论一般比发微博要多，如果假设平均每天每人发微博一次，那么评论微博按 3 倍来算，即每人每天发 3 条评论，则评论微博预计每天发送量是 2.5 亿*3=7.5 亿；

评论微博的时段估算同发微博，预计 60%集中在早上 8：00-9：00，中午 12：00-13：00，晚上 20：00-22：00 这 4 个小时中，所以这 4 个小时的平均 TPS 计算如下：

7.5 亿*60%/（4*3600）= 30k/s

【业务特性分析】

评论是个写操作，不能用缓存，可以使用负载均衡；评论微博的重要性和时效性可以弱于发微博，可以采用写缓冲

【架构分析】

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

【架构设计】

1.负载均衡算法选择

发评论时候可以发送请求到任意一台服务器，“轮询”或“随机”算法都可以满足

2.写缓冲的选择

这里用“容量无限”的消息队列 kafka 作为写缓冲，暂时缓冲无法被及时消化的请求，业务服务器收到请求后写入 kafka 即返回成功

3.业务服务器数量估算

评论微博涉及数据写入消息队列、接收队列数据、内容审核、写入持久化存储，按照每个服务器 500tps 来估计，完成 30k/s 预计需要 75 台，算上预留，可以按 80 台来准备。即使略微超过算力，也可以缓存在消息队列，慢慢消费

二、看微博评论

【性能预估】

一般看评估是肯定看过微博的，所以看评论会比看微博要多。因为一个微博的评论一般会看 1-3 页，所以这里也假设看评论是看微博的 3 倍请求次数，则估算为：

250 亿（看微博的预估量） * 3 = 750 亿

看评论的时段也和看微博重合，预计 QPS：

750 * 60%/（4*3600）= 3000K/s

【业务特性分析】

评论发了以后不能修改，所以非常适合用缓存架构，请求量也很大，也要用负载均衡架构

【架构分析】

1.用户量过亿，要使用多级负载均衡，覆盖 DNS->F5->Nginx->网关

2.请求量达到 750 亿，要使用多级缓存架构，尤其是 CDN

【架构设计】

1.负载均衡算法选择

任一服务器都能处理请求，因此使用轮询或者随机算法即可

2.业务服务器数量估算

同看微博的估算，预计 CDN 要挡住 90%的流量，剩下的 10%进入业务服务器，则 QPS 为：3000K/s * 10% = 300K/s；读业务比较简单，直接读取缓存即可，按照每台 1000QPS 来估算，预计需要：

300 台，按照 20%预留，最终需要 360 台

三、微博评论整体架构

多级负载均衡架构

整体架构设计

发评论和写评论与发微博和写微博有业务差异，建议将评论和微博分拆到不同业务；

同时发评论和写评论也有业务差异，也是建议分拆到不同业务，同时能够隔离故障域，防止既不能发又不能写的情况出现；

四、 微博评论热点事件高可用计算架构

【发评论】

发评论的架构中有消息队列作为写缓冲，在遇到热点事件产生大量评论时可以作为缓冲，通过控制消费线程数量来控制处理速率，从而满足高可用设计；

【看评论】

热点事件发生后，绝大部分请求都落到热点事件那条微博的评论下面，可以考虑“多副本缓存”