写点什么

模块 5- 微博评论高性能高可用计算架构分析

作者:小何
  • 2021 年 12 月 02 日
  • 本文字数:1033 字

    阅读完需:约 3 分钟

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

1.  用户行为建模和性能估算

【用户量】

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

 

【关键行为】

A.      发评论

B.      看评论

 

【发评论】

假设平均每天每人发 5 条评论,则评论每天的发送量约为 10 亿条。

大部分人发表评论集中在早上 8:00~9:00,中午 12:00~13:00,晚上 20:00~22:00,假设这几个时间段发评论总量占比 60%,则这 4 个小时的平均发评论的 TPS 计算如下:

10 亿*60%/(4*3600) ≈40k/s

 

【看评论】

由于绝大部分用户看评论的对象是大 V 的和明显,因此假设平均一天微博评论观看人数有 100 次,则观看评论的次数为:

2.24 亿*100=224 亿

大部分人观看评论和发评论的时间段基本重合,因此看评论的平均 QPS 计算如下:

224 亿*60%/(4*3600)≈1200K/s

 

2.  架构设计

2.1     发评论

【业务特性分析】

发评论是一个典型的写操作,因此不能用缓存,可以用负载均衡。

【架构分析】

用户量过亿,应该要用多级负载均衡架构,覆盖 DNS -> F5 -> Ngnix ->网关的多级负载均衡

【架构设计】

A. 负载均衡算法选择

建议选择轮询或随机算法

B. 业务服务器数量估算

发评论涉及几个关键的处理:内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖存储系统),因此安装一个服务每秒 500 来估算,完成 40k/s 的 TPS,需 80 台服务器,按照 20%的预留,100 台服务器应该差不多。

 

2.2     看评论

【业务特性分析】

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

【架构分析】

A.      用户量过亿,应该要用多级负载均衡架构

B.      请求量达到 224 亿,应该要用多级缓存架构,尤其是 CDN 缓存,是缓存设计的核心

【架构设计】

A.      负载均衡算法选择

建议选择轮询或者随机算法

B.      业务服务器数量估算

假设 CDN 能够承载 90%的用户流量,那么剩下的 10%的看评论的请求进入系统,则请求 QPS 为 1200K/s*10%=120K/s,由于读取评论的处理逻辑比较简单,主要是读缓存系统,因此假设单台业务服务器处理能力是 1000/s,则需要服务器数量为 120 台,按照 20%的预留量,最终机器数量为大概 150 台。

 

3.  方案

3.1 整体架构设计



3.2 评论业务的多级负载均衡整体架构



3.3 评论业务的多级缓存整体架构



4.热点事件计算高可用架构分析

对于热点事件,参与评论的人可能会很多,但发评论的重要性不如看微博甚至转发微博,可以考虑对“发评论”采用令牌桶算法”进行限流,放入消息队列中再慢慢写入数据库。

 


用户头像

小何

关注

还未添加个人签名 2018.03.19 加入

还未添加个人简介

评论

发布
暂无评论
模块5-微博评论高性能高可用计算架构分析