架构实战营第五次作业

性能估算

【用户量】

1. 2020.9 月月活 5.11 亿，日活 2.24 亿

【关键行为】

1. 发微博

2. 看微博

3. 评论微博（本次作业分析对象）

【性能估算】

由于评论微博的行为相对较少，假设平均每天每人只发出 1 条评论，则微博评论每天的发送量约为 2.5 亿条。

大部分人评论微博的时间段与发微博的时间段（8:00-9:00、12:00-13:00、20:00-22:00 共 4 小时）基本重合，假设这几个时间段评论微博总量占比为 60%，因此评论微博的平均 TPS 计算如下：

2.5 亿*60%/（4*3600）≈10K/s

非热点事件时评论微博的高性能计算架构

【业务特性分析】

评论微博虽然是写操作，但由于评论后经常容易被淹没，且用户对自己发出的评论并不会实时关注，因此可以使用写缓冲和负载均衡。

【架构分析】

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

【架构设计】

1. 负载均衡算法选择

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

2. 业务服务器数量估算

评论微博涉及几个关键处理：内容审核、数据写入存储、数据写入缓存，因此按照一个服务每秒处理 500 来估算，完成 10K/s 的 TPS，需要 20 台服务器，加上一定的预留量，可以预备 25 台服务器。

【服务拆分分析】

1. 微博评论可以在微博发出很久时间后再评论，即微博评论与发微博业务关联紧密度不高；

2. 发一条微博只需要一个请求，但一条微博的评论可以是几百几十万条，业务请求量有明显差异。

基于以上两点分析，微博评论也需要拆分成独立的服务。

热点事件时评论微博的高可用计算架构

假设有 20%的围观用户会在事件发生 1 小时内评论，微博评论的重要性和影响力不如微博本身，可以考虑对“微博评论”限流，由于评论能给原微博带来一定热度，因此尽量少丢弃请求，考虑用“漏桶算法”。

祝助教老师眉目舒展，顺问冬安~~~