架构实战营模块五作业
基于模块 5 第 6 课的微博实战案例,分析“微博评论”这个核心场景的业务特性,然后设计其高性能高可用计算架构,包括但不限于如下内容:
- 1)计算性能预估(不需要考虑存储性能)
- 2)非热点事件时的高性能计算架构,需要考虑是否要拆分独立的服务
- 3)热点事件时的高可用计算架构
计算性能预估
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 台。
读评论需要考虑因果一致性
热点情况
发评论
热点事件的微博评论相比微博自身时效性要求可以低一些,因此可以考虑对热点事件微博的评论进行限流,最好是采用漏桶算法。原有高性能架构设计中采用了消息队列写缓冲的方式,同时也达到了限流的目的。
本文由 biezhi 创作,采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外,均为本站原创或翻译,转载前请务必署名
最后编辑时间为:
2021/06/10 00:39