写点什么

微博评论架构设计

发布于: 刚刚

1.1 用户量预估

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

1.2 用户行为建模

  1. 发表微博评论

微博每天发送量约为 2.5 亿,看微博关注的重点都集中在大 V 和明星,假设平均每条有 100 人观看,再假设 10%的用户会对微博评论发表自己的看法,则评论发送量约为 25 亿条。

  1. 查看微博评论

大部分查看微博的用户都喜欢看评论区,假设 90%的人都爱看评论,则评论查看次数为 2.25 x 100 x 0.9 = 225 亿。

  1. 使用习惯

大部分人集中在早上 8 点~9 点,中午 12 点~13 点,晚上 20 点~22 点,假设这 4 个小时流量占比为 60%。

1.3 性能需求计算

  1. 发表微博评论

25 亿 x 60% / (4 x 3600) = 100K/s

  1. 看微博评论

225 亿 x 60% / (4 x 3600) = 950K/s

2. 业务分析

2.1 发表评论

业务特性分析

微博发布评论,不用实时展现,可以出现延迟,因此可以使用消息队列进行削峰操作。

架构分析

用于微博用户量巨大,因此采用多级负载均衡架构,CDN->F5->nginx->网关

架构设计

  1. 负载均衡算法选择。发评论的时候依赖登录状态,登录状态一般都是保存在分布式缓存中的,因此发评论的时候,将请求发送给任意服务器都可以,这里选择“轮询”或者“随机”算法。

  2. 业务服务器数量估算。发评论涉及几个关键的处理:内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统),因此按照一个服务每秒处理 500 来估算,完成 50K/s 的 TPS,需要 100 台服务器,加上一定的预留量,120 台服务器差不多了。


2.2 看评论

业务特性分析

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

架构分析

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

  2. 请求量达到 125 亿,应该要用多级缓存架构,尤其是 CDN 缓存。

架构设计

  1. 负载均衡算法选择。游客(非登陆用户)都可以直接看评论,因此将请求发送给任意服务器都可以,这里选择“轮询”或者“随机”算法。

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

  3. 与微博类似,并非所有的评论需要上 CDN。但是热门微博的热门评论页一定要上 CDN,并进行定期(如每半小时)更新。如此可以在保证 CDN 的命中率的同时提供相对较实时的用户体验。


微博评论的多级缓存架构



用户头像

还未添加个人签名 2020.12.08 加入

还未添加个人简介

评论

发布
暂无评论
微博评论架构设计