写点什么

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

发布于: 刚刚

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 台服务器即可。

  • 多级负载均衡架构

  • 查看评论的多级缓存架构

2.3 高性能计算方案

  • 整体架构设计

  • 多级负载均衡架构

  • 多级缓存整体架构

3. 热点事件时的高可用计算架构

3.1 业务特效分析

  • 发布评论:同非热点事件的发布评论。

  • 查看评论:热点事件发生后,绝大部分请求都会落在导致热点事件发生的那一条微博上的评论。

3.2 架构分析

  • 核心:预防

  • 发布评论:采用写缓存和限流

  • 查看评论:查看多副本缓存。

3.3 高可用架构示意图


用户头像

还未添加个人签名 2018.05.21 加入

还未添加个人简介

评论

发布
暂无评论
微博评论高性能高可用计算架构设计