点击上方关注我们

新浪微博是近十年来的国内主流社交平台，众多明星商户都选择在上面和观众买家等进行密切交流，发布最新消息。对于流量来说，用微博发布消息已经变成了最简洁的人气反应，话题度，转发量，评论数都是兵家常争之地。但微博面对众多的流量新闻，却坚定的保持着【每年一崩】的惯例，让大家立刻就能判断，必定是哪个明星又搞了个大新闻。

2018 冯绍峰 赵丽颖结婚

微博实时崩溃，客服紧急上线说各位程序员正在处理，截止发稿日，赵丽颖的官宣微博留言数已经超过了170万。话题的热度也以亿为单位计数，直接把微博客户端挤崩了3.5个小时，才完全恢复。

新浪官方CEO也澄清了之前说能够同时承受5个流量明星出轨的新闻，不过大家对于新浪“连一个流量结婚都承受不住”的状况，也是一片玩笑。

2017 鹿晗 关晓彤 谈恋爱

一度让新浪微博和粉丝群体一起崩溃，而且崩溃的五花八门，层出不穷，不但能崩一次，还能崩两次。一小时评论过60万，截止发稿日已经超过了290万。

流量谈恋爱，程序员倒霉。在婚礼上也要被抓去维稳。

不但程序员要跪，连负责核心接口功能的底层支持的负责人也要跪。

2016 马蓉出轨

2016年让所有流量都黯然失色的一大热点来自王宝强及其前妻马蓉和其经纪人，虽然是非曲直交给了法律判断，但马蓉一举抗下了全年热搜担当，这个457万的评论数，足以让所有流量都汗颜。

面对出轨的明星，微博即使做好了完全的准备，也不一定能做到万无一失。毕竟在马蓉之前，上一个出轨流量陈赫的道歉文评论也才299万

  那些崩溃的其他网站  

2018 GitHub

昨天早上北京7点开始，GitHub开始出现大面的瘫痪，一直持续到了晚上的9点整。

2014 鸟叔 Gangnam Style 导致油管崩溃

更早在2014年，一首魔性歌曲《gangnam style》也曾经让世界最大的视频网站油管崩溃过，对此油管还非常诚恳的道歉说：我们真的没想到会有视频有这么高的访问量，对此我们升级了我们的算法，下一个要让我们崩溃的视频需要达到9,223,372,036,854,775,808次。程序员的言下之意是，你来试试看。

  新浪服务器到底是怎么崩的  

这些崩的层出不穷的网站也让各个程序员们摩拳擦掌，一番探究。各大讨论网站都发出了不同的声音。

知友：苏莉安

我觉得不像数据库挂了，微博这种级别的架构根本不是简单的分布式 server+DB 就能抗住的，别说鹿晗关晓彤搞个大新闻，就算平时运营的压力也扛不住。

刚才王高飞说加一千台服务器暂时顶住了，数据库是不可能临时这么弹性伸缩的，能伸缩的无非就是 HTTP Server、各中间层服务、缓存或消息队列。

大概是微博自动扩容的算法没写好，或者没敢全交给算法来做。比如你发现流量升高了，自动下单加几十台服务器能接受，突然加一千台要是程序出 Bug 的话微博得白支出多少钱啊……多半是这个量级的扩容需要运维手工来确认。

而且是在长假最后一天的中午爆发的，不是访问高峰期，服务器也准备不足。明星公布恋情这件事又没法预警，谁知道他们啥时候心血来潮忽然介绍女朋友啊……

知友

根据目前已有的信息猜测是数据库被压垮了，先发猜想，稍后写个程序分析当时的点赞评论转发数据验证猜想。微博这样的网站，如果被大流量压垮，不太可能是非必需字段没有容错。

之前经历过几次热门事件，我相信在爆发热点新闻的时候，微博会暂时牺牲一点数据准确性来保证关键服务可用，也就是说，光读请求很难压垮微博。

根据事故时的微博点赞数、转发数、评论数、评论的回复数、评论的点赞数、转发的评论转发点赞数等的量，微博极可能是由于事发当时需要写入数据库的请求太多(写行为峰值可能达到了几十万甚至更高)，以及大部分写都会落到同一条微博上，而且某些写操作还需要触发相应的其他写行为(回复评论需要通知评论者、点赞需要进关注者 feed 等)，数据库压力过大扛不过来，最终跪了一会儿。

