作者 | 阿里文娛測試開發專家舒琴、錦燁

出品 | AI科技大本營（ID:rgznai100）

大麥搶票背景

大麥網主要的業務範圍為演唱會、音樂會、體育賽事、話劇、展銷會、親子活動等現場類 的票務業務，其業務鏈條涵蓋從 B 端生產、C 端銷售、現場換驗的全套流程。大麥網一類典型項目是稀缺的火爆 IP 項目，如演唱會、遊戲體育賽事，這類票務隱含了時間、空間的特殊限制屬性，是需要搶的。大麥搶票是演出行業的雙 11，涉及場景複雜、系統較多、鏈路較長，搶票 保障尤為重要。

大麥搶票保障大致經歷了幾個階段：第一階段：“原始”階段，保障不健全，設施不完善；第二階段：“彈內化”階段，部分大型搶票順利完成；第三階段：“體系化”階段，能夠承接所有大型搶票；第四階段：“常態化”階段，大搶體驗優化升級。

“原始”階段

大搶容易出現限流，體驗不順暢等現象，囧！

1. 為何會這樣

此階段的大麥還處在原技術團隊和阿里系業務、產品、技術各方都在討論及對焦階段，大 部分大型搶票核心系統還在大麥的 IDC 機房，技術體系走.net 和 java 的混合體系，大麥原體系 主要承載此階段的大型搶票任務。

為什麼此體系下，每逢大型搶票就會面臨如此大的壓力和風險呢？分析主要有以下幾點原 因：

1）保障設施不健全：大麥 IDC 機房硬件設備、帶寬等均有限制；DB 採用 SQL SERVER 企業版，很多數據庫都是單庫。在應對大型搶票時（特別是選座購買，耗帶寬、耗資源），會面 臨嚴峻挑戰；

2）預案/限流待建設：系統在高流量、高壓力下的保護措施待建設，比如：限流和降級， 造成系統一旦超過壓力，就直接報警；

3）監控運維零散：定位問題、解決問題耗時較長。

2. 方案和結果

這階段也採取了一些臨時方案，比如：極簡限流方案、一些點的性能優化、修改應用配置 參數、整理搶票預案等等，也緩解了一些問題，但整體上仍未解決大型搶票問題。

“彈內化”階段

基於第一階段的諸多問題，產品、技術已經啟動大面積系統改造，直接重構新系統到阿里 域內，用新系統建設逐步替代老系統，即空中換引擎方案。

1. 空中換引擎

要快速將關鍵系統重構到阿里域內，確立了直接遷移、臨時方案或長期重構等步驟，具體 方案是：

1）APP 鏈路部分彈內化：技術改造重點放在無線端，所有 APP 用戶調用接口的入口先走 到阿里域，再路由到大麥 IDC，讓阿里機房來抵檔大量流量；

2）藉助阿里基礎運維能力：由於入口接口入到阿里域，一些限流及降級的事情利用平臺就 可以做，運維監控也完全可以利用 eagleeye、maieye 等排查工具來做了；此過程中用戶中心、消息中心等服務開始向阿里域內重構並上線；

3）搶票預案初步建立：在主站的預案平臺建立了大麥的大型搶票預案，比如：商品詳情頁 增加了 tair 緩存，靠 tair 在阿里域內扛住流量，減少打到大麥 IDC 的請求調用；

2. 堅定路線不動搖

優化後的熱量搶票項目系統正常，但限流會影響用戶體驗。分析搶票過程中出現的問題， 集中在了彈內化範圍、機房的瓶頸、運維經驗不足等。所以，催生了第三階段，大型搶票全鏈 路收口進阿里域內。

“體系化”階段

針對上階段遺留的問題，業務和技術針對搶票流程和系統做了全體系化升級，確立了完善 的搶票流程和搶票保障機制。升級後的大麥能承接住所有大型搶票，且用戶體驗有所提升。

1. 彈內化全面開花

1）新搜索在阿里域內上線，搜索 response 過大的問題也都解決，不存在對帶寬的影響了；

2）新選座在阿里域內上線，大型搶票的選座流量直接打到阿里域內，利用異步化和類似 ConcurrentHashMap 的機制平衡了對大麥 IDC 選座的調用量及緩存的一致性；

3）新交易在阿里域內上線，將核心的創建事務號接口、下單接口全部都放在了阿里域內， 單下單後訂單要同步到大麥機房的進行後續履約服務；

2. 保障流程建起來

