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

一、评论微博

【性能预估】

评论一般比发微博要多，如果假设平均每天每人发微博一次，那么评论微博按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台

三、微博评论整体架构

多级负载均衡架构

整体架构设计

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

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

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

【发评论】

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

【看评论】

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