架构训练营模块五

1.用户行为性能估算

发微博:考虑到微博是一个看得多发的少的业务，假设平均每天每人发 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。

结合模块五第六课的课程内容,在此基础上尝试进行微博评论的计算性能预估

微博评论:与看微博相同,微博评论绝大部分对象也是大 V 和明星,相对于看微博,实际评论微博的人相对少一些,假设平均一条微博的评论有 20 条,则微博评论的次数为 2.5 亿 * 20 = 50 亿。评论微博与看微博的时间基本重合,因此评论微博的 TPS 计算如下: 50 亿 * 60% / (4*3600) = 200K/s。

2.业务特性分析

微博评论是一个典型的写操作，因此不能用缓存，可以用负载均衡，并且存在针对某一微博短时大量写请求的情况，但微博评论一般都是评论完没有自己二次查看的请求，一般由其他看评论的人查看，因此可以通过写入缓冲慢慢处理，可以忍受短暂的延迟处理。

3.架构分析

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

4.架构设计

4.1 负载均衡算法选择

评论微博的时候选择使用写入缓冲的方式对请求削峰填谷将评论请求缓冲到消息队列里处理，消息队列的消费者服务也会讲评论内容按照微博原文将评论更新到缓存中，所以负载均衡算法选择"轮训"或"随机"。

4.2 业务服务器数量估算

微博评论涉及几个关键的处理：数据写入消息队列、内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），消息队列选择 rocketMq 的情况下,选择四主四从的架构,后续存储系统按照一个服务每秒处理 1000 来估算，可以延迟 20 秒处理完毕，完成 200K/s 的 TPS，需要 20 台服务器，加上一定的预留量与消息队列服务器，30 台服务器差不多了。

4.3 服务拆分选择

微博评论与发微博看微博时间上是同步的,因此选择将服务独立拆分出来。

5.看微博整体负载架构

微博评论总体上与看微博一直,在后续的服务层中加入消息队列来缓冲评论写入请求并通过微博评论服务写入数据存储与缓存。

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

在发生热点事件如明星离婚时,会有大量的读请求进入,此时通过轮训程序处理时,虽然请求已经均匀的分布到每一天机器上,但仍然可能造成部分服务器由于无法处理爆发式的请求而造成处理性能下降直至系统崩溃,所以应对热点事件时,应该首先考虑热点事件主要内容发布到 CDN 中缓存以用来满足大部分用户看微博的请求,对于微博评论,一是定时刷新部分处理后的微博评论到 CDN 中,二是设置熔断与降级策略,在请求达到设定降级阈值时将缓存中已完成刷新的内容返回,当请求量超过设定的熔断阈值时,执行熔断策略,拒绝用户请求将用户请求重定向到 CDN 路径上. 同时在运维层面,可以临时增加服务器以应对爆发增长的请求。