架构实战营 - 模块 5- 作业
设计微博系统中”微博评论“的高性能高可用计算架构
【作业要求】基于模块 5 第 6 课的微博实战案例,分析“微博评论”这个核心场景的业务特性,然后设计其高性能高可用计算架构,包括但不限于如下内容:
1)计算性能预估(不需要考虑存储性能)
2)非热点事件时的高性能计算架构,需要考虑是否要拆分独立的服务
3)热点事件时的高可用计算架构
总体评估
1,用户量预估:
1. 2020.9 月月活 5.11 亿,日活 2.24 亿(参考《微博 2020 用户发展报告》)
2,用户行为建模:
1,发微博
2,看微博
3,微博评论(本次作业)
借用课上的一些数据
【发微博】
考虑到微博是一个看得多发的少的业务,假设平均每天每人发 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
【微博评论】
【业务特性分析】
微博评论包含两种:
1,看评论(只看)
2,评论内容(不能修改,可以删除自己的评论)
评论内容的行为分两种:
1,一种是评论微博。
2,一种是评论微博下的评论。
分析普通微博内容
分析看微博的评论
【业务特性分析】
看微博是一个典型的读场景,由于评论一般是紧跟在微博下面的,看到微博也就看到了部分评论,且微博评论发了后不能修改,因此非常适合用缓存架构,同时由于请求量很大,负载均衡架构也需要。
【架构分析】
1. 用户量过亿,应该要用多级负载均衡架构
2. 看微博的请求量达到 250 亿,所以看评论的也类似,应该要用多级缓存架构,尤其是 CDN 缓存,是缓存设计的核心。
【架构设计】
1.负载均衡算法选择 游客都可以直接看微博,因此将请求发送给任意服务器都可以,这里选择“轮询”或者“随机”算法。
2. 业务服务器数量估算 假设 CDN 能够承载 90%的用户流量,那么剩下 10%的读微博的请求进入系统,则请求 QPS 为 1000K/s * 10% = 100K/s,由于读取 微博的处理逻辑比较简单,主要是读缓存系统,因此假设单台业务服务器处理能力是 1000/s,则机器数量为 100 台,按照 20%的预留 量,最终机器数量为 120 台。
分析评论微博
约束条件:
1,发微博是评论的基础。
用户行为:
1,大部分用户是不评论的。
2,可能出现评论微博下的评论。
假设一天中,发微博的总量为 2.5 亿条。评论理论上是不限制时间的,但是一般互联网消息具有实时性,传播的很快,那么可能评论微博的时间会有集中的现象,尤其是热点微博,假设发微博的时间集中在早上 8:00~9:00 点,中午 12:00~13:00,晚上 20:00~22:00,这几个时间段发微博总量占比为 60%。那么评论微博也可以这样假定。
另外普通微博的评论数量一般不会很多,假定每条微博的评论数量为 20,评论微博内容的话某一秒集中评论的数量为 10。如果是评论微博的评论的话,某一秒集中评论的数量为 5。
则这 4 个小时的平均评论微博的 TPS 计算如下:
评论微博:
2.5 亿 * 60% / (4 * 3600) *10≈ 100 K/s
评论微博下的评论:
2.5 亿 * 60% / (4 * 3600) *5≈ 50 K/s
所以最后的 TPS 可以用 150 K/s。
【业务特性分析】
评论微博内容是一个写场景,由于写了评论以后不能修改,同时由于请求量很大,负载均衡架构也需要。
【架构分析】
1. 用户量过亿,请求量也很大,应该要用多级负载均衡架构
【架构设计】
1.负载均衡算法选择将请求发送给任意服务器都可以,这里选择“轮询”或者“随机”算法。
2. 业务服务器数量估算 按照一个服务每秒处理 500 来估算,大约使用 150K/500 约等于 300 台,按照 20%的预留,应该是 360 台。
则最终的多级负载均衡架构如下:
分析热点微博内容
如果某一天有热点内容出现,可能会出现某一条内容或多条内容下集中式的爆发性评论。
但是由于热点内容的不确定性,很难预估。
我们可以采取一些策略来预防:
1,排队
2,限流
3,降级
4,熔断
评论