架构实战营模块五作业
基于模块 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