搶票系統(tǒng)怎么設計才不超賣Awesome Architecture案例StarArena完整推演虛擬等候室鎖座支付狀態(tài)機【免費下載鏈接】awesome-architecture Architecture-first system design: 26 bilingual tutorials, 25 architecture templates, and 6 end-to-end cases covering distributed systems, AI-native systems, RAG, coding Agents, and production trade-offs.項目地址: https://gitcode.com/gh_mirrors/awesomearc/awesome-architectureAwesome Architecture是一個專注「架構」而非「代碼」的開源知識庫收錄了 26 篇雙語教程、25 張架構模板和 6 個端到端案例。其中的StarArena 演唱會搶票系統(tǒng)案例把「100 萬人搶 2 萬張票」這個最尖的壓力場景完整推演了一遍從為什么必須上虛擬等候室到鎖座預占 超時釋放如何防止超賣和占座再到支付狀態(tài)機 冪等 對賬補償怎么兜住回調遲到、重復、丟失的壞情況。本文帶你用 10 分鐘讀懂這套搶票系統(tǒng)架構設計。 搶票為什么不是普通下單先算一筆入口賬普通電商庫存不夠可以補貨演唱會座位是天然有限庫存——2 萬個座位賣多一張就是事故普通瀏覽高峰頁面慢一點可以忍搶票的高峰是同一秒的瞬時尖刺。StarArena 案例先做了一筆很「要命」的粗算維度數(shù)量級場館座位20,000 個預約提醒人數(shù)1,000,000 人開售前 10 秒實際點擊約 300,000 次用戶平均重試次數(shù)2 次入口搶票請求≈ 60,000 req/s真正能買到票的人≤ 20,000這筆賬的結論很反直覺98% 以上的請求注定買不到票所以不能讓它們全部打進最貴、最脆弱的核心鏈路。架構重心由此確定先擋流量再談下單先控資格再談庫存先保證可恢復再談體驗順滑。 這是搶票系統(tǒng)的第一性原理把洪峰擋在門外遠比在門內拼命加機器有效。 虛擬等候室如何扛住開售瞬間的 6 萬 QPS舊路徑的問題三個動作擠在一條鏈路上早期 StarArena 賣的是小型 Livehouse 演出單體應用完全夠用。但頂流開售后架構立刻暴露出裂縫觸發(fā)信號表現(xiàn)入口洪峰過尖10 秒內 60,000 req/s 直接打到搶票接口熱門票檔成熱點同一票檔被反復爭搶庫存扣減集中到少數(shù)記錄數(shù)據(jù)庫鎖等待飆升下單 P99 從幾百毫秒變成數(shù)秒甚至超時支付回調亂序/丟失用戶付了錢訂單還顯示待支付核心矛盾在于開售按鈕背后其實是三個完全不同的動作——爭資格、鎖庫存、收錢出票。早期單體把它們揉在一條同步鏈路里小流量下沒問題洪峰下必然被撕開。新架構所有請求先進「虛擬等候室」演進后的搶票主鏈路分成清晰的幾段用戶 → CDN/活動頁 → 虛擬等候室(發(fā)令牌) → 選票/鎖座入口 → 座位庫存服務(鎖座/釋放) → 訂單狀態(tài)機(待支付) → 第三方支付 → 出票服務 → 對賬/補償任務各段的職責邊界非常清楚CDN活動頁靜態(tài)內容盡量不進入核心系統(tǒng)虛擬等候室所有人先排隊按系統(tǒng)真實承受力一批批發(fā)放一次性放行令牌把洪峰「整形」成細水長流選票/鎖座入口校驗令牌、用戶資格和防刷規(guī)則庫存服務只管座位的鎖定、釋放、確認用原子操作扣減絕不超賣訂單狀態(tài)機承認支付和出票不會一次成功用狀態(tài)推進而非「賭一次同步調用」。?? 常見誤區(qū)把虛擬等候室理解成「一個排隊頁面」。它的靈魂不是讓用戶等待而是準入控制——令牌不是訂單拿到令牌才允許進入最脆弱的鎖座鏈路。 票到底什么時候扣三種扣減時機方案對比這是整個案例最重要的決策庫存扣減時機決定了訂單、支付、出票的整個結構。方案流程優(yōu)點代價A · 支付成功后扣票下單 → 支付 → 扣票 → 出票沒付款不占庫存座位利用率高可能出現(xiàn)「支付成功但票沒了」退款投訴事故B · 下單時直接扣票下單成功 正式扣票 → 等支付邏輯直觀不易超賣大量用戶不支付會長期占票黃牛可惡意占座C ·鎖座預占 超時釋放搶資格 → 鎖座(15 分鐘) → 待支付訂單 → 支付成功正式出票超時未支付自動釋放防超賣也避免未支付訂單永久占票狀態(tài)機更復雜要處理超時、回調、補償StarArena 選擇方案 C因為它匹配三條硬約束票不能超賣、支付可能失敗、用戶不能無限占座。一句話記住這個模式「占用 超時釋放」是所有「臨時持有稀缺資源」場景的通用解——訂座、庫存預占、分布式鎖都是它。防超賣本身還有個關鍵細節(jié)普通「查余量 → 減余量 → 寫回」在高并發(fā)下必然超賣兩個請求都讀到剩 1 張各扣一張。正確做法是用原子操作「扣減并返回結果」只有一個請求能把最后一張減成 0另一個拿到「不足」。在線票務/搶票模板 里還有更進一步的手段熱點庫存放內存原子扣減、必要時分段庫存把 1000 張拆成 10 段各 100 張分散競爭。?? 支付狀態(tài)機回調遲到、重復、丟失都怎么兜搶票系統(tǒng)最危險的不是慢而是慢的時候還把票和錢弄錯。第三方支付是外部系統(tǒng)回調可能延遲、重復、丟失所以支付鏈路必須「為失敗而設計」機制解決什么問題訂單狀態(tài)機明確規(guī)定「待支付 → 已支付 → 已出票 / 已關閉」狀態(tài)不能亂跳冪等推進同一個支付回調重復來幾次結果也只算一次已處理直接返回成功狀態(tài)條件更新超時任務只在訂單仍是「待支付」時才能關單支付回調只在「待支付/支付確認中」時才能推進——靠條件保護而不是靠時間猜主動查單回調沒來就定期主動問支付平臺不依賴「別人一定會通知我」對賬 補償定時比對訂單、支付、出票三方狀態(tài)發(fā)現(xiàn)卡住如「已支付未出票」自動補推一個最刁鉆的競態(tài)用戶在第 14 分 59 秒支付回調第 15 分 02 秒才到和超時釋放任務撞車?？俊笗r間」判斷必錯靠狀態(tài)版本號 條件更新才能保護兩邊只有一個能贏另一邊失敗后由對賬任務修復。 冪等、Saga、對賬這些手藝的系統(tǒng)講法見教程 11 · 數(shù)據(jù)一致性工程 和 12 · 為失敗而設計支付側的賬本與復式記賬設計見 支付系統(tǒng)架構模板。 壞了怎么辦六類故障場景的兜底設計搶票系統(tǒng)的成熟度不看成功路徑多漂亮而看壞情況能不能被系統(tǒng)自己發(fā)現(xiàn)、自己推進、自己修回來故障直接后果架構兜底等候室發(fā)令牌過快鎖座鏈路被打爆監(jiān)控 P99 與令牌消耗速度動態(tài)降低放行速率用戶鎖座后不支付好座位被占住15 分鐘超時掃描自動釋放座位支付成功但回調丟失用戶扣錢、訂單仍待支付主動查單 支付對賬冪等補推狀態(tài)繼續(xù)出票支付回調重復訂單被重復推進回調冪等鍵 支付單唯一索引出票服務短暫故障已支付但沒拿到票訂單進入「待出票」服務恢復后補發(fā)釋放與回調撞車誤關已支付訂單條件更新 對賬修復 延伸閱讀如何讀這個倉庫的對應資料本案例不是重寫票務模板而是把模板里最危險的一條鏈路拿出來細推。推薦讀法先讀案例再回看模板你會更容易看懂「虛擬等候室」為什么是靈魂部件而不是可有可無的排隊頁。資料相對路徑讀什么? StarArena 案例正文cases/stararena-ticketing/README.md完整推演入口賬 → 觸發(fā)信號 → ADR 決策 → 數(shù)據(jù)流 → 故障兜底? 在線票務/搶票模板templates/online-ticketing/README.md虛擬等候室、原子扣減、鎖座超時的架構地圖與常見反模式 支付系統(tǒng)模板templates/payment-system/README.md冪等、狀態(tài)機、對賬、復式記賬 電商平臺模板templates/ecommerce-platform/README.md商品/訂單/庫存/支付的基本關系 方法論教程08 · 架構決策記錄與演進案例中 ADR-01/02/03 的記錄方式 案例總覽cases/README.md6 個案例怎么配合模板與教程讀? 五句話總結舊架構不是錯約束變了才需要演進——小活動單體合理頂流開售把它逼到邊界先算入口賬再畫架構圖——6 萬 req/s 里 98% 注定失敗逼出虛擬等候室搶票要拆三段——搶資格、鎖庫存、收錢出票每段才能限流、超時、重試、補償鎖座預占是拿復雜度換正確性——避免「錢扣了沒票」也用超時釋放避免長期占票支付成功不是結束而是狀態(tài)推進的開始——沒有冪等、狀態(tài)機和對賬補償系統(tǒng)遲早要人工救火。【免費下載鏈接】awesome-architecture Architecture-first system design: 26 bilingual tutorials, 25 architecture templates, and 6 end-to-end cases covering distributed systems, AI-native systems, RAG, coding Agents, and production trade-offs.項目地址: https://gitcode.com/gh_mirrors/awesomearc/awesome-architecture創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考