鹿晗宣布恋情致微博宕机，大型网站高可用性架构如何应对？

hwyzw

    你可以捕捉当时鹿晗在微博上发表的所有评论的转发、回复和点赞的时间，看看失败前的几秒钟内有多少成功的写作行为。

    不负责任且未经验证的猜测（画图水平有限，省略了部分流程，但从上到下过多的箭头大致表示很多请求是读出来的，并没有压到数据库，所以看一下就可以了【手册】面罩].jpg]）：

    好友：匿名（150+赞）

    放两张微博后台数据的图片：

    也许这不是很直观？

    没有比较就没有伤害！关晓彤的热议趋势一下子上涨了1122.9%，社会！

    浅谈因鹿晗公布恋情导致微博停运的大型网站高可用架构

    中午吃饭的时候，我正在刷微博，发现微博突然挂了。一开始我以为是我家里网速不好，后来我改变了数据流，还是获取不到内容，报错，就知道微博可能挂了。翻看朋友圈，原来鹿晗和关晓彤已经在对方的微博圈子“公布恋情”了。如果之前没有看过《好先生》这部剧，我可能都不认识关晓彤。前几天不是还在炒地CP吗？怎么这么突然？嘿...你的圈子很混乱。

    作为一名程序员，我更感兴趣的是微博如何应对瞬时高并发流量。从很久以前马伊琍的《周一见》文章，到后来的“出轨队”和“吸毒队”争分，再到前段时间的郭敬明事件和薛之谦事件，再到如今的鹿晗公布恋情…………微博似乎每次都卡壳，始终没有任何进展。每次有热点事件，内容发不出去的时候，大家都会抱怨微博的应用平台很糟糕。但微博的后台系统肯定是要进行重构、升级和优化的。我觉得能达到今天的水平就已经很不错了。

    从用户角度（主要是我的角度hhhh）

   

    当遇到热点事件时，微博很有可能在短时间内（大约10到15分钟）根本无法显示内容。一段时间后（约半小时），微博会每隔一段时间（约10秒）刷新一次。有时您会看到 5xx 错误。以5开头的http状态码表示服务器或者网关有问题。例如服务器拒绝连接、网关超时、或者应用程序代码存在bug等，都会导致5xx错误。热点事件发生后1小时内，系统应能恢复正常服务。

    从网站开发和运维人员角度

    以上全是我的废话！

    为什么我觉得微博在高并发、大流量访问方面的表现已经非常好呢？例如：淘宝每年双11期间也要应对高并发场景，但可以提前做好很多准备，比如提前购买带宽资源、增加服务器资源、进行全面关闭等。 - 站点容灾等等等等，很多都是可以预见的。微博呢？热点事件随时可能发生，所以这对微博的运维工程师来说是一个不小的考验。当然，现在的运维平台也非常智能。可实时监控各项指标。如果出现异常，会立即通过短信或电子邮件发送警报。之后，各个岗位的工程师会分配各种资源。

    那平时微博为什么不增加一些服务器资源呢？

    服务器资源、网络带宽资源等既重要又昂贵。由于没有必要一直处理高并发的场景，所以如果平时增加冗余的服务器资源，大量的机器闲置，也是一种很大的浪费。当我们考虑可用的服务时，我们还必须考虑成本。

    本来，我开始写这个博客的时候，是想回顾一下自己所学的关于大型网站高可用架构的知识。但由于高性能、可扩展性、可扩展性和高可用性是密不可分的，所以我感觉写不下去了。想写的东西太多了，又不知道从哪里开始。那么下面我就讲一下高可用架构中经常提到的几个点。

    大型网站的高可用架构

    无论是小型网站还是大型网站，分层都是必要的：粗粒度的层一般是应用层、业务层和数据层。水平分层后，各层可以根据不同的模块进行垂直划分。以微博为例，我认为它的评论模块和点赞模块应该解耦。系统越复杂，水平和垂直的分层分割粒度就越细。很多时候当你使用它的时候，你会认为它只是一个系统。事实上，可能有成百上千个独立部署的系统向外界提供服务。

    簇

    集群是大型网站架构中非常非常重要的概念。由于服务器（无论是应用服务器还是数据服务器）容易出现单点问题，一旦服务器出现故障，就必须进行故障转移。

    应用服务器集群

   

    一般来说，应用服务器必须是无状态的。什么是无状态服务器？在介绍之前，我们先来说一下状态服务器：状态服务器一般会保存请求相关的信息，每次请求都会默认使用之前的请求信息。这很容易导致会话粘性问题：如果状态服务器宕机，那么它保存的请求信息（例如）就会丢失，这可能会导致不可预测的问题。

    相反，无状态服务器不保存请求信息。它处理的客户端信息必须由请求本身携带，或者从其他服务器集群获取。因此，无状态服务器比有状态服务器更加健壮，即使服务器重启甚至服务器崩溃，状态也不会丢失。由此衍生的另一个优点是扩展的方便：只要在额外的服务器上部署同一个应用，并实现反向代理，就可以向外界提供正常的服务。

    管理

    既然应用服务器是无状态的，那么如何管理用户的登录信息（）？以下四种方法较为常见。但由于前三种都有很大的局限性，所以这里只讲基于集群的服务器管理方法。

    负载平衡

    既然提到了集群，就必须要说到负载均衡。但我觉得负载均衡应该归入可扩展性的范畴，这里就不赘述了。我简单说一下常见的负载均衡方法和负载均衡算法。

    负载均衡方式、负载均衡算法、插入点等

    突然想到一个有趣的事情：在微博的架构中，应该使用异步拉取模型，而不是同步推送模型。这是什么意思？举个例子：鹿晗粉丝超过3000万，关晓彤粉丝超过1000万。如果他们发布一条微博，需要推送到4000万粉丝的内容列表（假设这里使用关系数据库），这就是一个简化的同步推送模型。

    那么这样做有什么缺点呢？首先，这会消耗大量的数据库连接资源，更重要的是，它不符合软件设计规范：因为对于两个风扇来说，分别超过3000万和超过1000万条数据是冗余的。如果陈赫和邓超第一次点赞自己的微博，瓶颈就来了：往数据库里插入4000万以上似乎还可以，但现在四个人的粉丝总数加起来了。有数亿。同时向数据库插入这么多数据，感觉不合适吗？

    没关系，我们现在改变内容推送方式：不再使用同步推送，而是使用异步拉取。我们每次用手机浏览微博，如果想看到更新的内容，是不是都要下拉刷新才能获取呢？是的，这就是异步拉取。异步拉取有什么好处？一个明显的好处是可以集中管理热点数据，而不需要进行大量冗余数据插入操作。此外，它消耗的系统资源也更少。那么微博内容从哪里来呢？主流的解决方案是将热点内容放入缓存，每次都检查缓存。这样可以减少I/O操作，避免资源耗尽导致的超时问题。

    PS：当我写下这篇文章时，我开始感到困惑。现在回头再继续写，感觉已经写不下去了。好久没写博客了，很多知识都忘记了。不过今天我在脑子里整理了一下相关的事情，因为我的毕业设计也打算做一些高并发、大流量相关的事情。今天是个追热点话题，复习之前学过的知识的时间~

    其实高可用架构还包括服务升级、服务降级、数据备份、故障转移等，感觉网站的高可用、高性能、高扩展性其实还有很多可写的地方。然而，有些知识如果没有一定的实践经验是无法很好掌握的。那我以后慢慢说吧~