架构营模块五作业

微博评论模块的核心功能就是看评论和发评论。而对于发评论和看评论来说，看评论需要的性能会更高，毕竟微博用户大部分是看评论的请求更多，而发评论的比较少。

1.性能评估

1.1 发评论

根据第六模块看微博的人次为 250 亿来估算，假设有 1%的观看次数会转换为发评论就会有 2.5 亿的发评论次数。同时大部分的发评论的时间与看微博的时间基本重合，所以可以推算出发评论的 TPS 大约为

2.5 亿*60%/(4*3600) = 10K/s。

1.2 看评论

考虑到看微博用户不一定会看到所有评论内容，可能用户只会看前几条的评论，所以假设用户只会浏览微博的前 10 条评论，又考虑到并不是所有微博都会有评论，因此设置一个 0.5 的阈值，所以看微博的 QPS 大约为

250 亿*10 条*0.5*60%/(4*3600) = 5000K/s。

2.非热点时间的高性能计算架构

根据性能评估结果，需要将评论功能单独部署，并且因为看评论的性能需求远大于发评论，看评论和大评论同样需要分开部署。

2.1 发评论

发评论属于写操作，不可以使用缓存，可以考虑使用负载均衡，将写请求分散到多台服务器上进行处理。考虑到用户过亿，需要用到多级负载均衡：DNS->F5->Nginx->网关->写服务。负载均衡算法可以采用轮询或者随机的方式将请求转发给后端的写服务。同时评论内容是需要内容审核系统切需要写入数据库，所以按照一台服务器每秒处理 500 来估算，每秒处理 10K 大约需要 20 台服务器。加上一些预留，可以增加到 25 台服务器。

2.2 看评论

看评论属于读操作，而且 QPS 非常高，所以需要使用多级缓存系统，同时请求高还需要使用多级负载均衡。缓存可以使用 CDN，这样基本可以承载 90%的用户访问量，剩余 10%(500K/s)的访问量通过负载均衡的轮询或者随机算法将请求分散到分布式缓存上，读请求相比写请求处理比较简单，只需要从缓存中读取数据即可，所以处理能力每台可以达到 1000/s，则需要 500 台服务器，考虑到预留，最终需要 550 台。

3.热点事件的高可用计算架构

对于热点事件，发评论和看评论的请求会激增，为了保证服务器的可用性，需要考虑服务器的计算高可用。

3.1 发评论

热点事件会导致发评论的请求增加，为了防止比平时过多的写评论压垮服务器，需要做限流。可以考虑使用漏桶算法，在请求以及处理服务器之间加上一个写缓存队列，防止同一时间大量的写请求压垮服务器。当写队列已满，只能牺牲一定数量的写请求，将其直接丢弃。

3.2 看评论

为了应对更多的看评论请求，可以使用多副本缓存进行应对，使用多副本缓存将对热点事件的同一评论 de 读请求分散到多台服务器上，通过增加服务器防止对同一评论内容的访问，导致服务器的崩溃。