其实如果缓存做好，这时候还是可以满足核心数据读请求的(当然微博缓存做的并不好，我微博个人页数据错误很久了反馈也没用)。

如果数据库压力过大时，对部分写请求异步化，或者考虑暂时抛弃部分请求换取稳定性，当然这样也各有利弊，不一定是好的。

可以抓取当时鹿晗发的微博的所有评论转发回复点赞的时间，看下故障前几秒成功的写行为究竟有多少。

不负责任的未经验证的猜测(画图水平有限，省略了部分过程，但是从上下两个过度的箭头数，大致表达了很多请求是读且未压到数据库，将就看吧：

知友：佚名

让我放两张来自微博后台数据的图片：

这样看可能不是很直观?

没有对比就没有伤害啊!关晓彤热议趋势硬生生涨了 1122.9%，社会社会!

51CTO技术栈 的论坛讨论也非常热烈，大家都给出了很多不同的看法，比如说自己即使不是新浪的内容人员，也会觉得微博的处理速度还算不错

01从用户的角度来看

遇到热点事件的时候微博大概率在短时间内(大约 10~15)可能会完全刷不出内容，过了一段时间之后(大约半小时)进行间隔刷新(间隔 10 秒左右)，有可能某些时候会看到 5xx 的 error，5 开头的 http 状态码代表服务器或者是网关存在问题。

比如说服务器拒绝连接、网关超时或者是应用代码存在 Bug 等都会导致 5xx 的错误。在热点事件发生 1 小时内，系统应该可以恢复正常的服务。

虽然大家都拿微博和淘宝等等网站做对比，但微博内容本身的不确定性和不可控性都让新浪微博平台本身带来很大压力，他们的反应已经非常及时。也分析了一下可用的架构类型。

由于并不是每时每刻都必须应对高并发的场景，因此如果说在平时增加了冗余的服务器资源导致大量机器空载，也是一种很大的浪费。我们在考虑提供可用服务的同时，也必须考虑一下成本。下面我就针对高可用性架构中经常会提到的几个点来讲讲。

大型网站高可用架构

不管是对于小型网站还是大型网站来说，分层都是必须的：粗粒度的分层一般为应用层、业务层和数据层。横向分层之后，可能还会根据模块的不同对每一层进行纵向的分割。

拿微博举例，我觉得它的评论模块和点赞模块应该是解耦的。越是复杂的系统，横向和纵向的分层分割粒度就会越细。很多时候你用起来以为它就是一个系统，其实后面可能是由几百上千个独立部署的系统对外提供服务。

集群

集群在大型网站架构中是一个非常非常重要的概念。由于服务器(不管是应用服务器还是数据服务器)容易发生单点问题，一旦一台服务器挂了，就必须进行失效转移。

应用服务器集群

一般来说，应用服务器必须是无状态的。什么叫无状态服务器呢?在介绍它之前，我们先来说一下状态服务器：状态服务器一般会保存请求相关的信息，每个请求会默认地使用以前的请求信息。

这样就很容易导致会话粘滞问题：如果一台状态服务器宕机了，那么它保存的请求信息 (例如 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 操作并且避免发生因资源枯竭造成的超时问题。

其实高可用性架构还包括服务升级、服务降级、数据备份、失效转移等等。关于网站高可用、高性能、高拓展方面感觉还有很多很多东西来写。但是有些知识没有一定的实践经验呢，又不能很好的掌握。更多深度技术内容可见：新浪微博如何应对极端峰值下的弹性扩容挑战?

不过也有的程序员非常耿直，觉得理由挺简单的

但真要说起来，服务器瘫痪这事儿和两家的技术水平还真扯不上多大关系，毕竟只是一个超载问题。想当年连天涯社区都能承载上亿的访问量，发展了这么多年的微博居然不行？

所以总结起来，微博之所以一直解决不了这个问题，主要的原因还是舍不得花钱。

欢迎在下方投票，投出你觉得网站因为流量瘫痪，是谁的锅呢？

报告原文链接： http://server.51cto.com/sOS-553620.htm 

微信公众号改版，为了不错过最新消息

苹果鸡小伙伴们欢迎加星标

安卓鸡小伙伴们可以设置置顶哦~

爱你们