模块 5 作业 微博评论高性能高可用计算架构

【作业要求】

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用计算架构，包括但不限于如下内容：

1）计算性能预估（不需要考虑存储性能）

2）非热点事件时的高性能计算架构，需要考虑是否要拆分独立的服务

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

性能预估

结合课件内容，假设每日观看微博的次数为 250 亿，其中每观看 10 条微博会评论一条，则每日的评论总数为 250 亿/20=12.5 亿。

评论微博的时间短和看微博的时间段一致，因此评论微博的平均 TPS 为：

12.5 亿*60%/(4*3600)=53K/s

高性能计算架构

评论微博是个典型的写操作，因此不能用缓存，考虑到用户量过亿，可以使用多级负载均衡架构，涵盖 DNS->F5->Nginx->网关。

评论微博的时候依赖登录状态，登录状态一般都是保存在分布式缓存中的，因此发微博的时候，将请求发送给任意服务器都可以，因此负载均衡算法可以使用轮询或随机。

评论微博涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），因此按照一个服务每秒处理 500 来估算，完成 53K/s 的 TPS，需要 106 台服务器，加上一定的预留量，150 台服务器可以支撑。

微博评论相比发微博来说实时性和一致性要求都没有那么高，服务的重要性也不及发微博和看微博，即便服务短时间失效，对用户的影响也不大，因此最好是拆分为独立的服务，这样不会因为微博评论业务的性能压力而影响到更重要的发微博和看微博场景。

高可用计算架构

热点事件会造成一两条微博在短时间内引来大量访问和评论，但结合微博实际数据情况，热点事件微博所收到的评论数远远不及浏览数，且评论数通常小于转发数，因此假设热点事件对应的微博平均会在 1 小时内产生 50 万条评论，则对应的 TPS 为 50w/3600≈140/s，可见对于热点事件，微博评论的性能压并不是很大。

但是另一方面，由于所有的评论全都附加到同一条微博，请求分布并不均衡，因此负载均衡架构在此会受到较大的影响。

由于微博评论的业务重要程度和影响力不如原微博，因此可以考虑对微博评论进行限流，同时考虑到越多评论将会为热点事件带来越大的影响力，因此要尽量减少丢弃请求，可以对微博评论采取写缓冲或漏桶算法的方式进行优化。