高并发大流量，大麦抢票的技术涅槃之路

一、大麦抢票背景

大麦网主要的业务范围为演唱会、音乐会、体育赛事、话剧、展销会、亲子活动等现场类的票务业务，其业务链条涵盖从 B 端生产、C 端销售、现场换验的全套流程。大麦网一类典型项目是稀缺的火爆 IP 项目，如演唱会、游戏体育赛事，这类票务隐含了时间、空间的特殊限制属性，是需要抢的。大麦抢票是演出行业的双 11，涉及场景复杂、系统较多、链路较长，抢票保障尤为重要。

大麦抢票保障大致经历了几个阶段：

第一阶段：“原始”阶段，保障不健全，设施不完善；

第二阶段：“弹内化”阶段，部分大型抢票顺利完成；

第三阶段：“体系化”阶段，能够承接所有大型抢票；

第四阶段：“常态化”阶段，大抢体验优化升级。

二、“原始”阶段

大抢容易出现限流，体验不顺畅等现象，囧！

1. 为何会这样

此阶段的大麦还处在原技术团队和阿里系业务、产品、技术各方都在讨论及对焦阶段，大部分大型抢票核心系统还在大麦的 IDC 机房，技术体系走.net 和 java 的混合体系，大麦原体系主要承载此阶段的大型抢票任务。

为什么此体系下，每逢大型抢票就会面临如此大的压力和风险呢？分析主要有以下几点原因：

1）保障设施不健全：大麦 IDC 机房硬件设备、带宽等均有限制；DB 采用 SQL SERVER 企业版，很多数据库都是单库。在应对大型抢票时（特别是选座购买，耗带宽、耗资源），会面临严峻挑战；

2）预案 / 限流待建设：系统在高流量、高压力下的保护措施待建设，比如：限流和降级，造成系统一旦超过压力，就直接报警；

3）监控运维零散：定位问题、解决问题耗时较长。

2. 方案和结果

这阶段也采取了一些临时方案，比如：极简限流方案、一些点的性能优化、修改应用配置参数、整理抢票预案等等，也缓解了一些问题，但整体上仍未解决大型抢票问题。

三、“弹内化”阶段

基于第一阶段的诸多问题，产品、技术已经启动大面积系统改造，直接重构新系统到阿里域内，用新系统建设逐步替代老系统，即空中换引擎方案。

1. 空中换引擎

要快速将关键系统重构到阿里域内，确立了直接迁移、临时方案或长期重构等步骤，具体方案是：

1）APP 链路部分弹内化：技术改造重点放在无线端，所有 APP 用户调用接口的入口先走到阿里域，再路由到大麦 IDC，让阿里机房来抵档大量流量；

2）借助阿里基础运维能力：由于入口接口入到阿里域，一些限流及降级的事情利用平台就可