写点什么

模块五作业

用户头像
Mr.He
关注
发布于: 1 小时前

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

【浏览评论】

基数:用户 2.5 亿;

假设:每人每日浏览的微博数量为 100 条,并对其中 80%的微博查看其评论;

时间:用户 60%的浏览量集中在早 8:00-9:00,中午 12:00-13:00,晚 20:00-22:00 的 4 个小时内;

QPS:2.5 亿 *60%*100*80%/(4*3600) = 833K/s

【发布评论】

基数:用户 2.5 亿;

假设:每人每日浏览的微博数量为 100 条,并对其中 30%的微博发布评论;

时间:用户 60%的评论操作集中在早 8:00-9:00,中午 12:00-13:00,晚 20:00-22:00 的 4 个小时内;

TPS:2.5 亿 *60%*100*30%/(4*3600) = 312K/s


2. 微博评论高性能计算架构设计

2.1 整体架构

2.2 业务分析

2.2.1 发布评论

【业务特性】

发布评论是典型的写操作,由于其实时性要求不太高且请求不可丢弃的特点,因此为了降低系统压力,可引入写缓冲。

【架构分析】

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

【架构设计】

  1. 由于需要用户登录,登录状态可记录在分布式缓存中,因此发布评论的时候,可发给任意服务器。故选择轮询或者随机算法。

  2. 服务器数量

发布评论的关键处理步骤与发微博相似:内容审核、数据写入存储、数据写入缓存。由于评论的内容一般是低于微博的内容,因此按照每个服务器每秒处理 1000 请求来估算。由于引入了写缓冲,为保证用户在 5 秒之内可看见自己的评论,故每台服务器可缓冲 5000 请求。加上 20%的预留量,综上,完成 312K/s 的 TPS,需要约 75 台服务器。

2.2.2 浏览评论

【业务特性】

发布评论是典型的读操作,适合缓存架构,由于请求量大,也需要引入负载均衡架构。

【架构分析】

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

  2. 请求量超过 200 亿,应该使用多级缓存架构,尤其是 CDN 缓存。

【架构设计】

  1. 由于需要用户登录,登录状态可记录在分布式缓存中,因此发布评论的时候,可发给任意服务器。故选择轮询或者随机算法。

  2. 服务器数量

假设 CDN 承载了 90%的流量,那么剩下的 10%的读请求进入系统。因此,QPS = 833K/s *10% = 83K/s。假设单机处理能力为每秒 1000,预留量 20%,故需约 100 台服务器。

2.3 微博评论业务架构图

综上所述,微博评论的多级负载均衡架构如下如图。


微博评论多级缓存架构如下图。


3. 微博热点事件高可用架构

3.1 核心思想:无法预估,做好预防

3.2 架构设计分析

3.2.1【发布评论】

热点事件突发,评论量会显著上升。由于在发布评论业务中,引入了写缓冲,系统不会有宕机的危险,但用户体验会下降,因为能刷到自己评论的时间会等更久。

3.2.2【浏览评论】

热点事件会带来缓存热点的问题,可以考虑多副本缓存。


3.3 热点事件评论业务计算高可用架构示意图



发布于: 1 小时前阅读数: 3
用户头像

Mr.He

关注

还未添加个人签名 2018.04.27 加入

还未添加个人简介

评论

发布
暂无评论
模块五作业