基於搶票活動業務方和技術方信息不一致、或臨時搶票活動準備不充分等情況，由測試方 牽頭和各業務方、各技術方針對搶票流程、參與人員、搶票設置各項達成一致，並沉澱出搶票 保障流程和方案，相關人為操作建立 SOP 保障，優化後的流程為：

1）【流程建設】搶票階段分為搶票前、搶票中、搶票後：搶票前重點是由業務方搶票申報，再由技術方確認是否安排預演或壓測，根據業務方和歷

史搶票信息判斷搶票級別來決定搶票預案執行範圍和風控級別；

搶票中重點是過程監控和應急處理；搶票後重點是預案恢復、搶票報表輸出，以及搶票過程中問題覆盤；2）【流程建設】搶票參與角色中：產品、開發、測試、公關 搶票涉及多個業務方，主要業務保障人是 BD、編輯、客服，主要支持角色有開發、測試、客服、公關等相關人員；

搶票過程中相關角色各司其職，共同保障搶票。印象比較深的就是這個階段每逢大搶，一 屋子相關搶票人員聚集，在搶票順利完成後，會議室傳出的陣陣歡呼聲。

3. 預案/預演/容量/Action 專項

搶票保障的每一項操作都需要在業務方明確項目信息後，由測試牽頭拉各方參與人員整體 評估和協調執行，不管是搶票前的準備還是搶票後的覆盤，每個小的專項都執行到位。

1）【質量保障】項目預演：一般已有成熟流程的項目不會再安排預演，對大型搶票或未搶 過的新玩法，測試方會安排模擬搶票。主要由各業務方、技術方和各端測試同學共同參與，提 前暴露業務、設置問題或體驗問題；

2）【質量保障】性能容量：技術拉取全鏈路最近類似項目的最新壓測數據，和線上實際容 量做評估，分析搶票預估量是否能順利支撐，是否有性能瓶頸或限流情況，提前通知業務方；如項目玩法沒有最近的壓測數據支撐，由測試方安排大搶項目壓測；

3）【技術優化】預案執行：全鏈路涉及的首頁搜索、商品詳情、票務雲選座、交易下單、 票務雲庫存、訂單服務、無線端等梳理大搶模式的前置預案和緊急預案。如商品詳情前置預案：對藝人、關注、營銷等降級處理，調整用戶、場館、詳情緩存時長，搶票前 30 分鐘預熱限購服 務的 BD 和 tair 等；

4）【質量保障】問題覆盤：每次搶票完成後對搶票過程中各方暴露的問題、客服反饋的高 諮詢、線上收集的 bug、內網帖子吐糟、外部用戶微博或微信轉載等問題，測試方統一收集， 組織各方覆盤後優化方案落實到 action，並跟進 action 執行進度；

4. 搶票監控大盤

除各業務定製的搶票監控項外，搶票期大盤的彙總數據監控，可以為每次搶票更好地提供 監控數據支持，方便業務方一目瞭然 get 到搶票數據，具體信息如下：

“常態化”階段

上階段系統化升級完善後，大家肯定會問，大麥搶票不會出問題了吧？我們可以很負責地說肯定再不會出現宕機情況，但是在近期超稀缺 IP 搶票因為項目太火

爆，搶到票的畢竟是少數人，大搶之後出現的二手高價售賣現象、搶票不流暢導致搶不到票等問題，被搶不到票的內網小二、外網用戶瘋狂吐槽。總結槽點主要集中在搶不到票、商品詳情被限流、下單交互耗時導致搶不到票、搶票異常

情況對用戶提示不友好等等，針對這些問題除了產品方案的優化，技術同學也成立了很多搶票

專項解決用戶痛點，這些小而美的體驗極致優化，你注意到了嗎？

1. 為真實用戶護航

此階段磨礪了近一年的大麥新交易系統上線了，新交易和共享星環平臺全面融合，核心的 渲染接口、下單接口基於星環能力實現了大麥擴展特性；新交易架構圖如下：

融入共享對大麥來說好處很多，針對搶票流程的貢獻主要有 3 點：1）【技術優化】依託共享基礎能力 除了可以複用共享能力，還可以參考主站交易的大搶方案，比如限流、系統日誌監控、問

題排查平臺等等。技術方實現基於星環體系的未支付關單定製，由業務方指定關單時長，有效

降低了惡意佔用庫存現象發生。

2）【體驗升級】接入集團風控體系：服務於線上火爆搶票的三層防控技術體系，實際由大麥用戶風險評分、集團安全 MTEE 人

機識別、定製化的策略包組成。在交易流程的渲染、下單以不同維度對非法用戶進行二次攔截，讓真實用戶的搶票體驗更順滑，大大提升了真實用戶的購買率。

