架构实战营 - 第 6 期 模块五课后作业

一、计算性能预估

【用户量】

1. 2020.9 月月活 5.11 亿，日活 2.24 亿（参考《微博 2020 用户发展报告》）。

关键行为：评论微博

考虑到微博是一个看得多评论的少的业务，基于发微博和看微博的数据分析，我们假设平均一条微博观看人数有 100 次，其中有 30%的观看者会发出评论，则发评论的数量为：

2.5 亿 * 100 * 30% = 75 亿。

大部分人评论微博的时间段和看微博的时间段基本重合，因此评论微博的平均 PS 计算如下：

75 亿 * 60% / (4*3600) ≈ 300 K/s。

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

【业务特性分析】

微博评论是一个既有写，也有读的场景，由于发评论以后不能修改，只能删除，所以非常适合缓存架构。而且由于请求量巨大，同时也可以用上负载均衡架构。

【架构分析】

用户量过亿，应该要用多级负载均衡架构，覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。

【架构设计】

1. 负载均衡算法选择

评论微博的时候依赖登录状态，登录状态一般都是保存在分布式缓存中的，因此评论微博的时候，将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

2. 业务服务器数量估算

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

3、由于微博的核心业务是发微博和看微博，评论业务是非核心业务，所以可以考虑把评论拆分成独立的服务来部署，已减少因评论业务故障，导致影响核心业务的运行。

评论微博的多级负载均衡架构

微博高性能计算方案--整体架构设计

三、热点事件时的高可用计算架构。

1、微博热点事件用户行为建模和性能估算

热点事件指某个大 V 或者明星爆料或者官宣，虽然只有一两条微博，但引起大量用户在短时间内访问并且评论，给系统造成很大压力。

【评论微博】

造成热点事件的微博通常只有 1~2 条，但是用户围观后会有很多评论，但是评论数量难以预估，和事件的影响力和影响范围有关。

2、微博热点事件业务特性分析

【评论微博】

热点事件发生后，绝大部分请求都落在了导致热点事件发生的那一条微博上面。而且热点微博的可被查看优先级，是远高于评论的优先级的，评论的内容重要性和影响力是不如原微博的。

3、微博热点事件计算高可用架构分析

核心架构设计思想：既然无法预估，那就做好预防！

【评论微博】

虽然评论的业务优先级没有微博原文重要，但是我们也希望评论内容尽可能不会丢失，但是又要考虑到评论功能的可用性，所以可以考虑使用消息队列+缓存+数据库的组合，用消息队列来对评论功能削峰，也就是写缓冲，然后通过后台任务，根据评论服务器集群的处理能力，把评论内容写入到缓存中，就可以对外提供评论查看功能，最后再慢慢落到数据库当中。

综上所述，设计热点事件时的微博评论高可用架构示意图如下：