写点什么

架构实战营模块 5 作业

  • 2022 年 6 月 29 日
  • 本文字数:1875 字

    阅读完需:约 6 分钟

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


一、计算性能预估

1.1 用户量

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

1.2 微博评论场景关键行为:

  1. 发评论

  2. 看评论

1.3 行为建模以及性能估算

  1. 发评论:假设平均每天每人发 1 条微博(只考虑文字微博),则微博每天的发送量约为 2.5 亿条。大部分的人发微博集中在早上 8:00~9:00 点,中午 12:00~13:00,晚上 20:00~22:00,假设这几个时间段发微博总量占比为 60%。用户发评论的时间与发微博的时间基本重合,且多数评论都集中在明星和大 V 的微博下。假设平均每条微博有 100 人阅读,有十分之一的人会发表评论,那么每条微博对应 10 条评论。性能估算为:2.5 亿条 * 10 条评论 * 60%/(4 * 3600) ≈ 100K/s


  1. 看评论:看评论的时间与发评论、发微博的时间也基本重合。假设看微博的人中约有 30%会点开评论查看,那么性能估算为:2.5 亿条 * 100 人 * 30% * 60%/(4 * 3600) ≈ 300K/s


二、微博评论高性能计算架构设计

2.1 发评论

2.1.1 发评论架构设计

  1. 从业务特性上来分析,发评论是一个写操作,正常情况下不能用缓存,可以用负载均衡。

  2. 架构分析:用户量过亿,TPS 要求也非常高,应该使用多级负载均衡的架构,覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。

  3. 架构设计:

(1)负载均衡算法设计:

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

(2)业务服务器数量估算:

发表评论涉及几个关键的处理:内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统),但是一般评论内容比微博的内容简单很多,因此按照一个服务每秒处理 1000 来估算,完成 100K/s 的 TPS,需要 100 台服务器,加上一定的预留量,150 台服务器差不多了。

2.1.2 发评论的多级负载均衡架构

2.2 看评论

2.2.1 看评论架构设计

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

  2. 架构分析:

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

(2)请求量达到 75 亿,应该要用多级缓存架构,尤其是 CDN 缓存,是缓存设计的核心。

  1. 架构设计:

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

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

2.2.2 看评论的多级负载均衡架构

2.2.3 看评论的多级缓存架构

微博评论一般不如微博本身重要,同时根据微博热门评论以及精选评论等功能进行分析,排名靠前的微博评论是最容易被看到的,后面的评论可能很少被查看,所以可以区分两类评论,将热门评论存储到 CDN,并定时更新,非热门的评论缓存一份列表到分布式缓存系统,能够节约 CDN 服务器资源的成本。

2.3 整体架构方案

2.3.1 微博评论的多级负载均衡设计

2.3.2 微博评论的多级缓存架构设计

只有看评论会用到缓存架构

三、微博评论高可用架构设计

3.1 微博热点事件用户行为建模、性能估算

热点一般是大 V 或明星的爆料、官宣等事件,或者是一些社会热点事件,一般集中在一两条微博,但引起大量用户在短时间内访问,给系统造成很大压力。

  1. 发评论:

热点事件下的评论数量一般非常多,一条热点微博下起码约几百甚至上千条评论。

  1. 看评论:

热点事件往往会聚集很多吃瓜群众,看微博评论的次数也会明显比平时要高出很多。但很难预估,主要和事件的影响力和影响范围有关。

3.2 业务特性分析

  1. 发评论:评论一般不如发微博重要,而且很多评论发出后就会被刷下去,也不会被马上看到,热点事件发生时可以通过写缓存的方式降低系统的负载压力。

  2. 看评论:热点事件发生后,看评论也主要是看热点微博下的热门评论居多,这部分评论主要缓存在 CDN 中,可以比较快的被访问到。

3.3 高可用架构分析

核心架构设计思想:既然无法预估,那就做好预防!

  1. 发评论:发评论不如发微博重要,且有很多评论不需要即刻被看到,可以考虑使用限流的方式保护系统。同时评论能够增加讨论度,活跃社区气氛,带来更好的传播效果,所以不应该被丢弃,可以考虑漏桶算法,通过一个 kafka 消息队列来实现漏桶。

  2. 看评论:热点事件微博存在缓存热点问题,可以考虑“多副本缓存”,由于原有的缓存架构已经采用了“应用内的缓存”,总体上来看,缓存热点问题其实不一定很突出。

3.4 高可用架构设计示意图


发布于: 刚刚阅读数: 3
用户头像

还未添加个人签名 2018.09.21 加入

还未添加个人简介

评论

发布
暂无评论
架构实战营模块5作业_架构实战营_挖了蘑菇哩斯_InfoQ写作社区