蘑菇街，以导购起家的女性时尚电商，目前已经上线自己的电商交易平台，全面转型为垂直电商。

据官方数据显示，蘑菇街双十一交易额已突破一亿元，并提前完成了此前的预定目标。蘑菇街今年第一次自己做交易，虽说总的交易量只有天猫几分钟的量，但峰值时期系统的压力同样不小，并且他们也才刚刚开始。

 

那蘑菇街是怎么准备这场战争的？相应做了哪些预案？

岳旭强，蘑菇街CTO，曾于2004年加入淘宝，参与并主导核心业务系统搭建，2007年开始负责淘宝服务化体系建设。2010年底离职创业，组建并带领蘑菇街技术团队，支撑蘑菇街的高速发展和业务转型，有丰富的架构设计和技术团队管理经验。

 

蘑菇街成交额

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

 

架构设计优化

双十一高峰时期系统的压力也不小，为了保证系统在这样的短时高并发场景下的稳定性以及高可用性，蘑菇街从去年年底一直到今年上半年一直在做架构方面调整。

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

随着蘑菇街从导购网站向垂直电商的转型，系统也就开始变得越来越复杂。从去年年底开始，我们就着手架构方面的调整。其实所有的系统都一样，当大到一定程度后所要做的第一件事情都是拆分，也就是微服务化。

拆分主要是从两个层面去做，我们先从垂直层面（业务）做了一些拆分，把交易、资金、评价、商品等服务化，每一个是单独的系统，系统与系统之间通过接口通信。

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

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

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

 

数据库业务拆分

交易场景下，数据库的读操作远大于写操作，这个时候数据库的负载也特别大。针对这次双十一，蘑菇街数据库这块其实也是按照服务、业务来拆分的，比如负责交易的团队会全权负责交易系统的数据库，交易的数据库是独立的一个集群，使用的是MySQL，有做读写分离，主要是使用我们自己研发的中间层donquixote（堂吉柯德），它的主要功能是连接池、屏蔽非法SQL、读写分离。

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

 

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

这个其实蛮麻烦的，以前蘑菇街做导购社区的时候，一致性的问题基本不用考虑。但是做交易的话，这个事就变得非常复杂，


秒杀这样的场景下，主要需要解决超卖和错单的问题。解决超卖，我们主要将秒杀交易全部异步化, 库存、优惠券的扣除都是异步队列消费时处理，同时保证最先入队的人先下单。解决错单的问题，会在交易下单时, 第一步push异步队列, 第二步日志打点, 后台处理同时校验日志、队列中的消息，以保证数据的正确性。


 

在双十一之前蘑菇街应该也做了很多次演练，双十一高峰期有没有出现演练时没有预想到的情况？当然有。一开始我们根据去年的交易情况以及最近的业务量对双十一的交易量做了个预估，我们觉得一天1个亿差不多了，数据库按照六七月份数据库的线上峰值为基准，放大八倍压测，Web服务器按照十五倍压测，这是双十一前的准备。

但是没想到10号凌晨就达到我们的预案值了，当时很紧张，但是也很开心。我们先是紧急做了处理，砍掉了很多短期影响不是很大的功能和业务，尽量的优化和减少系统的压力。接下来的一天时间又对数据库做了优化调整，包括限流等应急措施。Web那块我们觉得8台机器问题不大，并且扩展也很容易之前的准备也比较充分，所以也没有把精力放在这上面。

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

 

 

原文： InfoQ