不知不觉，美好的十一假期结束了。假期最后一天，约4000万人同时恋爱，我们迎来了2017年最大的甜蜜暴击！鹿晗在新浪微博高调公布新恋情，并大方@女友关晓彤。消息一出，微博顿时炸开了锅。短短几个小时后，微博转发736137次，评论1913926次，点赞4179888次。短时间内的转发量、评论量、点赞量都冲到了每分钟百万。疯狂上涨的数字摧毁了新浪微博。服务器……终于，新浪工程师担心的事情出现了：北京时间10月8日中午12点32分，新浪微博官方客服号发布公告称当前客户端无法正常刷新、评论等页面不能正常工作。工程师正在调查显示的问题。至于出现这个问题的具体原因，新浪微博在公告中表示“大家都心知肚明”。最后老大搞了一千台服务器搞定了……然而，整个事件中，除了无数少女心破碎之外，最无辜最敬业的小哥莫属微博搜索工程师丁振凯了.婚礼当天，鹿晗公布恋情后，不得不离开宴会处理微博异常，继续婚礼。他心疼弟弟三秒……那一刻，被迫加班的程序员心里有这样一种感觉：连今天的淘宝程序员都失恋了：微博工程师眼中的“鹿晗”：好了，言归正传，新浪服务器是怎么崩溃的？新浪服务器是怎么崩溃的？好友：苏恋（200+点赞，程序（会员话题优秀回答者）我觉得不是数据库挂了，微博这种级别的结构，简单的分布式服务器+DB都抵挡不住，我受不了了压力。刚才王高飞说增加1000台服务器暂时撑不住，数据库弹性伸缩暂时不可能，能扩展的无非就是HTTPServer，各种中间层服务，缓存，或者消息队列，可能微博自动扩容的算法没写好，或者不敢交给算法，比如你发现流量增加了，自动下单是可以接受的增加几十台服务器，如果突然增加1000台服务器出现BUG，微博要花多少钱……估计这种级别的扩容，需要人工运维。确认。而且，爆发于最后一天中午长假期间，不是访问高峰期，服务器也没有做好准备。没有办法警告明星宣布他们的恋情。谁知道他们什么时候会突然心血来潮介绍自己的女朋友……智友（400+赞）根据现有资料推测，数据库爆满了。然后编写程序分析当时的点赞、评论和转发数据，验证猜想。如果像微博这样的网站被大流量压得喘不过气来，非必要字段不容错的可能性不大。经历过几次热点事件，相信在热点新闻爆发的时候，微博会暂时牺牲一点数据的准确性来保证关键服务的可用性。也就是说，阅读量很难压垮微博。根据事故发生时的微博点赞数、转发数、评论数、评论回复数、评论点赞数、转发评论点赞数等，很可能需要在事故发生时写微博.来自数据库的请求过多（写入行为的峰值可能达到几十万甚至更高），大部分写入会落在同一个微博上，有些写入操作需要触发相应的其他写入行为（响应tocomments需要Informcommenters，likes需要输入followersfeed等），数据库压力太大承受不了，最后跪了一会。其实缓存做好了，此时核心数据读取请求还是可以满足的（当然微博缓存没做好，我微博个人页面的数据早就出错了，并且反馈是无用的）。如果数据库压力过大，将一些写请求异步化，或者考虑暂时放弃一些请求以换取稳定性。当然，这各有利弊，不一定是好事。你可以抓取鹿晗在微博上发表的所有评论被转发、回复、点赞的时间，可以看到在失败前的几秒内有多少成功的写作动作。不负责任的未经证实的猜测（画的水平有限，省略了部分流程，但是从上下箭头的数量过多来看，大致表达了很多请求是读取的，没有压入数据库，大家看看：朋友:匿名(150+点赞)求我发两张微博后台数据图：这样看可能不是很直观？没有对比就没有伤害！关晓彤热议上升1122.9%,socialsociety!如何快速提升系统性能？回过头来看，让曾浩说“微博服务器稳定，可以同时应对三对作弊”的流量是多少？具体数据见下图：评分方式：满分100分，由阅读次数、互动次数、社会影响力、欣赏值四项组成，比例分别为30%、30%、20%,和20%.由上可知可以看出鹿晗的微博每一条都达到了顶峰，那么在如此高流量的情况下，作为开发者有没有快速提升系统性能的好方法呢？至于鹿晗公布恋情导致微博下架，说说大型网站的高可用架构。作为一个程序员，我更感兴趣的是微博是如何应对瞬时高并发大流量的。从很久以前文章里的马伊琍“周一见”，到“出轨队”和“毒瘾队”争分夺秒，再到前段时间的郭敬明事件和薛之谦事件，再到今天的鹿晗公布恋情……微博好像每次都挂了，一直没有进展。每次遇到热点事件，都会吐槽微博的应用平台很火。但是，微博的后台系统一定是重构、升级、优化了。我觉得能够达到今天的水平已经很不错了。01从用户角度（主要是我的角度hhhhh）遇到热点事件，微博有很大概率可能短时间（大概10~15）更新不了内容，经过间隔刷新（间隔约10秒）的时间段（约半小时），有可能在某个时候看到5xx错误，以5开头的http状态码表示服务器或网关有问题。比如服务器拒绝连接，网关超时，或者应用代码有bug等等，都会导致5xx错误。在热点事件发生后的1小时内，系统应该能够恢复正常服务。02从网站开发和运维人员的角度看运维：什么鬼？为什么流量这么高？国庆假期还没结束呢！O&M：兄弟们醒醒！添加机器！系统快崩溃了！发展：不催！自杀！领队：扩容后拉出来测试！测试：人在家躺着，锅从天上来！我在胡说八道！为什么我觉得微博在高并发大流量访问方面的表现已经很不错了？举个例子：淘宝一年一度的双11购物节，我们也要处理高并发的场景，但是这个是可以提前做好的。比如提前购买带宽资源，增加服务器资源，实现完整的异地容灾等等，很多都是可以预见的。微博呢？热点事件随时都有可能发生，所以这对微博的运维工程师来说是一个很大的考验。当然，现在的运维平台也非常智能。可实时监控各项指标。如有异常，会立即发送短信或邮件报警。之后，各个岗位的工程师都会去现场调配各种资源。那微博为什么平时不增加一些服务器资源呢？服务器资源、网络带宽资源等既重要又昂贵。由于没有必要一直处理高并发场景，增加冗余的服务器资源，造成大量机器空置，也是一种很大的浪费。当我们考虑可用的服务时，我们还必须考虑成本。接下来说说高可用架构中经常提到的几个点。大型网站的高可用架构无论是小型网站还是大型网站，分层都是必要的：粗粒度层一般是应用层、业务层和数据层。水平分层后，每一层可以根据不同的模块进行垂直划分。以微博为例，我觉得它的评论模块和点赞模块应该解耦。系统越复杂，水平和垂直层次划分的粒度越细。很多时候你在使用的时候以为它是一个系统，但实际上可能有成百上千个独立部署的系统对外提供服务。集群集群是大型网站架构中一个非常非常重要的概念。由于服务器（无论是应用服务器还是数据服务器）都容易出现单点问题，一旦服务器宕机，就必须进行故障转移。应用服务器集群一般来说，应用服务器必须是无状态的。什么是无状态服务器？在介绍之前，先说说状态服务器：状态服务器一般会保存与请求相关的信息，每次请求都会默认使用之前的请求信息。这很容易导致sessionsticking问题：如果一个stateserver宕机了，它保存的请求信息（比如session）就会丢失，这可能会造成不可预知的问题。相比之下，无状态服务器不存储请求信息，其处理的客户端信息必须由请求本身携带或从其他服务器集群获取。因此，无状态服务器比有状态服务器更健壮，即使服务器重启甚至服务器宕机，状态也不会丢失。由此衍生出的另一个好处是扩展方便：只要在新增的服务器上部署相同的应用，并做一个反向代理，就可以对外提供正常的服务。Session管理既然应用服务器是无状态的，那么如何管理用户的登录信息（session）呢？常用的方法有四种：session复制源地址hash（session绑定）用cookie记录session这三种都有很大的局限性。这里只讲基于集群的会话服务器管理。我们这里把服务器的状态分开：分为statelessapplicationserver和statefulsessionserver。当然，这里所说的sessionserver肯定是指sessionserver集群。我们可以使用分布式缓存或关系数据库来存储会话。对于微博，这里必须使用分布式缓存：因为如果使用关系型数据库，数据库连接资源很可能成为瓶颈，I/O操作也很耗时。比较常见的K-V内存数据库是Redis。我觉得用Redis来存储微博内容的点赞数、用户关注度和粉丝数比较合适。既然负载均衡提到了集群，就要说说负载均衡了。但是我觉得负载均衡应该属于可扩展性，这里就不细说了，简单说说常见的负载均衡方式和负载均衡算法。负载均衡方式：HTTP重定向负载均衡。DNS域名解析负载均衡。反向代理负载平衡。IP负载均衡。数据链路层负载均衡。负载均衡算法：roundrobin。随机方法。源地址哈希。加权循环。随机加权。最小连接数。插一句别的，突然想到一个比较有意思的事情：在微博架构中，应该采用异步拉取模型，而不是同步推送模型。你是什??么意思？举个例子：鹿晗粉丝超过3000万，关晓彤粉丝超过1000万。如果他们都发了一条微博，需要推送到这4000万粉丝的内容列表中（假设这里使用关系型数据库），这就是一个简化的同步推送模型。那么这样做有什么缺点呢？首先这会消耗大量的数据库连接资源，更重要的是不符合软件设计规范：因为对于两者的粉丝来说，分别有3000万以上和1000万以上的粉丝。数据是冗余的。如果说陈赫和邓超是第一时间点赞他们的微博，那么这个时候瓶颈就来了：刚才入库还可以接受4000多万粉丝，但是现在加起来粉丝数四是几亿。同时向数据库中插入这么多数据，是不是感觉不太合适？没关系，我们现在改一下内容推送方式：不同步推送，改用异步拉取。每次我们在手机上刷微博，如果想看到更新的内容，是不是要下拉刷新才能获取？没错，这就是异步拉取。异步拉取有什么好处？一个明显的好处是可以集中管理热点数据，而无需进行大量冗余的数据插入操作。此外，对系统资源的消耗也较少。那么微博内容从何而来？主流的解决方案是将热点内容放在缓存中，每次都检查缓存，这样可以减少I/O操作，避免资源耗尽导致的超时问题。事实上，高可用架构还包括服务升级、服务降级、数据备份、故障转移等。关于网站的高可用、高性能、高扩展，还有很多很多东西要写。但是有些知识没有一定的实践经验，是无法很好地掌握的。更深入的技术内容可见：新浪微博如何应对极端高峰下的弹性扩容挑战？
