加入收藏 | 设为首页 | 会员中心 | 我要投稿 湖南网 (https://www.hunanwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 建站 > 正文

鹿晗和关晓彤是如何联手搞垮新浪微博服务器的?

发布时间:2017-10-12 15:43:40 所属栏目:建站 来源:51CTO
导读:副问题#e# 不知不觉,柔美的十一假期已经竣事了。在假期的最后一天,约莫有四万万人同时失恋,我们迎来了 2017 年度最大甜美暴击! 鹿晗在新浪微博高调公布了本身的新恋情,并大方的@了女伴侣关晓彤。动静一出, 微博立马就炸了。 短短几个小时之后,该条微

上面都是我胡说的!

鹿晗和关晓彤是怎样联手搞垮新浪微博处事器的?

为什么我认为微博在高并发大流量会见方面的示意已经很不错了呢?举个例子吧:淘宝每年在双 11 购物节的时辰也要应对高并发的场景,可是这是可以提前做许多筹备的。

好比说提前购置带宽资源、增进处事器资源、举办完整的异地容灾等等,许多都是可猜测的。而微博呢?热门变乱随时都也许产生,以是这对付微博的运维工程师来说是很大的检验。

虽然,此刻的运维平台也长短常的智能了,可以对各项指标举办及时监控,一有非常,马长举办短信可能邮件报警,之后就是各个岗亭的工程师人肉上场调配种种资源了。

那微博在平常为什么不增进一些处事器资源呢?处事器资源、收集带宽资源等既重要,又昂贵。

因为并不是时时候刻都必需应对高并发的场景,因此假如说在平常增进了冗余的处事器资源导致大量呆板空载,也是一种很大的挥霍。我们在思量提供可用处事的同时,也必需思量一下本钱。下面我就针对高可用性架构中常常会提到的几个点来讲讲。

大型网站高可用架构

不管是对付小型网站照旧大型网站来说,分层都是必需的:粗粒度的分层一样平常为应用层、营业层和数据层。横向分层之后,也许还会按照模块的差异对每一层举办纵向的支解。

拿微博举例,我认为它的评述模块和点赞模块应该是解耦的。越是伟大的体系,横向和纵向的分层支解粒度就会越细。许多时辰你用起来觉得它就是一个体系,着实后头也许是由几百上千个独立陈设的体系对外提供处事。

集群

集群在大型网站架构中是一个很是很是重要的观念。因为处事器(不管是应用处事器照旧数据处事器)轻易产生单点题目,一旦一台处事器挂了,就必需举办失效转移。

应用处事器集群

一样平常来说,应用处事器必需是无状态的。什么叫无状态处事器呢?在先容它之前,我们先来说一下状态处事器:状态处事器一样平常会生涯哀求相干的信息,每个哀求会默认地行使早年的哀求信息。

这样就很轻易导致会话粘滞题目:假如一台状态处事器宕机了,那么它生涯的哀求信息 (譬喻 session) 就丢失了,也许会导致不行预知的题目。

那么相对的,无状态处事器就不生涯哀求信息,它处理赏罚的客户信息必需由哀求本身携带,可能是从其他处事器集群获取。

因此无状态处事器相对付状态处事器来说越发地结实,就算是重启处事器乃至是处事器宕机都不会丢失状态。由此引申出来的另一个利益就是利便扩容:只要在增进的处事器上陈设沟通的应用并做好反向署理就能对外提供正常的处事。

Session 打点

既然应用处事器是无状态的,那么用户的登录信息 (session) 怎样打点呢?较量常见的有下面四种方法:

  • session 复制

  • 源地点 hash(session 绑定)

  • 用 cookie 记录 session

  • session 处事器

可是因为前三种都有很大的范围性,这里只聊聊基于集群的 session 处事器打点方法。

我们在这里是将处事器的状态举办疏散:分为无状态的应用处事器和有状态的 session 处事器。

虽然,这里说的 session 处事器必定说的是 session 处事器集群。我们可以借助漫衍式缓存可能是相关型数据库来存储 session。

对付微博来说,这里必定得用漫衍式缓存了:由于用相关型数据库的话,数据库毗连资源轻易成为瓶颈,而且 I/O 操纵也很耗时刻。

较量常见的 K-V 内存数据库有 Redis。我认为微博内容中的赞数、用户的存眷数和粉丝数用 Redis 来存应该算是较量吻合的。

负载平衡

既然提到了集群,必定得说说负载平衡。可是感受负载平衡应该可以归类到可伸缩性内里去,以是这里就不具体讲啦,就简朴说说有哪些常见的负载平衡的方法以及负载平衡算法。

负载平衡方法:

  • HTTP 重定向负载平衡。

  • DNS 域名理会负载平衡。

  • 反向署理负载平衡。

  • IP 负载平衡。

  • 数据链路层负载平衡。

负载平衡算法:

  • 轮询法。

  • 随机法。

  • 源地点哈希。

  • 加权轮询。

  • 加权随机。

  • 最小毗连数。

插播点此外

溘然想到一个较量故意思的对象:在微博的架构中,应该回收的是异步拉模子而不是同步推模子。

什么意思呢?我们举个例子:鹿晗的粉丝有 3000 多万,关晓彤的粉丝有 1000 多万。若是他俩发了条微博的同时必要往这 4000 万粉丝的内容列表中 (假设这里用的是相关型数据库) 推送已往,这就是简化的同步推模子。

那这样有什么弱点呢?起首,这样会耗损大量的数据库毗连资源,更重要的是这样不太切合软件计划类型:由于对付两人的粉丝来说,别离由有 3000 多万和 1000 多万的数据是冗余的。

若是说陈赫、邓超在第一时刻对他俩的微博举办了点赞,此时瓶颈就来了:适才往数据库里插入 4000 多万感受还可以接管,可是此刻四人的粉丝数加起来好几亿了,同时往数据库插这么大都据是不是感受不太吻合?

不要紧,我们此刻换一种内容推送方法:我们此刻不消同步推了,而是用异步拉。我们每次在手机上刷微博的时辰,假如想要看到更新的内容是不是都要下拉革新获取?没错这就是异步拉。

异步拉有什么甜头呢?很明明的一个甜头就是可以将热门数据举办齐集打点,而且不消举办大量的数据插入冗余操纵。其它对体系资源的耗损也较少。

那么微博内容从那边拉呢?主流的办理方案是把热门内容放到缓存中,每次都去查缓存,这样可以镌汰 I/O 操纵而且停止产生因资源枯竭造成的超时题目。

着实高可用性架构还包罗处事进级、处事降级、数据备份、失效转移等等。关于网站高可用、高机能、高拓展方面感受尚有许多许多对象来写。可是有些常识没有必然的实践履历呢,又不能很好的把握。

(编辑:湖南网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读