架构实战营模块五作业

/ 架构师训练营 / 没有评论 / 364浏览

架构实战营模块五作业

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

计算性能预估

2020 年 9 月日活 2.24 亿,发微博评论的频率应该介于发微博和看微博之间,我们假设平均一条微博会有 10 条评论,则每天发评论的总次数为 2.5 亿 x10 = 25 亿;

一般用户并不会刷到每条微博都会去看评论,因此看评论的请求量应该是大于发评论而小于看微博,假设一条微博的查看评论请求为 50,则每天看评论的总次数为 2.5 亿 x50 = 125 亿;

大部分人发评论和看评论的时间段分布与发微博时间段基本重合,即高峰时段的四个小时占总量的 60%,则:

发评论的 TPS 峰值计算:25 亿 x 60% / (4x3600) = 100K/s

看评论的 QPS 峰值计算:125 亿 x 60% / (4x3600) = 500K/s

非热点

发评论

发评论相比发微博来说业务上的时效要求低一些,不需要强一致性,因此可以采用客户端 APP 缓存+服务端写缓冲的方式。

用户量过亿,采用多级负载均衡架构,覆盖 DNS->LVS->Nginx->网关的多级负载均衡

业务服务器数量估算:服务端采用消息队列写缓冲的形式,单笔写请求变成异步,耗时约 30ms,单台 32 核服务器 TPS 约为 1000。按前述业务估计 100K/s 需要 100 台服务器,加上 20%冗余,约需要 120 台服务器。

读评论

看评论也是典型的读场景,适合用缓存架构,由于每天请求量达到 125 亿,需要使用多级缓存架构,尤其是 CDN 缓存。

负载均衡策略与发评论相同

业务服务器数量估算:假设 CDN 承载 90%流量,则服务器需处理的读 QPS 为 500K/sx10%=50K/s,读评论的处理逻辑较简单,主要是读缓存系统,因此可机器数量为 50 台,取 20%冗余,最终机器数量为 60 台。

读评论需要考虑因果一致性

热点情况

发评论

热点事件的微博评论相比微博自身时效性要求可以低一些,因此可以考虑对热点事件微博的评论进行限流,最好是采用漏桶算法。原有高性能架构设计中采用了消息队列写缓冲的方式,同时也达到了限流的目的。

alt