题图：《盗墓笔记》

鹿晗关晓彤公开恋情，是如何把新浪微博的服务器搞垮的？

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

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

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

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

根据目前已有的信息猜测是数据库被压垮了，先发猜想，稍后写个程序分析当时的点赞评论转发数据验证猜想。微博这样的网站，如果被大流量压垮，不太可能是非必需字段没有容错。之前经历过几次热门事件，我相信在爆发热点新闻的时候，微博会暂时牺牲一点数据准确性来保证关键服务可用。也就是说，光读请求很难压垮微博。根据事故时的微博点赞数、转发数、评论数、评论的回复数、评论的点赞数、转发的评论转发点赞数等的量，微博极可能是由于事发当时需要写入数据库的请求太多（写行为峰值可能达到了几十万甚至更高），以及大部分写都会落到同一条微博上，而且某些写操作还需要触发相应的其他写行为（回复评论需要通知评论者、点赞需要进关注者 feed 等），数据库压力过大扛不过来，最终跪了一会儿。其实如果缓存做好，这时候还是可以满足核心数据读请求的（当然微博缓存做的并不好，我微博个人页数据错误很久了反馈也没用）。如果数据库压力过大时对部分写请求异步化，或者考虑暂时抛弃部分请求换取稳定性，当然这样也各有利弊，不一定是好的。可以抓取当时鹿晗发的微博的所有评论转发回复点赞的时间，看下故障前几秒成功的写行为究竟有多少。不负责任的未经验证的猜测（画图水平有限，省略了部分过程，但是从上下两个过度的箭头数，大致表达了很多请求是读且未压到数据库，将就看吧[手动捂脸.jpg]）：

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

这样看可能不是很直观？

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

点击阅读原文

查看更多回答