写点什么

【架构实战营】第 5 模块作业

用户头像
swordman
关注
发布于: 2021 年 06 月 06 日
【架构实战营】第 5 模块作业

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

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

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

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


1.用户行为建模和性能估算

【发微博评论】

微博评论:看微博的人,只有少数人会发评论,一般都只是看看。根据发微博每天平均 2.5 亿条,假设观看人数 100 人中,平均只有 10%的人发表了评论,那么每条微博就有 10 条评论,则微博评论每天的发送量约为 25 亿条。

大部分人发送微博评论的时间段和发微博的时间段基本重合,因此在这 4 个小时内,发送微博评论的平均 TPS 计算如下:

25 亿 * 60% / (4 * 3600) ≈ 100 K/s

这个 TPS 的数量,是发微博的 10 倍。


【看微博评论】

看微博时,一般都会看一下评论,因此看微博评论的 QPS 和看微博的 QPS 相同:

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


2.非热点事件时的高性能计算架构

发微博评论是一个写操作,但数据实时性要求不高(自己可以先看到,其他人可以延时一段时间再看到)。因为发微博评论的 TPS 较高,因此可以用负载均衡 + 缓存来实现,负载均衡用来将评论写请求分配到不同的应用服务器,缓存用来延缓大量写操作请求对应用服务器造成的冲击,减少处理服务器数量。


【架构分析】

1. 用户量过亿,应该要用多级负载均衡架构

2. 请求量达到 100K/s,应该要用多级缓存架构,评论不是所有人都会看,存在 CDN 上不合适。使用 App 缓存 + Web 容器缓存,减少到达服务器请求的的 TPS。


【架构设计】

1. 负载均衡算法选择

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


2. 业务服务器数量估算

发微博评论涉及几个关键的处理:内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统)。

不考虑使用缓存,按照一个服务每秒处理 500 来估算,完成 100K/s 的 TPS,需要 200 台服务器,加上一定的预留量,250 台服务器差不多了;

如果使用写缓存,每个评论请求处理被缓存,TPS 可能下降 1/4,达到 75K/s,这样就只需要 150 台,加上预留量,大概需要 200 台服务器。


多级负载均衡整体架构 —— 同发微博的负载均衡架构。


多级缓存整体架构:


【服务拆分】

发微博评论的 TPS 比较高,尤其是遇到热点事件,因此发微博评论的服务需要拆分出来。

看微博评论的服务可以和看微博放在一起,因为只是多增加了一个微博对应评论的查询操作。


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

【架构设计分析】

1. 发微博评论

对“发微博评论”限流,尽量少丢弃请求,考虑用写缓冲架构,在接入服务器中使用写缓冲。



用户头像

swordman

关注

还未添加个人签名 2017.10.17 加入

还未添加个人简介

评论

发布
暂无评论
【架构实战营】第 5 模块作业