蘑菇街 11.11：流量超过预期，系统曾被冲垮

以导购起家的女性时尚电商蘑菇街目前已经上线自己的电商交易平台，全面转型为垂直电商。据官方数据显示，蘑菇街双十一交易额已突破一亿元，并提前完成了此前的预定目标。蘑菇街今年第一次自己做交易，虽说总的交易量只有天猫几分钟的量，但峰值时期系统的压力同样不小，并且他们也才刚刚开始。那蘑菇街是怎么准备这场战争的？相应做了哪些预案？带着这些问题，InfoQ 专门采访了蘑菇街的 CTO 岳旭强。岳旭强于 2004 年加入淘宝，参与并主导核心业务系统搭建，2007 年开始负责淘宝服务化体系建设。2010 年底离职创业，组建并带领蘑菇街技术团队，支撑蘑菇街的高速发展和业务转型，有丰富的架构设计和技术团队管理经验。

InfoQ：请介绍下双十一当天蘑菇街的交易情况，当天有多少的成交额？

岳旭强：截至 11 月 11 日 24 时，蘑菇街总成交额超过 3.37 亿，移动端成交占比持续稳定在 75% 以上，客单超过 250 元。双十一当天的成交额近 2 亿，虽然也就天猫几分钟的交易量，但是我们还是很激动，今年也是蘑菇街新的开始。

InfoQ：嗯，其实也很不错，蘑菇街第一次做交易就能交出了这么好的一份答案。双十一高峰时期系统的压力也不小吧，为了保证系统在这样的短时高并发场景下的稳定性以及高可用性，蘑菇街在架构方面做了哪些调整？

岳旭强：我们从去年年底一直到今年上半年一直在做架构方面调整。以前蘑菇街整个架构是混在一起的，没有什么架构可言，因为那个时候最主要的诉求就是灵活、简单、快速实现需求，所以技术方面没有太多东西。可以说从 2010 年底开始做蘑菇街一直到去年下半年，整个架构上没有太大的优化和调整，所有的东西就跟小网站一样的，代码都写在一起，只有一个大的代码库，也没有什么太多分层。

随着蘑菇街从导购网站向垂直电商的转型，系统也就开始变得越来越复杂。从去年年底开始，我们就着手架构方面的调整。其实所有的系统都一样，当大到一定程度后所要做的第一件事情都是拆分，也就是微服务化。拆分主要是从两个层面去做，我们先从垂直层面（业务）做了一些拆分，把交易、资金、评价、商品等服务化，每一个是单独的系统，系统与系统之间通过接口通信。

水平层面的话，我们把比较重要的应用的核心服务抽取出来，比如说资金业务、交易业务、商品业务。以前它们是一个单独的系统，可能从 Web 访问到中间的业务处理，再到 DB 都是在一起的，拆分之后，Web 服务和业务处理就被隔离开来，业务处理的服务也会被其它业务调用。拆分之后中间也就会用一些异步的消息机制来提高系统的稳定性。

拆分之后系统之间相互隔离，一定程度上提高了系统的稳定性。比如这次双十一活动中，11 号凌晨的时候活动系统垮了，但只是活动的相关业务不能访问，其它的业务不会受影响。

当然为了保证拆分后系统的稳定性，我们也开发了很多基础的组件，比如我们跨语言通讯的框架、缓存集群方案、内部系统负载均衡方案、数据库中间层。

InfoQ：交易场景下，数据库的读操作远大于写操作，这个时候数据库的负载也特别大。针对这次双十一，蘑菇街在数据库方面做了哪些优化？

岳旭强：数据库这块其实我们也是按照服务、业务来拆分的，比如负责交易的团队会全权负责交易系统的数据库，交易的数据库是独立的一个集群，使用的是 MySQL，有做读写分离，主要是使用我们自己研发的中间层 donquixote（堂吉柯德），它的主要功能是连接池、屏蔽非法 SQL、读写分离。

针对这次双十一，我们主要做了两件事，一个是硬件层面的扩容。一个是数据库 SQL 查询优化，我们大概花了两个月时间，把所有的 SQL 查询全部优化了一遍，虽然每一个都比较细小，但是最后综合起来的效果非常明显。同样的配置下，没有优化之前每秒处理的订单数大概是 900 单，优化之后每秒的可以处理的订单翻了一倍，1700 单。

InfoQ：秒杀这样的场景下，蘑菇街是如何保证数据的一致性的？

岳旭强：这个其实蛮麻烦的，以前蘑菇街做导购社区的时候，一致性的问题基本不用考虑。但是做交易的话，这个事就变得非常复杂，
秒杀这样的场景下，主要需要解决超卖和错单的问题。解决超卖，我们主要将秒杀交易全部异步化, 库存、优惠券的扣除都是异步队列消费时处理，同时保证最先入队的人先下单。解决错单的问题，会在交易下单时, 第一步 push 异步队列, 第二步日志打点, 后台处理同时校验日志、队列中的消息，以保证数据的正确性。

InfoQ：在双十一之前蘑菇街应该也做了很多次演练，双十一高峰期有没有出现演练时没有预想到的情况？

岳旭强：哈哈，当然有。一开始我们根据去年的交易情况以及最近的业务量对双十一的交易量做了个预估，我们觉得一天 1 个亿差不多了，数据库按照六七月份数据库的线上峰值为基准，放大八倍压测，Web 服务器按照十五倍压测，这是双十一前的准备。但是没想到 10 号凌晨就达到我们的预案值了，当时很紧张，但是也很开心。我们先是紧急做了处理，砍掉了很多短期影响不是很大的功能和业务，尽量的优化和减少系统的压力。接下来的一天时间又对数据库做了优化调整，包括限流等应急措施。Web 那块我们觉得 8 台机器问题不大，并且扩展也很容易之前的准备也比较充分，所以也没有把精力放在这上面。

11 号还没到 0 点的时候，11：56，活动系统就被冲垮了。限流保护都没有产生作用，瞬间被冲垮了，因为限流是需要延后一小点时间，数据过来后才做限制操作的，当时还没来得及，几台机器就垮掉了，这是没想到的。当时我们加了几台机器，终于在 0：11 的时候恢复正常了。第二天我们回放当天的日志，活动系统超过了我们当时预案的 10 多倍。这 10 多分钟，按照 10 号的量，可能损失就有 1000 万。

这两天我们也会复盘，总结一下这次遇到的问题，后续也希望能分享给 InfoQ 的读者。