一、大麦抢票背景

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

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

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

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

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

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

二、“原始”阶段

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

为何会这样

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

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

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

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

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

方案和结果

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

三、“弹内化”阶段

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

空中换引擎

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

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

2）借助阿里基础运维能力：由于入口接口入到阿里域，一些限流及降级的事情利用平台就可以做，运维监控也完全可以利用 eagleeye、maieye 等排查工具来做了；此过程中

用户中心、消息中心等服务开始向阿里域内重构并上线；

3）抢票预案初步建立：在主站的预案平台建立了大麦的大型抢票预案，比如：商品详情页增加了 tair 缓存，靠 tair 在阿里域内扛住流量，减少打到大麦 IDC 的请求调用；

坚定路线不动摇

优化后的热量抢票项目系统正常，但限流会影响用户体验。分析抢票过程中出现的问题，集中在了弹内化范围、机房的瓶颈、运维经验不足等。所以，催生了第三阶段，大型抢票全链路收口进阿里域内。

四、“体系化”阶段

针对上阶段遗留的问题，业务和技术针对抢票流程和系统做了全体系化升级，确立了完善的抢票流程和抢票保障机制。升级后的大麦能承接住所有大型抢票，且用户体验有所提升。

弹内化全面开花

1）新搜索在阿里域内上线，搜索 response 过大的问题也都解决，不存在对带宽的影响了；

2）新选座在阿里域内上线，大型抢票的选座流量直接打到阿里域内，利用异步化和类似 ConcurrentHashMap 的机制平衡了对大麦 IDC 选座的调用量及缓存的一致性；

3）新交易在阿里域内上线，将核心的创建事务号接口、下单接口全部都放在了阿里域内，单下单后订单要同步到大麦机房的进行后续履约服务；

保障流程建起来

基于抢票活动业务方和技术方信息不一致、或临时抢票活动准备不充分等情况，由测试方牵头和各业务方、各技术方针对抢票流程、参与人员、抢票设置各项达成一致，并沉淀出抢票保障流程和方案，相关人为操作建立 SOP 保障，优化后的流程为：

1）【流程建设】抢票阶段分为抢票前、抢票中、抢票后：

抢票前重点是由业务方抢票申报，再由技术方确认是否安排预演或压测，根据业务方和历史抢票信息判断抢票级别来决定抢票预案执行范围和风控级别；

抢票中重点是过程监控和应急处理；

抢票后重点是预案恢复、抢票报表输出，以及抢票过程中问题复盘；

2）【流程建设】抢票参与角色中：产品、开发、测试、公关

抢票涉及多个业务方，主要业务保障人是 BD、编辑、客服，主要支持角色有开发、测试、客服、公关等相关人员；

抢票过程中相关角色各司其职，共同保障抢票。印象比较深的就是这个阶段每逢大抢，一屋子相关抢票人员聚集，在抢票顺利完成后，会议室传出的阵阵欢呼声！

预案/预演/容量/Action 专项

抢票保障的每一项操作都需要在业务方明确项目信息后，由测试牵头拉各方参与人员整体评估和协调执行，不管是抢票前的准备还是抢票后的复盘，每个小的专项都执行到位。

1）【质量保障】项目预演：一般已有成熟流程的项目不会再安排预演，对大型抢票或未抢过的新玩法，测试方会安排模拟抢票。主要由各业务方、技术方和各端测试同学共同参与，提前暴露业务、设置问题或体验问题；

2）【质量保障】性能容量：技术拉取全链路最近类似项目的最新压测数据，和线上实际容量做评估，分析抢票预估量是否能顺利支撑，是否有性能瓶颈或限流情况，提前通知业务方；如项目玩法没有最近的压测数据支撑，由测试方安排大抢项目压测；

3）【技术优化】预案执行：全链路涉及的首页搜索、商品详情、票务云选座、交易下单、票务云库存、订单服务、无线端等梳理大抢模式的前置预案和紧急预案。如商品详情前置预案：对艺人、关注、营销等降级处理，调整用户、场馆、详情缓存时长，抢票前 30 分钟预热限购服务的 BD 和 tair 等；

4）【质量保障】问题复盘：每次抢票完成后对抢票过程中各方暴露的问题、客服反馈的高咨询、线上收集的 bug、内网帖子吐糟、外部用户微博或微信转载等问题，测试方统一收集，组织各方复盘后优化方案落实到 action，并跟进 action 执行进度；

抢票监控大盘

除各业务定制的抢票监控项外，抢票期大盘的汇总数据监控，可以为每次抢票更好地提供监控数据支持，方便业务方一目了然 get 到抢票数据，具体信息如下：

五、“常态化”阶段

上阶段系统化升级完善后，大家肯定会问，大麦抢票不会出问题了吧？

我们可以很负责地说肯定再不会出现宕机情况，但是在近期超稀缺 IP 抢票因为项目太火爆，抢到票的毕竟是少数人，大抢之后出现的二手高价售卖现象、抢票不流畅导致抢不到票等问题，被抢不到票的内网小二、外网用户疯狂吐槽。