2. 核心鏈路模型優化

1）【體驗升級】商品詳情無限流：從以往搶票看，商品詳情頁每逢大搶不僅要藉機器還要 限流，成為了用戶槽點聚集地。商品詳情主要實現了流量分散策略：

a）策略上減少開搶前併發請求，由於散列控制在較短時間，能夠快速上線快速驗證，但效 果不明顯；

b）交互上倒計時結束後用戶點擊替代自動刷新來分散流量，效果明顯 c）流程上減少物理調用，倒計時用戶點擊購買時只調用二級頁，倒計時校驗交給二級頁，效果非常明顯。改造後詳情頁與彈層頁流量從巨大差距到基本持平再到流量較大反轉，商品詳情搶票再也 不用藉機器，且足以支撐目標最高熱門項目搶票，再不會觸發限流！

2）【體驗升級】交易下單擴入口：從以往搶票看，交易下單大流量時容易觸發限流，用戶反饋搶不到票。針對交易下單的主要策略是：

a）放大入口+風控攔截+兜底限流，首先讓真實用戶能夠進到交易，再通過風控過濾掉異常 用戶，最後用兜底限流保護下游系統，從而最大限度的保障用戶搶票順滑；

b）對渲染階段的支付方式和支付特權做優化，實現大搶時渲染對支付方式調用降級，降低 用戶渲染或異步渲染被流控的風險；

3. 性能常態化

為摸清交易鏈路最新性能水位，測試團隊啟動了性能常態化項目。每月定時執行壓測，並 結合當月各系統功能發佈、性能優化或上下游支持，評估具體的壓測場景和壓測目標，壓測完 畢後更新鏈路依賴現狀，為搶票提供最有效數據。

1）【質量保障】常態化執行：如近期的稀缺 IP 項目搶票再次刷新各榜單列表，開發和測試 一起根據現有流量重新對系統進行壓測摸高評估。

2）【質量保障】壓測自動化：測試梳理了壓測流程，沉澱了各業務線壓測白皮書。提煉出 過程中耗時較多的步驟，實現自動化執行，如原臨時項目生成壓測數據和壓測前設置需要 11-12 步耗時半天，現在常態化固定項目生成壓測數據和僅需要 3-4 步 3 分鐘即可。

4. 預案自動化

之前搶票存在搶票活動頻繁，搶票無統一規範流程（監控、預案、入口），支持人數多，組 織搶票會議，耗費人力等問題。

1）【技術優化】搶票控制檯：

使 BD 或者運營在【搶票開始前】可以設置一些預案，【搶票過程中】提供統一視圖對搶票 進行【實時監控】，並且有能力進行【人為的干預和控制】，在【搶票結束後】能夠提供歷次搶 票數據以供分析，從而幫助 BD 自助完成搶票，實現“無人值守”具體實現流程如下：

2）【技術優化】商品詳情預案：

詳情頁每次大搶都需要人工降級 6~10 項預案，各項預案設置的值、執行時間等各有差異， 在預案設置時還需根據個人經驗做評估調整，人工操作太繁瑣。詳情預案基礎策略是對原降級 項實現本地緩存或 tair 緩存，第三方依賴接口限流異常降級補充，優化後僅保留 1 項需手動配 置的預案，其他皆已實現自動化。

5. 常態化成果

結語

大麥搶票經歷了“原始”階段、流程建設、技術優化、專項保障等四個階段建設後系統已穩如磐石，對提升用戶體驗上也在不斷努力。當然可能還是存在或多或少的問題，目前的技術方案也可能不是最優的，比如項目熱度智能分析、風控自動調節等等，也已經在技術優化計劃中。

【end】



「AI應用技術大師課」是CSDN發起的“百萬人學AI”倡議下的重要組成部分，4月份AI大師課以線上技術峰會的形式推出，來自微軟、硅谷TigerGraph、北郵等產學界大咖就圖計算+機器學習，語音技術、新基建+AI、AI+醫療等主題展開分享，
 
推薦閱讀

• 百萬人學AI：CSDN重磅共建人工智能技術新生態

• 154萬AI開發者用數據告訴你，中國AI如何才能彎道超車？

• 技術大佬的肺腑之言：“不要為了AI而AI”！| 刷新 CTO

• 悼念前端大牛司徒正美

• 業內最大的“空氣幣”——以太坊？

• Spark3.0發佈了，代碼拉過來，打個包，跑起來！

你點的每個“在看”，我都認真當成了AI

閱讀更多 AI科技大本營 的文章

關鍵字: 演唱會 人工智能