设计微博系统中”微博评论“的高性能高可用计算架构

计算性能预估

用户量预估

1. 2020.9 月月活 5.11 亿，日活 2.24 亿(参考《微博 2020 用户发展报告》)。

关键行为预估

写评论

读评论

性能估算

写评论：平均每条微博被评论的可能性 1/10，且一般在发布后不久被评论的可能性最大，因此同发微博 TPS：2.5 亿 * 60% / (4 * 3600) /10≈ 1 K/s，热点

读评论：一般评论只有微博作者等少数人看，除个别热点事件评论，其余没有什么人关注，因此预计为写评论的 1/10 即 100/s

热点事件评论：同转发微博场景，短时间内大量用户写评论，且可能只有部分置顶评论被读可能性大

业务特性分析

相比于微博本身评论被关注可能性极低，因此更像是一个写场景，不太适合用缓存；

热点事件，其评论可以设置缓存提升性能

1. 很少人去看微博的评论，本身相对于微博是异步

架构分析

1. 用户量本身应该会过亿，用多级负载均衡

2. 评论量相比微博小的多，更像是微信红包，因此不用进行任务分解，但可以跟微博一样搞双机房

3. 可以对热点事件的评论增加缓存，但是因为其相比于微博本身非核心，因此可以适当降级，优先考虑可用性与成本，可以舍弃多级架构中成本较高的部分

架构设计

多级负载均衡架构-nginx + 网关集群 + 服务集群 3 级

负载均衡算法选择：服务器性能差不多情况下，选择轮询或随机即可（简单合适原则）

按服务器单台每秒 500，完成 1k（写）+100（读）基本保证 2 倍即可，4 台服务器。

无需多级缓存

对于热点事件的评论：

写评论：允许在高峰期进行异步降级，保证微博本身业务可用，因此可以通过本地缓冲队列同步到服务器；同时在本地缓存个人评论提升写评论体验；同时可以增加漏洞桶限流

读评论：热门评论随微博用多副本缓存到用户本地以及 CDN，可以不用多级；