总结槽点主要集中在抢不到票、商品详情被限流、下单交互耗时导致抢不到票、抢票异常情况对用户提示不友好等等，针对这些问题除了产品方案的优化，技术同学也成立了很多抢票专项解决用户痛点，这些小而美的体验极致优化，你注意到了吗？

为真实用户护航

此阶段磨砺了近一年的大麦新交易系统上线了，新交易和共享星环平台全面融合，核心的渲染接口、下单接口基于星环能力实现了大麦扩展特性；新交易架构图如下：

融入共享对大麦来说好处很多，针对抢票流程的贡献主要有 3 点：

1）【技术优化】依托共享基础能力

除了可以复用共享能力，还可以参考主站交易的大抢方案，比如限流、系统日志监控、问题排查平台等等。技术方实现基于星环体系的未支付关单定制，由业务方指定关单时长，有效降低了恶意占用库存现象发生。

2）【体验升级】接入集团风控体系：

服务于线上火爆抢票的三层防控技术体系，实际由大麦用户风险评分、集团安全 MTEE 人机识别、定制化的策略包组成。在交易流程的渲染、下单以不同维度对非法用户进行二次拦截，让真实用户的抢票体验更顺滑，大大提升了真实用户的购买率。

核心链路模型优化

1）【体验升级】商品详情无限流：从以往抢票看，商品详情页每逢大抢不仅要借机器还要限流，成为了用户槽点聚集地。商品详情主要实现了流量分散策略：

a）策略上减少开抢前并发请求，由于散列控制在较短时间，能够快速上线快速验证，但效果不明显；

b）交互上倒计时结束后用户点击替代自动刷新来分散流量，效果明显

c）流程上减少物理调用，倒计时用户点击购买时只调用二级页，倒计时校验交给二级页，效果非常明显

改造后详情页与弹层页流量从巨大差距到基本持平再到流量较大反转，商品详情抢票再也不用借机器，且足以支撑目标最高热门项目抢票，再不会触发限流！

2）【体验升级】交易下单扩入口：从以往抢票看，交易下单大流量时容易触发限流，用户反馈抢不到票。针对交易下单的主要策略是：

a）放大入口+风控拦截+兜底限流，首先让真实用户能够进到交易，再通过风控过滤掉异常用户，最后用兜底限流保护下游系统，从而最大限度的保障用户抢票顺滑；

b）对渲染阶段的支付方式和支付特权做优化，实现大抢时渲染对支付方式调用降级，降低用户渲染或异步渲染被流控的风险；

性能常态化

为摸清交易链路最新性能水位，测试团队启动了性能常态化项目。每月定时执行压测，并结合当月各系统功能发布、性能优化或上下游支持，评估具体的压测场景和压测目标，压测完毕后更新链路依赖现状，为抢票提供最有效数据。

1）【质量保障】常态化执行：如近期的稀缺 IP 项目抢票再次刷新各榜单列表，开发和测试一起根据现有流量重新对系统进行压测摸高评估。

2）【质量保障】压测自动化：测试梳理了压测流程，沉淀了各业务线压测白皮书。提炼出过程中耗时较多的步骤，实现自动化执行，如原临时项目生成压测数据和压测前设置需要 11-12 步耗时半天，现在常态化固定项目生成压测数据和仅需要 3-4 步 3 分钟即可。

预案自动化

之前抢票存在抢票活动频繁，抢票无统一规范流程（监控、预案、入口），支持人数多，组织抢票会议，耗费人力等问题。

1）【技术优化】抢票控制台：

使 BD 或者运营在【抢票开始前】可以设置一些预案，【抢票过程中】提供统一视图对抢票进行【实时监控】，并且有能力进行【人为的干预和控制】，在【抢票结束后】能够提供历次抢票数据以供分析，从而帮助 BD 自助完成抢票，实现“无人值守”具体实现流程如下：

2）【技术优化】商品详情预案：

详情页每次大抢都需要人工降级 6~10 项预案，各项预案设置的值、执行时间等各有差异，在预案设置时还需根据个人经验做评估调整，人工操作太繁琐。详情预案基础策略是对原降级项实现本地缓存或 tair 缓存，第三方依赖接口限流异常降级补充，优化后仅保留 1 项需手动配置的预案，其他皆已实现自动化。

常态化成果

通过常态化各专项保障取得明显成效，近一年支持的抢票项目近千场，其中大型抢票近百场。其中近期热门「超大抢」项目，商详/下单渲染/下单均创历史峰值，系统顺利承接；热门「大抢」项目，特权码选座和普通选座，特权及选座峰值均创新高，系统顺利承接；

六、结语

大麦抢票经历了“原始”阶段、流程建设、技术优化、专项保障等四个阶段建设后系统已稳如磐石，对提升用户体验上也在不断努力。当然可能还是存在或多或少的问题，目前的技术方案也可能不是最优的，比如项目热度智能分析、风控自动调节等等，也已经在技术优化计划中，在抢票的路上大麦会秉持初心一直奔跑！

作者简介：

阿里文娱测试开发专家舒琴、阿里文娱测试开发锦烨

相关链接

阿里怎样守护产品线上质量？大麦用虚拟机器人搞定

大麦交易融入阿里电商平台之路

创作场景

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