鹿晗关晓彤公开恋情，是如何把微博服务器搞炸的？
来源 | 知乎日报
我觉得不像数据库挂了，微博这种级别的架构根本不是简单的分布式 server+DB 就能抗住的，别说鹿晗关晓彤搞个大新闻，就算平时运营的压力也扛不住。
刚才王高飞说加一千台服务器暂时顶住了，数据库是不可能临时这么弹性伸缩的，能伸缩的无非就是 HTTP Server、各中间层服务、缓存或消息队列。
大概是微博自动扩容的算法没写好，或者没敢全交给算法来做。比如你发现流量升高了，自动下单加几十台服务器能接受，突然加一千台要是程序出 bug 的话微博得白支出多少钱啊…… 多半是这个量级的扩容需要运维手工来确认。
而且是在长假最后一天的中午爆发的，不是访问高峰期，服务器也准备不足。明星公布恋情这件事又没法预警，谁知道他们啥时候心血来潮忽然介绍女朋友啊……
知友热评
因为没有了卓伟打提前量，太突然
——肖小邦
根据目前已有的信息猜测是数据库被压垮了，先发猜想，稍后写个程序分析当时的点赞评论转发数据验证猜想。微博这样的网站，如果被大流量压垮，不太可能是非必需字段没有容错。之前经历过几次热门事件，我相信在爆发热点新闻的时候，微博会暂时牺牲一点数据准确性来保证关键服务可用。也就是说，光读请求很难压垮微博。根据事故时的微博点赞数、转发数、评论数、评论的回复数、评论的点赞数、转发的评论转发点赞数等的量，微博极可能是由于事发当时需要写入数据库的请求太多（写行为峰值可能达到了几十万甚至更高），以及大部分写都会落到同一条微博上，而且某些写操作还需要触发相应的其他写行为（回复评论需要通知评论者、点赞需要进关注者 feed 等），数据库压力过大扛不过来，最终跪了一会儿。其实如果缓存做好，这时候还是可以满足核心数据读请求的（当然微博缓存做的并不好，我微博个人页数据错误很久了反馈也没用）。如果数据库压力过大时对部分写请求异步化，或者考虑暂时抛弃部分请求换取稳定性，当然这样也各有利弊，不一定是好的。可以抓取当时鹿晗发的微博的所有评论转发回复点赞的时间，看下故障前几秒成功的写行为究竟有多少。不负责任的未经验证的猜测（画图水平有限，省略了部分过程，但是从上下两个过度的箭头数，大致表达了很多请求是读且未压到数据库，将就看吧 [手动捂脸. jpg]）：
让我放两张来自微博后台数据的图片：
这样看可能不是很直观？
没有对比就没有伤害啊！关晓彤热议趋势硬生生涨了 1122.9%，社会社会！
转载自：知乎日报
金秋十月与你饮酒论道
SACC2017
作为国内最受欢迎的架构师盛会，2017 第九届中国系统架构师大会 (SACC) 将于将于 2017 年 10 月 19-21 日在北京新云南皇冠假日酒店震撼来袭。
大会以 “云智未来” 为主题，云集国内外顶级专家，围绕云计算、人工智能、大数据、移动互联网、产业应用等热点领域展开技术探讨与交流。本届大会共设置 2 大主会场，18 个技术专场；邀请来自互联网、金融、制造业、电商等多个领域，100 余位技术专家及行业领袖来分享他们的经验；并将吸引 4000 + 人次的系统运维、架构师及 IT 决策人士参会，为他们提供最具价值的交流平台。
即日起，填写 SACC2017 会前调查问卷，即有机会赢取价值 2600 元的大会门票 1 张！仅限 10 张！
点击“阅读原文”，快来试试手气~ 
原文作者：；如有侵权，请联系管理员删除。
