小结一下“鹿关门”

        本来想好好分析一下本次事件的，但今天一大早就发现已经有位兄弟放出来一篇大作了，写得非常好。所以呢，就不展开写了，简单谈谈我个人的几点观点：

1）无论怎么设计，系统一定要能容易地水平扩展。也就是说，整个数据流中，所有的环节都要能够水平扩展。这样，当你的系统有性能问题时，才能做到快速和高效的扩容。

当然，我列出这一点，并不是说微博系统的水平扩展做得不好，反而是觉得他们做得已经是国内领先水平了。之所以出现昨天的状况，一方面是技术上是非常自信的，二是微博从运营角度是希望能将本次微博表白效果进一步放大，所以在一开始，并没有多少技术上的干预，如果在更早的时间里就进行降级或者大V级别隔离操作，也就是转发鹿关的本条微博时需要前后输一个数字验证码。

1）技术不是一朝一夕能搞定的，没有长期的积累，关键时刻只会掉链子。昨天的事件，换一家互联网公司彻底歇菜了，给你1000台机器也救不活。CAP背后任何一点进步，都需要结合自身业务，不断的做技术研究，团队演练的。别幻想看几篇文章，照着做一遍就算完事了。微博的团队很幸运，有不断实战的机会，越战越强。

2）分布式是能让现有系统性能有质的提升的最好方法。最好的例子可以参见12306和阿里云合作构建的两地三中心的架构。双数据中心并行作业，不但可以分担高负载运行，而且可以相互备份， 保证操作不间断。动态调整网络带宽和“虚机“资源，并解决网络传输瓶颈问题。

3）“大V爆料”这种业务场景是相当变态的，两个1000多万粉丝的大V，让几百万甚至上千万人在某个时刻同时进行转发和评论是变态中的变态。业务形态的变态决定了，要伺候好这么多用户，并且不被骂是很难的。

4）为了应付大V一句表白搞那么大的系统，而其它时间几乎都在闲着，想想还是有些可惜了，这也就是国内几家大厂干得出来，因为是需要很多很多基础建设投入和人力成本的。

扫描二维码或手动搜索微信公众号【架构栈】： ForestNotes

欢迎转载，带上以下二维码即可