作业

「作业要求」

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

1. 计算性能预估(不需要考虑存储性能);

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

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

「提示」

1. 分析方法对照“看微博”和“发微博”的案例。

非热点事件

计算性能预估与架构设计

按照课程 6 里设定的背景：

【发微博】

考虑到微博是一个看得多发的少的业务，假设平均每天每人发 1 条微博(只考虑文字微博)，则微博每天的发送量约为 2.5 亿条。

大部分的人发微博集中在早上 8:00~9:00 点，中午 12:00~13:00，晚上 20:00~22:00，假设这几个时间段发微博总量占比为 60%，则这 4 个小时的平均发微博的 TPS 计算如下:2.5 亿 * 60% / (4 * 3600) ≈ 10 K/s。

【看微博】

由于绝大部分微博用户看微博的对象是大 V 和明星，因此我们假设平均一条微博观看人数有 100 次，则观看微博的次数为:

2.5 亿 * 100 = 250 亿。

大部分人看微博的时间段和发微博的时间段基本重合，因此看微博的平均 QPS 计算如下:

250 亿 * 60% / (4*3600) = 1000K/s。

发评论

按照每条微博下平均有 10 条评论计算，则发评论的 TPS 为：10 k/s*10=100k/s，按照每台能抗住 1000/sTPS,则需要 100 台机器，加上一点的预留量，可以使用 120 台机器；

架构设计

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

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

多级负载架构

看评论

大部分的人看评论的 QPS 与看微博类似：1000k/s，按此估算也是需要 120 台机器。

架构设计

• 用户量过亿，应该要用多级负载均衡架构;

• 请求量达到 250 亿，应该要用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。

• 负载均衡算法选择游客都可以直接看评论，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

多级负载架构

看评论多级缓存

整体架构设计

• 任务分配：多机房；

• 任务分解：需要将发评论和看评论做服务拆分，以达到互不影响的目的；

热点事件

因评论的热点事件的特性跟发和看微博是一样的，故处理办法可参考发微博和看微博。可采用“漏桶算法”来处理海量的发评论请求。