架构实战营模块 5 作业
微博评论高性能高可用计算架构设计
一、计算性能预估
1.1 用户量
2020.9 月月活 5.11 亿,日活 2.24 亿(参考《微博 2020 用户发展报告》)。
1.2 微博评论场景关键行为:
发评论
看评论
1.3 行为建模以及性能估算
发评论:假设平均每天每人发 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
看评论:看评论的时间与发评论、发微博的时间也基本重合。假设看微博的人中约有 30%会点开评论查看,那么性能估算为:2.5 亿条 * 100 人 * 30% * 60%/(4 * 3600) ≈ 300K/s
二、微博评论高性能计算架构设计
2.1 发评论
2.1.1 发评论架构设计
从业务特性上来分析,发评论是一个写操作,正常情况下不能用缓存,可以用负载均衡。
架构分析:用户量过亿,TPS 要求也非常高,应该使用多级负载均衡的架构,覆盖 DNS -> F5 -> Nginx -> 网关的多级负载均衡。
架构设计:
(1)负载均衡算法设计:
发评论的时候依赖登录状态,登录状态一般都是保存在分布式缓存中的,因此发评论的时候,将请求发送给任意服务器都可以,这里选择“轮询”或者“随机”算法。
(2)业务服务器数量估算:
发表评论涉及几个关键的处理:内容审核(依赖审核系统)、数据写入存储(依赖存储系统)、数据写入缓存(依赖缓存系统),但是一般评论内容比微博的内容简单很多,因此按照一个服务每秒处理 1000 来估算,完成 100K/s 的 TPS,需要 100 台服务器,加上一定的预留量,150 台服务器差不多了。
2.1.2 发评论的多级负载均衡架构
2.2 看评论
2.2.1 看评论架构设计
业务特性分析,看评论是一个典型的读场景,由于评论发了之后不能修改,因此非常适合用缓存架构,同时由于请求量很大,负载均衡架构也需要。
架构分析:
(1)用户量过亿,应该要用多级负载均衡架构;
(2)请求量达到 75 亿,应该要用多级缓存架构,尤其是 CDN 缓存,是缓存设计的核心。
架构设计:
(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 或明星的爆料、官宣等事件,或者是一些社会热点事件,一般集中在一两条微博,但引起大量用户在短时间内访问,给系统造成很大压力。
发评论:
热点事件下的评论数量一般非常多,一条热点微博下起码约几百甚至上千条评论。
看评论:
热点事件往往会聚集很多吃瓜群众,看微博评论的次数也会明显比平时要高出很多。但很难预估,主要和事件的影响力和影响范围有关。
3.2 业务特性分析
发评论:评论一般不如发微博重要,而且很多评论发出后就会被刷下去,也不会被马上看到,热点事件发生时可以通过写缓存的方式降低系统的负载压力。
看评论:热点事件发生后,看评论也主要是看热点微博下的热门评论居多,这部分评论主要缓存在 CDN 中,可以比较快的被访问到。
3.3 高可用架构分析
核心架构设计思想:既然无法预估,那就做好预防!
发评论:发评论不如发微博重要,且有很多评论不需要即刻被看到,可以考虑使用限流的方式保护系统。同时评论能够增加讨论度,活跃社区气氛,带来更好的传播效果,所以不应该被丢弃,可以考虑漏桶算法,通过一个 kafka 消息队列来实现漏桶。
看评论:热点事件微博存在缓存热点问题,可以考虑“多副本缓存”,由于原有的缓存架构已经采用了“应用内的缓存”,总体上来看,缓存热点问题其实不一定很突出。
3.4 高可用架构设计示意图
版权声明: 本文为 InfoQ 作者【挖了蘑菇哩斯】的原创文章。
原文链接:【http://xie.infoq.cn/article/7dfcbe255a83fd48fd266409f】。文章转载请联系作者。
评论