微博评论高性能高可用计算架构设计

关注

发布于: 刚刚

1.性能估算

1.1 发布评论

2020 年 9 月 MAU 约为 5.11 亿，DAU 2.24 亿。（参考《微博 2020 用户发展报告》）。

假设每天每个人发送一条微博，每条微博平均 10 条评论，用户发送微博和评论微博时间段集中在早上 8:00 - 9:00，中午 12:00 - 13:00，晚上 20:00 - 22:00，这三个时段发送评论数占评论总数 60%；则这 4 个小时的平均发微博评论的 TPS 计算如下:2.24 亿 * 10 * 60% / (4 * 3600) ≈ 100 K/s。

1.2 查看评论

假设每条微博平均 100 人查询，每次只加载前 10 条评论，微博查看的时间段集中在早上 8:00 - 9:00，中午 12:00 - 13:00，晚上 20:00 - 22:00，这三个时段发送评论数占评论总数 60%；则这 4 个小时的平均发微博评论的 TPS 计算如下:2.24 亿*100*60% / (4 * 3600) ≈ 1000 K/s。

2. 非热点事件时的高性能计算架构

2.1 发布评论

业务特性分析

发布评论是一个典型的写操作，但是由于不需要及时展现评论，可以采用负载均衡搭配写缓冲。

架构分析

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

架构设计
发微博的时候依赖登录状态，登录状态一般都是保存在分布式缓存中的，因此发微博的时候，将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。
业务服务器数量估算：按每个服务每秒 500 估算，完成 100k/s 的 TPS，需要 200 台服务器，加上预留量，250 台服务器即可。
多级负载均衡架构

2.2 查看评论

业务特性分析

查看评论是一个典型的读场景，由于评论发了后不能修改，因此非常适合用缓存架构，同时由于请求量很大，负载均衡架构也需要。

架构分析
用户量过亿，应该要用多级负载均衡架构；
请求量达到 224 亿，应该要用多级缓存架构，尤其是 CDN 缓存，是缓存设计的核心。
架构设计
游客都可以直接看微博的评论，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。
假设 CDN 能够承载 90%的用户流量，那么剩下 10%的查看评论的请求进入系统，则请求 QPS 为 1000K/s*10%=100K/s，由于查看评论的处理逻辑比较简单，主要是读缓存系统，，业务服务器数量估算：按每个服务每秒 1000 估算，完成 1000k/s 的 TPS，需要 100 台服务器，加上预留量，110 台服务器即可。
多级负载均衡架构