防超賣實(shí)戰(zhàn)：訂單狀態(tài)機(jī)與庫(kù)存設(shè)計(jì))
1. 項(xiàng)目背景與方案選型1.1 售票痛點(diǎn)與系統(tǒng)定位做線上動(dòng)物園售票系統(tǒng)之前很多人第一反應(yīng)是“這無(wú)非是個(gè) CRUD 項(xiàng)目”。真上手之后你會(huì)發(fā)現(xiàn)訂單、庫(kù)存、支付狀態(tài)、退票規(guī)則這些點(diǎn)每一個(gè)都能讓你加班到半夜。這個(gè)系統(tǒng)的核心價(jià)值一方面是替游客省去現(xiàn)場(chǎng)排隊(duì)買票的時(shí)間另一方面是幫園區(qū)把票務(wù)數(shù)據(jù)沉淀下來(lái)——銷量統(tǒng)計(jì)、熱門時(shí)段分析、游客畫(huà)像全都得有數(shù)據(jù)支撐才能做。這個(gè)項(xiàng)目我定位為課程設(shè)計(jì)/畢業(yè)設(shè)計(jì)級(jí)別的完整案例不是玩具但也沒(méi)有過(guò)度工程化。它要覆蓋一條完整的購(gòu)票鏈路游客瀏覽票種 → 注冊(cè)登錄 → 選擇日期與數(shù)量 → 創(chuàng)建訂單 → 模擬支付或?qū)诱鎸?shí)支付 → 生成電子票二維碼 → 入園時(shí)掃碼核銷。同時(shí)后臺(tái)需要支持票種管理、訂單管理、用戶管理、公告發(fā)布、數(shù)據(jù)統(tǒng)計(jì)。整個(gè)系統(tǒng)用 SpringBoot 作為后端主框架前端我選了 Vue Element UI數(shù)據(jù)庫(kù)用 MySQL緩存加了一層 Redis。如果你正準(zhǔn)備拿 Java 方向做畢設(shè)或課設(shè)這套組合的覆蓋面足夠廣答辯時(shí)也講得出東西。1.2 技術(shù)選型背后的取舍邏輯SpringBoot 在 Java 生態(tài)中的地位不用多說(shuō)我選它的核心原因是啟動(dòng)快、配置收斂、生態(tài)成熟。你不用像 SSM 時(shí)代那樣寫(xiě)一堆 XML一個(gè)SpringBootApplication就能跑起來(lái)。但這不代表你不需要理解底層——比如 SpringBoot 默認(rèn)整合了 Spring MVC、內(nèi)嵌 Tomcat、自動(dòng)配置機(jī)制你至少要明白spring-boot-starter-web幫你做了什么否則遇到詭異問(wèn)題根本無(wú)從排查。持久層框架我選了 MyBatis Plus而不是原生 MyBatis 或 JPA。原因很簡(jiǎn)單單表 CRUD 要是手寫(xiě) XML效率太低JPA 雖然省事但復(fù)雜查詢和 SQL 調(diào)優(yōu)不直觀。MyBatis Plus 兼顧兩者內(nèi)置的BaseMapper能覆蓋 80% 的簡(jiǎn)單操作復(fù)雜統(tǒng)計(jì)用注解 SQL 或 XML 自己寫(xiě)可控性很強(qiáng)。另外它自帶分頁(yè)插件后臺(tái)列表頁(yè)和訂單查詢都直接受益。Redis 的引入主要是兩件事一是緩存票種信息和公告減少數(shù)據(jù)庫(kù)壓力二是購(gòu)票時(shí)的庫(kù)存預(yù)扣與防超賣處理。這兩個(gè)場(chǎng)景用 Redis 的原子操作非常合適。如果只是純課程設(shè)計(jì)完全不引入 Redis 也能跑但我想讓這個(gè)項(xiàng)目有一點(diǎn)“生產(chǎn)味道”所以把它加了進(jìn)來(lái)。至于支付真實(shí)對(duì)接微信/支付寶需要商戶號(hào)個(gè)人項(xiàng)目拿不到所以我在項(xiàng)目中做了“模擬支付”模塊同時(shí)把支付接口抽象出來(lái)后續(xù)要對(duì)接真實(shí)支付只需替換實(shí)現(xiàn)類。2. 系統(tǒng)模塊與數(shù)據(jù)庫(kù)設(shè)計(jì)2.1 角色權(quán)限與功能模塊拆解整個(gè)系統(tǒng)按角色劃分成三類游客、注冊(cè)用戶、管理員。游客只能瀏覽票種和公告注冊(cè)用戶在前者基礎(chǔ)上增加了購(gòu)票、訂單查詢、退票、個(gè)人信息管理管理員則進(jìn)入后臺(tái)管理票種、訂單、用戶、公告還能看銷售統(tǒng)計(jì)報(bào)表。我畫(huà)模塊圖的時(shí)候習(xí)慣先列角色再列每個(gè)角色能做什么最后落到頁(yè)面和接口上。前臺(tái)部分的核心模塊是首頁(yè)輪播公告、票種列表、購(gòu)票流程選日期/選數(shù)量/創(chuàng)建訂單、訂單中心待支付/已支付/已退票狀態(tài)流轉(zhuǎn)、電子票展示、個(gè)人中心。后臺(tái)部分的核心模塊是登錄鑒權(quán)、Dashboard 統(tǒng)計(jì)卡片、票種管理增刪改查上下架、訂單管理查看/退款、用戶管理、公告管理。這里我特別想強(qiáng)調(diào)一個(gè)容易在設(shè)計(jì)階段被忽略的點(diǎn)票種與日期庫(kù)存的關(guān)系。很多初學(xué)設(shè)計(jì)數(shù)據(jù)庫(kù)時(shí)只做一張 ticket 表存總量結(jié)果用戶選不同日期買票時(shí)庫(kù)存根本沒(méi)法區(qū)分。我實(shí)際的做法是引入“日期庫(kù)存表”每個(gè)票種對(duì)應(yīng)多個(gè)日期的庫(kù)存記錄比如“成人票-2025-06-01-剩余500張”。這樣既能控制單日可售量也為后續(xù)的限流和峰值控制留了余地。2.2 核心數(shù)據(jù)表結(jié)構(gòu)詳解數(shù)據(jù)庫(kù)我總共設(shè)計(jì)了9張表挑核心的幾張說(shuō)一下設(shè)計(jì)思路。第一張是用戶表user。字段包括主鍵 id、手機(jī)號(hào)登錄賬號(hào)、密碼BCrypt 加密存儲(chǔ)、昵稱、頭像、角色標(biāo)識(shí)1-普通用戶 2-管理員、創(chuàng)建時(shí)間。手機(jī)號(hào)作為唯一登錄憑證在表上要加唯一索引。密碼絕對(duì)不能明文存儲(chǔ)這是底線我用 Spring Security 自帶的BCryptPasswordEncoder做哈希。第二張是票種表ticket_type。字段有名稱成人票/兒童票/學(xué)生票/家庭套票、描述、原價(jià)、售價(jià)、票種類型、狀態(tài)0-下架 1-上架、創(chuàng)建時(shí)間。這里有個(gè)細(xì)節(jié)原價(jià)和售價(jià)要分開(kāi)方便后續(xù)做優(yōu)惠活動(dòng)。金額字段用 DECIMAL(10,2)千萬(wàn)不要用 double/float線上環(huán)境因?yàn)楦↑c(diǎn)精度導(dǎo)致對(duì)不上賬的例子太多了。第三張是日期庫(kù)存表ticket_stock。字段有id、票種 id、售賣日期、總庫(kù)存、剩余庫(kù)存、版本號(hào)。這個(gè)表就是防超賣的關(guān)鍵戰(zhàn)場(chǎng)。版本號(hào)字段是為了后續(xù)做樂(lè)觀鎖控制用的雖然我在最終方案里用了 Redis 預(yù)扣為主數(shù)據(jù)庫(kù)還保留了樂(lè)觀鎖作為兜底雙保險(xiǎn)。第四張是訂單表ticket_order。字段有訂單編號(hào)自定義生成規(guī)則、用戶 id、訂單總金額、訂單狀態(tài)0-待支付 1-已支付 2-已取消 3-已退票 4-已完成、支付方式、支付時(shí)間、創(chuàng)建時(shí)間、更新時(shí)間。訂單號(hào)的生成規(guī)則我用了“日期 隨機(jī)數(shù) 用戶ID后四位”示例202506011430221234。不建議直接用數(shù)據(jù)庫(kù)自增 id 當(dāng)訂單號(hào)暴露給用戶容易被爬取和猜測(cè)這個(gè)點(diǎn)面過(guò)幾個(gè)面試官都問(wèn)過(guò)。第五張是訂單明細(xì)表order_item。因?yàn)橐粋€(gè)訂單可能包含多種票一張家庭套票 兩張成人票訂單明細(xì)用來(lái)記錄每種票的數(shù)量、單價(jià)、小計(jì)金額。主表存總金額明細(xì)表存分項(xiàng)這是標(biāo)準(zhǔn)的 1:N 設(shè)計(jì)不要偷懶只建一張訂單表。最后還有公告表、輪播圖表、退款記錄表邏輯相對(duì)直接不展開(kāi)細(xì)說(shuō)。2.3 訂單狀態(tài)機(jī)與關(guān)鍵字段設(shè)計(jì)狀態(tài)機(jī)是這個(gè)系統(tǒng)里最值得細(xì)說(shuō)的地方。訂單狀態(tài)我定義了五個(gè)0-待支付、1-已支付、2-已取消、3-已退票、4-已完成。它們之間的流轉(zhuǎn)關(guān)系是待支付可以到已支付用戶付款也可以到已取消用戶主動(dòng)取消或超時(shí)未付已支付可以到已退票用戶申請(qǐng)退款也可以到已完成入園核銷后自動(dòng)流轉(zhuǎn)已退票和已完成都是終態(tài)不能再做任何操作。這個(gè)狀態(tài)機(jī)定義清楚后所有的接口邏輯都圍繞它轉(zhuǎn)。比如用戶端“取消訂單”接口第一件事就是判斷當(dāng)前狀態(tài)是否為 0如果不是直接拒絕。又比如管理員“退款”接口只處理狀態(tài)為 1 的訂單。這樣看起來(lái)是代碼里幾行 if 判斷但設(shè)計(jì)階段沒(méi)想清楚后期就會(huì)陷入各種狀態(tài)錯(cuò)亂的 bug 泥潭。我還在訂單表里加了一個(gè)out_trade_no字段專門存第三方支付流水號(hào)。雖然模擬支付用不上但這是給未來(lái)對(duì)接真實(shí)支付留的擴(kuò)展位。做設(shè)計(jì)時(shí)預(yù)留這類字段是很好的習(xí)慣答辯加分項(xiàng)往往就在這些細(xì)節(jié)上。3. 核心業(yè)務(wù)實(shí)現(xiàn)與實(shí)操細(xì)節(jié)3.1 購(gòu)票流程與庫(kù)存防超賣方案購(gòu)票是整個(gè)系統(tǒng)最核心的鏈路。我把它拆成四個(gè)步驟參數(shù)校驗(yàn) → 庫(kù)存預(yù)扣 → 創(chuàng)建訂單 → 超時(shí)自動(dòng)釋放。前端頁(yè)面點(diǎn)擊“提交訂單”后后端接口按這個(gè)流程處理。參數(shù)校驗(yàn)階段除了判斷用戶是否登錄、票種是否存在、數(shù)量是否為正整數(shù)這些常規(guī)校驗(yàn)我還加了一個(gè)“售賣日期必須大于今天”的判斷防止用戶補(bǔ)買昨天的票。另外要校驗(yàn)單筆訂單最大購(gòu)買數(shù)量我限制為每個(gè)票種最多 5 張防止惡意刷單。庫(kù)存預(yù)扣是我重點(diǎn)處理的部分。方案是這樣先把票種信息和目標(biāo)日期的庫(kù)存量緩存到 Rediskey 設(shè)計(jì)為stock:ticket:{ticketId}:{date}value 存剩余數(shù)量。用戶提交訂單時(shí)用一段 Lua 腳本原子執(zhí)行“檢查剩余量大于等于購(gòu)買量 → 扣減剩余量 → 返回成功”否則返回庫(kù)存不足。為什么用 Lua 腳本因?yàn)?Redis 單線程執(zhí)行Lua 腳本能保證判斷和扣減這兩步的原子性避免并發(fā)情況下兩個(gè)請(qǐng)求同時(shí)讀到剩余量 1然后都買成功導(dǎo)致超賣。庫(kù)存預(yù)扣成功后才創(chuàng)建訂單記錄狀態(tài)置為待支付。這里有一個(gè)關(guān)鍵細(xì)節(jié)預(yù)扣的庫(kù)存并不會(huì)立即從數(shù)據(jù)庫(kù)的ticket_stock表扣減而是通過(guò)一個(gè)定時(shí)任務(wù)每隔 5 分鐘掃描待支付訂單如果超過(guò) 15 分鐘未支付就自動(dòng)取消同時(shí)恢復(fù) Redis 庫(kù)存來(lái)兜底。為什么用延遲釋放而不是立即釋放因?yàn)橛脩艨赡茉谥Ц俄?yè)停留如果提前釋放庫(kù)存別人把票搶走了用戶支付成功卻沒(méi)票這體驗(yàn)太差了。而 15 分鐘不支付基本可以斷定用戶已經(jīng)放棄。數(shù)據(jù)庫(kù)表的剩余庫(kù)存字段只在訂單支付成功后才真正扣減。也就是說(shuō)Redis 庫(kù)存負(fù)責(zé)“并發(fā)攔截”數(shù)據(jù)庫(kù)庫(kù)存負(fù)責(zé)“最終一致性”。等技術(shù)能力再?gòu)?qiáng)一點(diǎn)你可以用消息隊(duì)列把扣減動(dòng)作異步化但在這個(gè)項(xiàng)目體量下定時(shí)任務(wù)足夠。核心 Lua 腳本我貼出來(lái)這個(gè)腳本我調(diào)試過(guò)很多次-- KEYS[1] stock:ticket:{ticketId}:{date} -- ARGV[1] 購(gòu)買數(shù)量 local remain tonumber(redis.call(GET, KEYS[1])) local buyNum tonumber(ARGV[1]) if remain and remain buyNum then redis.call(DECRBY, KEYS[1], buyNum) return 1 else return 0 end對(duì)應(yīng)的 Java 調(diào)用側(cè)要注意執(zhí)行完 Lua 腳本返回 1 才繼續(xù)創(chuàng)建訂單返回 0 直接拋業(yè)務(wù)異?！皫?kù)存不足”。另外 Redis 的 key 要設(shè)置過(guò)期時(shí)間比如票種下架或售賣日期過(guò)后可以讓它自動(dòng)淘汰避免臟數(shù)據(jù)長(zhǎng)期占用內(nèi)存。3.2 訂單生成與超時(shí)自動(dòng)關(guān)閉訂單創(chuàng)建時(shí)幾個(gè)字段要特別處理。訂單編號(hào)我用了自定義生成器規(guī)則是yyyyMMddHHmmss 4位隨機(jī)數(shù) 用戶ID后四位。UUID 雖然簡(jiǎn)單但很長(zhǎng)且無(wú)序索引效率差純自增 id 又太容易暴露業(yè)務(wù)量。我的這個(gè)規(guī)則在演示效果和查詢性能之間比較均衡。創(chuàng)建訂單的接口我加了Transactional事務(wù)注解保證訂單主表和明細(xì)表要么一起成功要么一起回滾。有人可能疑惑Redis 庫(kù)存已經(jīng)扣了數(shù)據(jù)庫(kù)事務(wù)失敗怎么辦我的處理是在事務(wù)失敗時(shí)手動(dòng)調(diào)用一個(gè)releaseRedisStock()方法把預(yù)扣的庫(kù)存加回去。這一步不能依賴 Redis 的自動(dòng)過(guò)期因?yàn)?15 分鐘太久用戶立刻重試時(shí)會(huì)看到庫(kù)存被“吞了”。超時(shí)關(guān)閉訂單的定時(shí)任務(wù)我用 Spring 自帶的Scheduled實(shí)現(xiàn)固定間隔 30 秒執(zhí)行一次。任務(wù)邏輯是查詢狀態(tài)為待支付且創(chuàng)建時(shí)間小于當(dāng)前時(shí)間 15 分鐘的訂單列表逐單關(guān)閉并恢復(fù) Redis 庫(kù)存。這里我踩過(guò)一個(gè)坑千萬(wàn)不能用SELECT * FROM ticket_order WHERE create_time DATE_SUB(NOW(), INTERVAL 15 MINUTE)一次性查出所有訂單然后 for 循環(huán)處理。如果訂單量大長(zhǎng)事務(wù)會(huì)把表鎖住。正確做法是分頁(yè)查詢每批 100 條處理完再查下一批。這個(gè)習(xí)慣在大數(shù)據(jù)量下會(huì)救你一命。Scheduled(fixedDelay 30000) public void autoCloseExpiredOrders() { // 分頁(yè)查詢待支付且超時(shí)的訂單 PageOrder page orderMapper.selectExpiredOrders(new Page(1, 100), 15); while (page.getRecords().size() 0) { for (Order order : page.getRecords()) { // 關(guān)閉訂單恢復(fù)Redis庫(kù)存 closeOrder(order); } // 繼續(xù)查下一頁(yè) page orderMapper.selectExpiredOrders(new Page(page.getCurrent() 1, 100), 15); } }定時(shí)任務(wù)里還要注意并發(fā)執(zhí)行問(wèn)題。Scheduled默認(rèn)單線程執(zhí)行但如果任務(wù)執(zhí)行時(shí)間超過(guò)間隔會(huì)出現(xiàn)任務(wù)堆積。我建議在方法上加一個(gè)Lock如果是用 ShedLock 的話或者用一個(gè)簡(jiǎn)單的AtomicBoolean標(biāo)志位防止重入。項(xiàng)目里我用的是標(biāo)志位方案夠用。3.3 電子票生成與核銷流程支付成功后系統(tǒng)要給用戶生成電子票。我用的是二維碼技術(shù)集成 ZXing 庫(kù)生成二維碼圖片內(nèi)容是一串加密后的憑證串。憑證串包含訂單號(hào)、票種ID、入園日期、用戶ID后四位我用 AES 對(duì)稱加密再拼接防止有人偽造二維碼。核銷場(chǎng)景是這樣的游客到了動(dòng)物園入口打開(kāi)公眾號(hào)或 App 里的“我的電子票”出示二維碼工作人員用后臺(tái)的“檢票核銷”功能掃碼。掃碼后后端解析密文校驗(yàn)訂單狀態(tài)為已支付、入園日期與當(dāng)日匹配、核銷狀態(tài)為未使用滿足條件就更新?tīng)顟B(tài)為已完成。這個(gè)流程里我特別提醒一個(gè)問(wèn)題二維碼內(nèi)容不要直接放明文訂單號(hào)否則有人可以通過(guò)遍歷訂單號(hào)生成二維碼逃票。AES 加密雖然談不上絕對(duì)安全但在這種應(yīng)用場(chǎng)景里足以擋住大部分低級(jí)攻擊。密鑰別寫(xiě)在代碼里放到application.yml的外部配置或者環(huán)境變量里項(xiàng)目文檔里也要注明。核銷接口必須是冪等的。如果游客的二維碼被掃了兩次第一次成功第二次要返回“該憑證已核銷”不能報(bào)系統(tǒng)異常。同時(shí)核銷操作要加鎖防止同一張票同時(shí)被兩個(gè)入口的機(jī)器掃碼導(dǎo)致并發(fā)更新。MySQL 行鎖用SELECT ... FOR UPDATE或者用 Redis分布式鎖都可以我這里用的是樂(lè)觀鎖更新時(shí)帶上核銷狀態(tài)條件影響行數(shù)為 0 說(shuō)明已被核銷。3.4 接口設(shè)計(jì)與統(tǒng)一返回規(guī)范接口設(shè)計(jì)我走的是 RESTful 風(fēng)格但也沒(méi)有嚴(yán)格到教條的程度。比如“購(gòu)票”這個(gè)動(dòng)作用POST /api/ticket/order來(lái)創(chuàng)建訂單“取消訂單”用PUT /api/ticket/order/{orderNo}/cancel來(lái)表示狀態(tài)變更。這樣接口的語(yǔ)義清晰前端對(duì)接時(shí)也容易理解。所有接口的返回格式統(tǒng)一為{ code: 200, message: success, data: {} }code 為 200 表示業(yè)務(wù)成功其他為業(yè)務(wù)錯(cuò)誤碼比如 40001 表示庫(kù)存不足40002 表示訂單狀態(tài)異常40003 表示參數(shù)校驗(yàn)失敗。我建議錯(cuò)誤碼分段規(guī)劃4xxxx 是前端傳參問(wèn)題5xxxx 是服務(wù)端處理問(wèn)題這樣通過(guò)錯(cuò)誤碼就能快速定位責(zé)任方。統(tǒng)一返回格式我用一個(gè)ResultT泛型類實(shí)現(xiàn)配合全局異常處理器RestControllerAdvice。業(yè)務(wù)異常類BizException里直接攜帶錯(cuò)誤碼和描述控制器代碼里只需要throw new BizException(ErrorCode.STOCK_NOT_ENOUGH)異常處理器統(tǒng)一捕獲并包裝返回。這個(gè)模式也是實(shí)際生產(chǎn)項(xiàng)目里的標(biāo)準(zhǔn)做法值得從課設(shè)階段就開(kāi)始養(yǎng)成。另外接口層要加參數(shù)校驗(yàn)JSR 303 的Valid注解用起來(lái)。請(qǐng)求 DTO 里對(duì)數(shù)量字段加Min(1)、對(duì)日期字段加NotBlank。不要把這些校驗(yàn)依賴前端前端校驗(yàn)只是用戶體驗(yàn)后端校驗(yàn)才是安全底線。4. 前端頁(yè)面與接口對(duì)接4.1 前端技術(shù)棧與頁(yè)面路由結(jié)構(gòu)前端我選了 Vue 2 Element UI如果是新學(xué)建議直接上 Vue 3 Element Plus原理類似。通過(guò) Axios 請(qǐng)求后端接口路由用 Vue Router狀態(tài)管理用 Vuex。為了演示方便我用vue-cli搭的工程開(kāi)發(fā)時(shí)通過(guò)proxy配置把/api前綴的請(qǐng)求代理到后端 8080 端口避免跨域開(kāi)發(fā)問(wèn)題。頁(yè)面路由按用戶側(cè)和管理側(cè)拆分。用戶側(cè)頁(yè)面包括首頁(yè)、票種列表、購(gòu)票確認(rèn)、訂單列表、訂單詳情、電子票、個(gè)人中心、登錄注冊(cè)。管理側(cè)頁(yè)面包括Dashboard、票種管理、訂單管理、用戶管理、公告管理、數(shù)據(jù)統(tǒng)計(jì)。整套頁(yè)面數(shù)量在 15 個(gè)左右工作量適中但覆蓋面足夠用來(lái)演示前后端分離開(kāi)發(fā)的能力。4.2 購(gòu)票頁(yè)面的關(guān)鍵交互邏輯購(gòu)票確認(rèn)頁(yè)是最核心的交互頁(yè)面。它要完成加載票種列表 → 用戶選擇日期日期選擇控件禁用今天之前的日期→ 選擇數(shù)量 → 實(shí)時(shí)計(jì)算總價(jià) → 提交訂單?？們r(jià)計(jì)算我做了前端實(shí)時(shí)計(jì)算展示但后端接口會(huì)重新計(jì)算一遍以后端為準(zhǔn)。不要信任前端傳過(guò)來(lái)的金額這是防篡改的基本常識(shí)。前端傳參只傳票種ID、日期、數(shù)量金額由后端查表計(jì)算得出。訂單支付頁(yè)的邏輯也值得一提。用戶點(diǎn)擊“確認(rèn)支付”后前端調(diào)用支付接口后端在模擬支付模式下直接返回成功并將訂單狀態(tài)從待支付更新為已支付同時(shí)生成電子票。真實(shí)接入支付時(shí)這個(gè)接口會(huì)變成“調(diào)用支付平臺(tái)下單返回支付參數(shù)”前端跳轉(zhuǎn)收銀臺(tái)支付結(jié)果通過(guò)回調(diào)通知。我把PaymentService接口定義好分別實(shí)現(xiàn)了MockPaymentServiceImpl和預(yù)留的RealPaymentServiceImpl這塊設(shè)計(jì)在答辯時(shí)講出來(lái)會(huì)顯得專業(yè)。前端還有一個(gè)細(xì)節(jié)用戶從購(gòu)物車一樣的購(gòu)票頁(yè)跳到訂單確認(rèn)頁(yè)時(shí)后端返回的訂單號(hào)需要保存到 Vuex這樣支付成功后的電子票頁(yè)面才能查到屬于當(dāng)前用戶的電子票憑證。我見(jiàn)過(guò)不少同學(xué)把訂單號(hào)放在 URL query 里刷新頁(yè)面就丟了體驗(yàn)比較糟糕。4.3 管理后臺(tái)的統(tǒng)計(jì)報(bào)表實(shí)現(xiàn)Dashboard 統(tǒng)計(jì)頁(yè)面需要展示三個(gè)核心指標(biāo)今日銷售額、今日訂單數(shù)、本月售票總量。數(shù)據(jù)來(lái)源是訂單表按時(shí)間維度做聚合統(tǒng)計(jì)我用 MyBatis Plus 的selectMaps方法寫(xiě)聚合 SQL返回ListMapString, Object前端用 ECharts 渲染柱狀圖和餅圖。這里有個(gè)性能優(yōu)化點(diǎn)統(tǒng)計(jì)接口每次實(shí)時(shí)查庫(kù)如果訂單量大了會(huì)很慢。我的處理是第一次查詢后把結(jié)果緩存到 Redis設(shè)置 60 秒過(guò)期相當(dāng)于容忍 1 分鐘內(nèi)的數(shù)據(jù)延遲。對(duì)于園區(qū)這種體量的業(yè)務(wù)這個(gè)延遲完全可接受。前端每 30 秒自動(dòng)刷一次配合緩存生效時(shí)間體驗(yàn)和性能之間取得平衡。5. 常見(jiàn)問(wèn)題與排查心得5.1 庫(kù)存超賣問(wèn)題排查實(shí)錄我測(cè)試時(shí)故意用 JMeter 開(kāi) 200 個(gè)線程同時(shí)買同一個(gè)票種的最后一張票第一次測(cè)試就翻車了——賣出了 7 張。排查過(guò)程很有意思雖然最后定位到原因很簡(jiǎn)單但把排查思路寫(xiě)下來(lái)對(duì)大家有參考價(jià)值。首先檢查數(shù)據(jù)庫(kù)庫(kù)存表發(fā)現(xiàn)剩余庫(kù)存變成了負(fù)數(shù)。再翻日志發(fā)現(xiàn)Redis 里的庫(kù)存量其實(shí)扣減是正確的問(wèn)題出在訂單支付成功后的“數(shù)據(jù)庫(kù)扣減”環(huán)節(jié)。我用的是先查庫(kù)存再更新庫(kù)存的代碼Stock stock stockMapper.selectByTicketIdAndDate(...); if (stock.getRemain() 0) { stock.setRemain(stock.getRemain() - 1); stockMapper.updateById(stock); }這種“讀改寫(xiě)”模式下多線程同時(shí)讀到剩余 1條件都成立都執(zhí)行了更新就超賣了。修復(fù)方式是直接更新int rows stockMapper.deductStock(ticketId, date, 1); if (rows 0) { throw new BizException(ErrorCode.STOCK_NOT_ENOUGH); }對(duì)應(yīng) SQL 是UPDATE ticket_stock SET remain remain - 1, version version 1 WHERE ticket_id ? AND sell_date ? AND remain 1。通過(guò)數(shù)據(jù)庫(kù)行鎖和受影響的 UPDATE 保證原子性。這也是我在前面提到“樂(lè)觀鎖作為兜底”的原因。5.2 定時(shí)任務(wù)不執(zhí)行或重復(fù)執(zhí)行的坑Scheduled(cron 0 */5 * * * ?)這個(gè)寫(xiě)法在單機(jī)環(huán)境下沒(méi)問(wèn)題但如果未來(lái)系統(tǒng)部署了多實(shí)例每個(gè)實(shí)例都會(huì)執(zhí)行一遍定時(shí)任務(wù)導(dǎo)致重復(fù)處理。課程設(shè)計(jì)階段不會(huì)遇到多實(shí)例部署但我還是在文檔里提了一嘴解決方案用 Redis 的SETNX做一個(gè)簡(jiǎn)單的分布式鎖SET key value NX EX 120獲取到鎖的實(shí)例才執(zhí)行任務(wù)執(zhí)行完刪除鎖或者引入 ShedLock 依賴兩行配置就搞定。另外提醒一個(gè)小坑SpringBoot 的Scheduled默認(rèn)線程池只有一個(gè)線程。如果你在任務(wù)內(nèi)部調(diào)了遠(yuǎn)程接口導(dǎo)致阻塞后續(xù)的任務(wù)全部卡住。我建議在配置類里顯式聲明ThreadPoolTaskScheduler設(shè)置核心線程數(shù)為 5避免一個(gè)慢任務(wù)拖垮其他定時(shí)任務(wù)。5.3 時(shí)間格式化、跨域與配置項(xiàng)小坑時(shí)間格式化這個(gè)問(wèn)題幾乎每次都會(huì)遇到。后端返回LocalDateTime默認(rèn)是2025-06-01T14:30:00這種 ISO 格式前端展示很難看。我在application.yml里統(tǒng)一配置了 Jackson 的格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8跨域問(wèn)題也一樣。前后端分離開(kāi)發(fā)時(shí)前端 8080后端 9527瀏覽器會(huì)攔截跨域請(qǐng)求。我在后端寫(xiě)了一個(gè)CorsConfig配置類允許所有來(lái)源、所有請(qǐng)求方法開(kāi)發(fā)環(huán)境足夠。生產(chǎn)環(huán)境部署建議用 Nginx 反向代理統(tǒng)一入口徹底規(guī)避跨域問(wèn)題同時(shí)也更安全。還有一個(gè)配置項(xiàng)坑SpringBoot 版本差異導(dǎo)致配置不生效。如果你用的 SpringBoot 2.4 以上的版本配置文件里的多環(huán)境配置寫(xiě)法變了spring.profiles.active需要放到application.yml最外層不要再寫(xiě)在spring.profiles下面。類似這些小坑我建議把踩過(guò)的記錄下來(lái)寫(xiě)進(jìn)配套的“遇到的問(wèn)題與解決”文檔中答辯時(shí)是一份很好的加分材料。5.4 配套文檔、PPT與源碼的組織經(jīng)驗(yàn)這個(gè)項(xiàng)目帶了完整的文檔和 PPT這部分經(jīng)驗(yàn)我從來(lái)沒(méi)見(jiàn)別人認(rèn)真整理過(guò)。畢設(shè)/課設(shè)答辯的評(píng)委會(huì)翻文檔但更重要的是他們會(huì)在現(xiàn)場(chǎng)讓你演示系統(tǒng)。所以我的文檔組織邏輯是需求分析用戶故事和功能清單 → 系統(tǒng)設(shè)計(jì)架構(gòu)圖數(shù)據(jù)庫(kù)ER圖接口文檔 → 系統(tǒng)實(shí)現(xiàn)核心代碼走讀 → 測(cè)試報(bào)告功能測(cè)試并發(fā)測(cè)試 → 總結(jié)與展望。PPT 則控制在 15 頁(yè)以內(nèi)核心是講清楚“我做了什么”和“我遇到了什么問(wèn)題怎么解決的”不要堆代碼。源碼組織方面也有講究。后端模塊我按 controller、service、mapper、entity、common、config 分包一個(gè)包干一件事。前端把 api 請(qǐng)求封裝到src/api目錄下頁(yè)面組件在src/views下。整個(gè)代碼層級(jí)清晰別人拿到就能快速跑起來(lái)這是“含源碼”項(xiàng)目最基本的要求——不是把代碼甩出來(lái)就叫含源碼而是要讓接手的人能看明白、能改、能運(yùn)行。最后再分享一個(gè)小技巧整個(gè)系統(tǒng)做下來(lái)我最大的感受是課設(shè)級(jí)別的項(xiàng)目重點(diǎn)不在于技術(shù)多新多全而在于邏輯閉環(huán)。你做一個(gè)售票系統(tǒng)就要保證從注冊(cè)到購(gòu)票到支付到核銷到退票整條鏈路每一個(gè)分支都處理到位。我見(jiàn)過(guò)太多項(xiàng)目演示時(shí)主流程很順暢一展示管理員退款就報(bào)錯(cuò)一展示庫(kù)存不足就白屏——這種硬傷特別致命。我自己的習(xí)慣是交付前花半天時(shí)間把核心業(yè)務(wù)鏈路的每一個(gè)接口用 Postman 過(guò)一遍包括異常場(chǎng)景未登錄訪問(wèn)訂單接口、庫(kù)存為 0 時(shí)下單、重復(fù)核銷、非法參數(shù)請(qǐng)求。把這些異常處理正常了演示再過(guò)不了只能說(shuō)明運(yùn)氣不好。另外記得MySQL 和 Redis 的本地環(huán)境配置、數(shù)據(jù)庫(kù)初始化腳本、Redis 數(shù)據(jù)預(yù)置命令全都要寫(xiě)進(jìn) README。換一臺(tái)電腦就跑不起來(lái)這比你代碼寫(xiě)得漂亮但要花三小時(shí)才能啟動(dòng)要致命得多。 SpringBoot+Redis售票系統(tǒng)防超賣實(shí)戰(zhàn)：訂單狀態(tài)機(jī)與庫(kù)存設(shè)計(jì)
1. 項(xiàng)目背景與方案選型1.1 售票痛點(diǎn)與系統(tǒng)定位做線上動(dòng)物園售票系統(tǒng)之前很多人第一反應(yīng)是“這無(wú)非是個(gè) CRUD 項(xiàng)目”。真上手之后你會(huì)發(fā)現(xiàn)訂單、庫(kù)存、支付狀態(tài)、退票規(guī)則這些點(diǎn)每一個(gè)都能讓你加班到半夜。這個(gè)系統(tǒng)的核心價(jià)值一方面是替游客省去現(xiàn)場(chǎng)排隊(duì)買票的時(shí)間另一方面是幫園區(qū)把票務(wù)數(shù)據(jù)沉淀下來(lái)——銷量統(tǒng)計(jì)、熱門時(shí)段分析、游客畫(huà)像全都得有數(shù)據(jù)支撐才能做。這個(gè)項(xiàng)目我定位為課程設(shè)計(jì)/畢業(yè)設(shè)計(jì)級(jí)別的完整案例不是玩具但也沒(méi)有過(guò)度工程化。它要覆蓋一條完整的購(gòu)票鏈路游客瀏覽票種 → 注冊(cè)登錄 → 選擇日期與數(shù)量 → 創(chuàng)建訂單 → 模擬支付或?qū)诱鎸?shí)支付 → 生成電子票二維碼 → 入園時(shí)掃碼核銷。同時(shí)后臺(tái)需要支持票種管理、訂單管理、用戶管理、公告發(fā)布、數(shù)據(jù)統(tǒng)計(jì)。整個(gè)系統(tǒng)用 SpringBoot 作為后端主框架前端我選了 Vue Element UI數(shù)據(jù)庫(kù)用 MySQL緩存加了一層 Redis。如果你正準(zhǔn)備拿 Java 方向做畢設(shè)或課設(shè)這套組合的覆蓋面足夠廣答辯時(shí)也講得出東西。1.2 技術(shù)選型背后的取舍邏輯SpringBoot 在 Java 生態(tài)中的地位不用多說(shuō)我選它的核心原因是啟動(dòng)快、配置收斂、生態(tài)成熟。你不用像 SSM 時(shí)代那樣寫(xiě)一堆 XML一個(gè)SpringBootApplication就能跑起來(lái)。但這不代表你不需要理解底層——比如 SpringBoot 默認(rèn)整合了 Spring MVC、內(nèi)嵌 Tomcat、自動(dòng)配置機(jī)制你至少要明白spring-boot-starter-web幫你做了什么否則遇到詭異問(wèn)題根本無(wú)從排查。持久層框架我選了 MyBatis Plus而不是原生 MyBatis 或 JPA。原因很簡(jiǎn)單單表 CRUD 要是手寫(xiě) XML效率太低JPA 雖然省事但復(fù)雜查詢和 SQL 調(diào)優(yōu)不直觀。MyBatis Plus 兼顧兩者內(nèi)置的BaseMapper能覆蓋 80% 的簡(jiǎn)單操作復(fù)雜統(tǒng)計(jì)用注解 SQL 或 XML 自己寫(xiě)可控性很強(qiáng)。另外它自帶分頁(yè)插件后臺(tái)列表頁(yè)和訂單查詢都直接受益。Redis 的引入主要是兩件事一是緩存票種信息和公告減少數(shù)據(jù)庫(kù)壓力二是購(gòu)票時(shí)的庫(kù)存預(yù)扣與防超賣處理。這兩個(gè)場(chǎng)景用 Redis 的原子操作非常合適。如果只是純課程設(shè)計(jì)完全不引入 Redis 也能跑但我想讓這個(gè)項(xiàng)目有一點(diǎn)“生產(chǎn)味道”所以把它加了進(jìn)來(lái)。至于支付真實(shí)對(duì)接微信/支付寶需要商戶號(hào)個(gè)人項(xiàng)目拿不到所以我在項(xiàng)目中做了“模擬支付”模塊同時(shí)把支付接口抽象出來(lái)后續(xù)要對(duì)接真實(shí)支付只需替換實(shí)現(xiàn)類。2. 系統(tǒng)模塊與數(shù)據(jù)庫(kù)設(shè)計(jì)2.1 角色權(quán)限與功能模塊拆解整個(gè)系統(tǒng)按角色劃分成三類游客、注冊(cè)用戶、管理員。游客只能瀏覽票種和公告注冊(cè)用戶在前者基礎(chǔ)上增加了購(gòu)票、訂單查詢、退票、個(gè)人信息管理管理員則進(jìn)入后臺(tái)管理票種、訂單、用戶、公告還能看銷售統(tǒng)計(jì)報(bào)表。我畫(huà)模塊圖的時(shí)候習(xí)慣先列角色再列每個(gè)角色能做什么最后落到頁(yè)面和接口上。前臺(tái)部分的核心模塊是首頁(yè)輪播公告、票種列表、購(gòu)票流程選日期/選數(shù)量/創(chuàng)建訂單、訂單中心待支付/已支付/已退票狀態(tài)流轉(zhuǎn)、電子票展示、個(gè)人中心。后臺(tái)部分的核心模塊是登錄鑒權(quán)、Dashboard 統(tǒng)計(jì)卡片、票種管理增刪改查上下架、訂單管理查看/退款、用戶管理、公告管理。這里我特別想強(qiáng)調(diào)一個(gè)容易在設(shè)計(jì)階段被忽略的點(diǎn)票種與日期庫(kù)存的關(guān)系。很多初學(xué)設(shè)計(jì)數(shù)據(jù)庫(kù)時(shí)只做一張 ticket 表存總量結(jié)果用戶選不同日期買票時(shí)庫(kù)存根本沒(méi)法區(qū)分。我實(shí)際的做法是引入“日期庫(kù)存表”每個(gè)票種對(duì)應(yīng)多個(gè)日期的庫(kù)存記錄比如“成人票-2025-06-01-剩余500張”。這樣既能控制單日可售量也為后續(xù)的限流和峰值控制留了余地。2.2 核心數(shù)據(jù)表結(jié)構(gòu)詳解數(shù)據(jù)庫(kù)我總共設(shè)計(jì)了9張表挑核心的幾張說(shuō)一下設(shè)計(jì)思路。第一張是用戶表user。字段包括主鍵 id、手機(jī)號(hào)登錄賬號(hào)、密碼BCrypt 加密存儲(chǔ)、昵稱、頭像、角色標(biāo)識(shí)1-普通用戶 2-管理員、創(chuàng)建時(shí)間。手機(jī)號(hào)作為唯一登錄憑證在表上要加唯一索引。密碼絕對(duì)不能明文存儲(chǔ)這是底線我用 Spring Security 自帶的BCryptPasswordEncoder做哈希。第二張是票種表ticket_type。字段有名稱成人票/兒童票/學(xué)生票/家庭套票、描述、原價(jià)、售價(jià)、票種類型、狀態(tài)0-下架 1-上架、創(chuàng)建時(shí)間。這里有個(gè)細(xì)節(jié)原價(jià)和售價(jià)要分開(kāi)方便后續(xù)做優(yōu)惠活動(dòng)。金額字段用 DECIMAL(10,2)千萬(wàn)不要用 double/float線上環(huán)境因?yàn)楦↑c(diǎn)精度導(dǎo)致對(duì)不上賬的例子太多了。第三張是日期庫(kù)存表ticket_stock。字段有id、票種 id、售賣日期、總庫(kù)存、剩余庫(kù)存、版本號(hào)。這個(gè)表就是防超賣的關(guān)鍵戰(zhàn)場(chǎng)。版本號(hào)字段是為了后續(xù)做樂(lè)觀鎖控制用的雖然我在最終方案里用了 Redis 預(yù)扣為主數(shù)據(jù)庫(kù)還保留了樂(lè)觀鎖作為兜底雙保險(xiǎn)。第四張是訂單表ticket_order。字段有訂單編號(hào)自定義生成規(guī)則、用戶 id、訂單總金額、訂單狀態(tài)0-待支付 1-已支付 2-已取消 3-已退票 4-已完成、支付方式、支付時(shí)間、創(chuàng)建時(shí)間、更新時(shí)間。訂單號(hào)的生成規(guī)則我用了“日期 隨機(jī)數(shù) 用戶ID后四位”示例202506011430221234。不建議直接用數(shù)據(jù)庫(kù)自增 id 當(dāng)訂單號(hào)暴露給用戶容易被爬取和猜測(cè)這個(gè)點(diǎn)面過(guò)幾個(gè)面試官都問(wèn)過(guò)。第五張是訂單明細(xì)表order_item。因?yàn)橐粋€(gè)訂單可能包含多種票一張家庭套票 兩張成人票訂單明細(xì)用來(lái)記錄每種票的數(shù)量、單價(jià)、小計(jì)金額。主表存總金額明細(xì)表存分項(xiàng)這是標(biāo)準(zhǔn)的 1:N 設(shè)計(jì)不要偷懶只建一張訂單表。最后還有公告表、輪播圖表、退款記錄表邏輯相對(duì)直接不展開(kāi)細(xì)說(shuō)。2.3 訂單狀態(tài)機(jī)與關(guān)鍵字段設(shè)計(jì)狀態(tài)機(jī)是這個(gè)系統(tǒng)里最值得細(xì)說(shuō)的地方。訂單狀態(tài)我定義了五個(gè)0-待支付、1-已支付、2-已取消、3-已退票、4-已完成。它們之間的流轉(zhuǎn)關(guān)系是待支付可以到已支付用戶付款也可以到已取消用戶主動(dòng)取消或超時(shí)未付已支付可以到已退票用戶申請(qǐng)退款也可以到已完成入園核銷后自動(dòng)流轉(zhuǎn)已退票和已完成都是終態(tài)不能再做任何操作。這個(gè)狀態(tài)機(jī)定義清楚后所有的接口邏輯都圍繞它轉(zhuǎn)。比如用戶端“取消訂單”接口第一件事就是判斷當(dāng)前狀態(tài)是否為 0如果不是直接拒絕。又比如管理員“退款”接口只處理狀態(tài)為 1 的訂單。這樣看起來(lái)是代碼里幾行 if 判斷但設(shè)計(jì)階段沒(méi)想清楚后期就會(huì)陷入各種狀態(tài)錯(cuò)亂的 bug 泥潭。我還在訂單表里加了一個(gè)out_trade_no字段專門存第三方支付流水號(hào)。雖然模擬支付用不上但這是給未來(lái)對(duì)接真實(shí)支付留的擴(kuò)展位。做設(shè)計(jì)時(shí)預(yù)留這類字段是很好的習(xí)慣答辯加分項(xiàng)往往就在這些細(xì)節(jié)上。3. 核心業(yè)務(wù)實(shí)現(xiàn)與實(shí)操細(xì)節(jié)3.1 購(gòu)票流程與庫(kù)存防超賣方案購(gòu)票是整個(gè)系統(tǒng)最核心的鏈路。我把它拆成四個(gè)步驟參數(shù)校驗(yàn) → 庫(kù)存預(yù)扣 → 創(chuàng)建訂單 → 超時(shí)自動(dòng)釋放。前端頁(yè)面點(diǎn)擊“提交訂單”后后端接口按這個(gè)流程處理。參數(shù)校驗(yàn)階段除了判斷用戶是否登錄、票種是否存在、數(shù)量是否為正整數(shù)這些常規(guī)校驗(yàn)我還加了一個(gè)“售賣日期必須大于今天”的判斷防止用戶補(bǔ)買昨天的票。另外要校驗(yàn)單筆訂單最大購(gòu)買數(shù)量我限制為每個(gè)票種最多 5 張防止惡意刷單。庫(kù)存預(yù)扣是我重點(diǎn)處理的部分。方案是這樣先把票種信息和目標(biāo)日期的庫(kù)存量緩存到 Rediskey 設(shè)計(jì)為stock:ticket:{ticketId}:{date}value 存剩余數(shù)量。用戶提交訂單時(shí)用一段 Lua 腳本原子執(zhí)行“檢查剩余量大于等于購(gòu)買量 → 扣減剩余量 → 返回成功”否則返回庫(kù)存不足。為什么用 Lua 腳本因?yàn)?Redis 單線程執(zhí)行Lua 腳本能保證判斷和扣減這兩步的原子性避免并發(fā)情況下兩個(gè)請(qǐng)求同時(shí)讀到剩余量 1然后都買成功導(dǎo)致超賣。庫(kù)存預(yù)扣成功后才創(chuàng)建訂單記錄狀態(tài)置為待支付。這里有一個(gè)關(guān)鍵細(xì)節(jié)預(yù)扣的庫(kù)存并不會(huì)立即從數(shù)據(jù)庫(kù)的ticket_stock表扣減而是通過(guò)一個(gè)定時(shí)任務(wù)每隔 5 分鐘掃描待支付訂單如果超過(guò) 15 分鐘未支付就自動(dòng)取消同時(shí)恢復(fù) Redis 庫(kù)存來(lái)兜底。為什么用延遲釋放而不是立即釋放因?yàn)橛脩艨赡茉谥Ц俄?yè)停留如果提前釋放庫(kù)存別人把票搶走了用戶支付成功卻沒(méi)票這體驗(yàn)太差了。而 15 分鐘不支付基本可以斷定用戶已經(jīng)放棄。數(shù)據(jù)庫(kù)表的剩余庫(kù)存字段只在訂單支付成功后才真正扣減。也就是說(shuō)Redis 庫(kù)存負(fù)責(zé)“并發(fā)攔截”數(shù)據(jù)庫(kù)庫(kù)存負(fù)責(zé)“最終一致性”。等技術(shù)能力再?gòu)?qiáng)一點(diǎn)你可以用消息隊(duì)列把扣減動(dòng)作異步化但在這個(gè)項(xiàng)目體量下定時(shí)任務(wù)足夠。核心 Lua 腳本我貼出來(lái)這個(gè)腳本我調(diào)試過(guò)很多次-- KEYS[1] stock:ticket:{ticketId}:{date} -- ARGV[1] 購(gòu)買數(shù)量 local remain tonumber(redis.call(GET, KEYS[1])) local buyNum tonumber(ARGV[1]) if remain and remain buyNum then redis.call(DECRBY, KEYS[1], buyNum) return 1 else return 0 end對(duì)應(yīng)的 Java 調(diào)用側(cè)要注意執(zhí)行完 Lua 腳本返回 1 才繼續(xù)創(chuàng)建訂單返回 0 直接拋業(yè)務(wù)異?！皫?kù)存不足”。另外 Redis 的 key 要設(shè)置過(guò)期時(shí)間比如票種下架或售賣日期過(guò)后可以讓它自動(dòng)淘汰避免臟數(shù)據(jù)長(zhǎng)期占用內(nèi)存。3.2 訂單生成與超時(shí)自動(dòng)關(guān)閉訂單創(chuàng)建時(shí)幾個(gè)字段要特別處理。訂單編號(hào)我用了自定義生成器規(guī)則是yyyyMMddHHmmss 4位隨機(jī)數(shù) 用戶ID后四位。UUID 雖然簡(jiǎn)單但很長(zhǎng)且無(wú)序索引效率差純自增 id 又太容易暴露業(yè)務(wù)量。我的這個(gè)規(guī)則在演示效果和查詢性能之間比較均衡。創(chuàng)建訂單的接口我加了Transactional事務(wù)注解保證訂單主表和明細(xì)表要么一起成功要么一起回滾。有人可能疑惑Redis 庫(kù)存已經(jīng)扣了數(shù)據(jù)庫(kù)事務(wù)失敗怎么辦我的處理是在事務(wù)失敗時(shí)手動(dòng)調(diào)用一個(gè)releaseRedisStock()方法把預(yù)扣的庫(kù)存加回去。這一步不能依賴 Redis 的自動(dòng)過(guò)期因?yàn)?15 分鐘太久用戶立刻重試時(shí)會(huì)看到庫(kù)存被“吞了”。超時(shí)關(guān)閉訂單的定時(shí)任務(wù)我用 Spring 自帶的Scheduled實(shí)現(xiàn)固定間隔 30 秒執(zhí)行一次。任務(wù)邏輯是查詢狀態(tài)為待支付且創(chuàng)建時(shí)間小于當(dāng)前時(shí)間 15 分鐘的訂單列表逐單關(guān)閉并恢復(fù) Redis 庫(kù)存。這里我踩過(guò)一個(gè)坑千萬(wàn)不能用SELECT * FROM ticket_order WHERE create_time DATE_SUB(NOW(), INTERVAL 15 MINUTE)一次性查出所有訂單然后 for 循環(huán)處理。如果訂單量大長(zhǎng)事務(wù)會(huì)把表鎖住。正確做法是分頁(yè)查詢每批 100 條處理完再查下一批。這個(gè)習(xí)慣在大數(shù)據(jù)量下會(huì)救你一命。Scheduled(fixedDelay 30000) public void autoCloseExpiredOrders() { // 分頁(yè)查詢待支付且超時(shí)的訂單 PageOrder page orderMapper.selectExpiredOrders(new Page(1, 100), 15); while (page.getRecords().size() 0) { for (Order order : page.getRecords()) { // 關(guān)閉訂單恢復(fù)Redis庫(kù)存 closeOrder(order); } // 繼續(xù)查下一頁(yè) page orderMapper.selectExpiredOrders(new Page(page.getCurrent() 1, 100), 15); } }定時(shí)任務(wù)里還要注意并發(fā)執(zhí)行問(wèn)題。Scheduled默認(rèn)單線程執(zhí)行但如果任務(wù)執(zhí)行時(shí)間超過(guò)間隔會(huì)出現(xiàn)任務(wù)堆積。我建議在方法上加一個(gè)Lock如果是用 ShedLock 的話或者用一個(gè)簡(jiǎn)單的AtomicBoolean標(biāo)志位防止重入。項(xiàng)目里我用的是標(biāo)志位方案夠用。3.3 電子票生成與核銷流程支付成功后系統(tǒng)要給用戶生成電子票。我用的是二維碼技術(shù)集成 ZXing 庫(kù)生成二維碼圖片內(nèi)容是一串加密后的憑證串。憑證串包含訂單號(hào)、票種ID、入園日期、用戶ID后四位我用 AES 對(duì)稱加密再拼接防止有人偽造二維碼。核銷場(chǎng)景是這樣的游客到了動(dòng)物園入口打開(kāi)公眾號(hào)或 App 里的“我的電子票”出示二維碼工作人員用后臺(tái)的“檢票核銷”功能掃碼。掃碼后后端解析密文校驗(yàn)訂單狀態(tài)為已支付、入園日期與當(dāng)日匹配、核銷狀態(tài)為未使用滿足條件就更新?tīng)顟B(tài)為已完成。這個(gè)流程里我特別提醒一個(gè)問(wèn)題二維碼內(nèi)容不要直接放明文訂單號(hào)否則有人可以通過(guò)遍歷訂單號(hào)生成二維碼逃票。AES 加密雖然談不上絕對(duì)安全但在這種應(yīng)用場(chǎng)景里足以擋住大部分低級(jí)攻擊。密鑰別寫(xiě)在代碼里放到application.yml的外部配置或者環(huán)境變量里項(xiàng)目文檔里也要注明。核銷接口必須是冪等的。如果游客的二維碼被掃了兩次第一次成功第二次要返回“該憑證已核銷”不能報(bào)系統(tǒng)異常。同時(shí)核銷操作要加鎖防止同一張票同時(shí)被兩個(gè)入口的機(jī)器掃碼導(dǎo)致并發(fā)更新。MySQL 行鎖用SELECT ... FOR UPDATE或者用 Redis分布式鎖都可以我這里用的是樂(lè)觀鎖更新時(shí)帶上核銷狀態(tài)條件影響行數(shù)為 0 說(shuō)明已被核銷。3.4 接口設(shè)計(jì)與統(tǒng)一返回規(guī)范接口設(shè)計(jì)我走的是 RESTful 風(fēng)格但也沒(méi)有嚴(yán)格到教條的程度。比如“購(gòu)票”這個(gè)動(dòng)作用POST /api/ticket/order來(lái)創(chuàng)建訂單“取消訂單”用PUT /api/ticket/order/{orderNo}/cancel來(lái)表示狀態(tài)變更。這樣接口的語(yǔ)義清晰前端對(duì)接時(shí)也容易理解。所有接口的返回格式統(tǒng)一為{ code: 200, message: success, data: {} }code 為 200 表示業(yè)務(wù)成功其他為業(yè)務(wù)錯(cuò)誤碼比如 40001 表示庫(kù)存不足40002 表示訂單狀態(tài)異常40003 表示參數(shù)校驗(yàn)失敗。我建議錯(cuò)誤碼分段規(guī)劃4xxxx 是前端傳參問(wèn)題5xxxx 是服務(wù)端處理問(wèn)題這樣通過(guò)錯(cuò)誤碼就能快速定位責(zé)任方。統(tǒng)一返回格式我用一個(gè)ResultT泛型類實(shí)現(xiàn)配合全局異常處理器RestControllerAdvice。業(yè)務(wù)異常類BizException里直接攜帶錯(cuò)誤碼和描述控制器代碼里只需要throw new BizException(ErrorCode.STOCK_NOT_ENOUGH)異常處理器統(tǒng)一捕獲并包裝返回。這個(gè)模式也是實(shí)際生產(chǎn)項(xiàng)目里的標(biāo)準(zhǔn)做法值得從課設(shè)階段就開(kāi)始養(yǎng)成。另外接口層要加參數(shù)校驗(yàn)JSR 303 的Valid注解用起來(lái)。請(qǐng)求 DTO 里對(duì)數(shù)量字段加Min(1)、對(duì)日期字段加NotBlank。不要把這些校驗(yàn)依賴前端前端校驗(yàn)只是用戶體驗(yàn)后端校驗(yàn)才是安全底線。4. 前端頁(yè)面與接口對(duì)接4.1 前端技術(shù)棧與頁(yè)面路由結(jié)構(gòu)前端我選了 Vue 2 Element UI如果是新學(xué)建議直接上 Vue 3 Element Plus原理類似。通過(guò) Axios 請(qǐng)求后端接口路由用 Vue Router狀態(tài)管理用 Vuex。為了演示方便我用vue-cli搭的工程開(kāi)發(fā)時(shí)通過(guò)proxy配置把/api前綴的請(qǐng)求代理到后端 8080 端口避免跨域開(kāi)發(fā)問(wèn)題。頁(yè)面路由按用戶側(cè)和管理側(cè)拆分。用戶側(cè)頁(yè)面包括首頁(yè)、票種列表、購(gòu)票確認(rèn)、訂單列表、訂單詳情、電子票、個(gè)人中心、登錄注冊(cè)。管理側(cè)頁(yè)面包括Dashboard、票種管理、訂單管理、用戶管理、公告管理、數(shù)據(jù)統(tǒng)計(jì)。整套頁(yè)面數(shù)量在 15 個(gè)左右工作量適中但覆蓋面足夠用來(lái)演示前后端分離開(kāi)發(fā)的能力。4.2 購(gòu)票頁(yè)面的關(guān)鍵交互邏輯購(gòu)票確認(rèn)頁(yè)是最核心的交互頁(yè)面。它要完成加載票種列表 → 用戶選擇日期日期選擇控件禁用今天之前的日期→ 選擇數(shù)量 → 實(shí)時(shí)計(jì)算總價(jià) → 提交訂單?？們r(jià)計(jì)算我做了前端實(shí)時(shí)計(jì)算展示但后端接口會(huì)重新計(jì)算一遍以后端為準(zhǔn)。不要信任前端傳過(guò)來(lái)的金額這是防篡改的基本常識(shí)。前端傳參只傳票種ID、日期、數(shù)量金額由后端查表計(jì)算得出。訂單支付頁(yè)的邏輯也值得一提。用戶點(diǎn)擊“確認(rèn)支付”后前端調(diào)用支付接口后端在模擬支付模式下直接返回成功并將訂單狀態(tài)從待支付更新為已支付同時(shí)生成電子票。真實(shí)接入支付時(shí)這個(gè)接口會(huì)變成“調(diào)用支付平臺(tái)下單返回支付參數(shù)”前端跳轉(zhuǎn)收銀臺(tái)支付結(jié)果通過(guò)回調(diào)通知。我把PaymentService接口定義好分別實(shí)現(xiàn)了MockPaymentServiceImpl和預(yù)留的RealPaymentServiceImpl這塊設(shè)計(jì)在答辯時(shí)講出來(lái)會(huì)顯得專業(yè)。前端還有一個(gè)細(xì)節(jié)用戶從購(gòu)物車一樣的購(gòu)票頁(yè)跳到訂單確認(rèn)頁(yè)時(shí)后端返回的訂單號(hào)需要保存到 Vuex這樣支付成功后的電子票頁(yè)面才能查到屬于當(dāng)前用戶的電子票憑證。我見(jiàn)過(guò)不少同學(xué)把訂單號(hào)放在 URL query 里刷新頁(yè)面就丟了體驗(yàn)比較糟糕。4.3 管理后臺(tái)的統(tǒng)計(jì)報(bào)表實(shí)現(xiàn)Dashboard 統(tǒng)計(jì)頁(yè)面需要展示三個(gè)核心指標(biāo)今日銷售額、今日訂單數(shù)、本月售票總量。數(shù)據(jù)來(lái)源是訂單表按時(shí)間維度做聚合統(tǒng)計(jì)我用 MyBatis Plus 的selectMaps方法寫(xiě)聚合 SQL返回ListMapString, Object前端用 ECharts 渲染柱狀圖和餅圖。這里有個(gè)性能優(yōu)化點(diǎn)統(tǒng)計(jì)接口每次實(shí)時(shí)查庫(kù)如果訂單量大了會(huì)很慢。我的處理是第一次查詢后把結(jié)果緩存到 Redis設(shè)置 60 秒過(guò)期相當(dāng)于容忍 1 分鐘內(nèi)的數(shù)據(jù)延遲。對(duì)于園區(qū)這種體量的業(yè)務(wù)這個(gè)延遲完全可接受。前端每 30 秒自動(dòng)刷一次配合緩存生效時(shí)間體驗(yàn)和性能之間取得平衡。5. 常見(jiàn)問(wèn)題與排查心得5.1 庫(kù)存超賣問(wèn)題排查實(shí)錄我測(cè)試時(shí)故意用 JMeter 開(kāi) 200 個(gè)線程同時(shí)買同一個(gè)票種的最后一張票第一次測(cè)試就翻車了——賣出了 7 張。排查過(guò)程很有意思雖然最后定位到原因很簡(jiǎn)單但把排查思路寫(xiě)下來(lái)對(duì)大家有參考價(jià)值。首先檢查數(shù)據(jù)庫(kù)庫(kù)存表發(fā)現(xiàn)剩余庫(kù)存變成了負(fù)數(shù)。再翻日志發(fā)現(xiàn)Redis 里的庫(kù)存量其實(shí)扣減是正確的問(wèn)題出在訂單支付成功后的“數(shù)據(jù)庫(kù)扣減”環(huán)節(jié)。我用的是先查庫(kù)存再更新庫(kù)存的代碼Stock stock stockMapper.selectByTicketIdAndDate(...); if (stock.getRemain() 0) { stock.setRemain(stock.getRemain() - 1); stockMapper.updateById(stock); }這種“讀改寫(xiě)”模式下多線程同時(shí)讀到剩余 1條件都成立都執(zhí)行了更新就超賣了。修復(fù)方式是直接更新int rows stockMapper.deductStock(ticketId, date, 1); if (rows 0) { throw new BizException(ErrorCode.STOCK_NOT_ENOUGH); }對(duì)應(yīng) SQL 是UPDATE ticket_stock SET remain remain - 1, version version 1 WHERE ticket_id ? AND sell_date ? AND remain 1。通過(guò)數(shù)據(jù)庫(kù)行鎖和受影響的 UPDATE 保證原子性。這也是我在前面提到“樂(lè)觀鎖作為兜底”的原因。5.2 定時(shí)任務(wù)不執(zhí)行或重復(fù)執(zhí)行的坑Scheduled(cron 0 */5 * * * ?)這個(gè)寫(xiě)法在單機(jī)環(huán)境下沒(méi)問(wèn)題但如果未來(lái)系統(tǒng)部署了多實(shí)例每個(gè)實(shí)例都會(huì)執(zhí)行一遍定時(shí)任務(wù)導(dǎo)致重復(fù)處理。課程設(shè)計(jì)階段不會(huì)遇到多實(shí)例部署但我還是在文檔里提了一嘴解決方案用 Redis 的SETNX做一個(gè)簡(jiǎn)單的分布式鎖SET key value NX EX 120獲取到鎖的實(shí)例才執(zhí)行任務(wù)執(zhí)行完刪除鎖或者引入 ShedLock 依賴兩行配置就搞定。另外提醒一個(gè)小坑SpringBoot 的Scheduled默認(rèn)線程池只有一個(gè)線程。如果你在任務(wù)內(nèi)部調(diào)了遠(yuǎn)程接口導(dǎo)致阻塞后續(xù)的任務(wù)全部卡住。我建議在配置類里顯式聲明ThreadPoolTaskScheduler設(shè)置核心線程數(shù)為 5避免一個(gè)慢任務(wù)拖垮其他定時(shí)任務(wù)。5.3 時(shí)間格式化、跨域與配置項(xiàng)小坑時(shí)間格式化這個(gè)問(wèn)題幾乎每次都會(huì)遇到。后端返回LocalDateTime默認(rèn)是2025-06-01T14:30:00這種 ISO 格式前端展示很難看。我在application.yml里統(tǒng)一配置了 Jackson 的格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8跨域問(wèn)題也一樣。前后端分離開(kāi)發(fā)時(shí)前端 8080后端 9527瀏覽器會(huì)攔截跨域請(qǐng)求。我在后端寫(xiě)了一個(gè)CorsConfig配置類允許所有來(lái)源、所有請(qǐng)求方法開(kāi)發(fā)環(huán)境足夠。生產(chǎn)環(huán)境部署建議用 Nginx 反向代理統(tǒng)一入口徹底規(guī)避跨域問(wèn)題同時(shí)也更安全。還有一個(gè)配置項(xiàng)坑SpringBoot 版本差異導(dǎo)致配置不生效。如果你用的 SpringBoot 2.4 以上的版本配置文件里的多環(huán)境配置寫(xiě)法變了spring.profiles.active需要放到application.yml最外層不要再寫(xiě)在spring.profiles下面。類似這些小坑我建議把踩過(guò)的記錄下來(lái)寫(xiě)進(jìn)配套的“遇到的問(wèn)題與解決”文檔中答辯時(shí)是一份很好的加分材料。5.4 配套文檔、PPT與源碼的組織經(jīng)驗(yàn)這個(gè)項(xiàng)目帶了完整的文檔和 PPT這部分經(jīng)驗(yàn)我從來(lái)沒(méi)見(jiàn)別人認(rèn)真整理過(guò)。畢設(shè)/課設(shè)答辯的評(píng)委會(huì)翻文檔但更重要的是他們會(huì)在現(xiàn)場(chǎng)讓你演示系統(tǒng)。所以我的文檔組織邏輯是需求分析用戶故事和功能清單 → 系統(tǒng)設(shè)計(jì)架構(gòu)圖數(shù)據(jù)庫(kù)ER圖接口文檔 → 系統(tǒng)實(shí)現(xiàn)核心代碼走讀 → 測(cè)試報(bào)告功能測(cè)試并發(fā)測(cè)試 → 總結(jié)與展望。PPT 則控制在 15 頁(yè)以內(nèi)核心是講清楚“我做了什么”和“我遇到了什么問(wèn)題怎么解決的”不要堆代碼。源碼組織方面也有講究。后端模塊我按 controller、service、mapper、entity、common、config 分包一個(gè)包干一件事。前端把 api 請(qǐng)求封裝到src/api目錄下頁(yè)面組件在src/views下。整個(gè)代碼層級(jí)清晰別人拿到就能快速跑起來(lái)這是“含源碼”項(xiàng)目最基本的要求——不是把代碼甩出來(lái)就叫含源碼而是要讓接手的人能看明白、能改、能運(yùn)行。最后再分享一個(gè)小技巧整個(gè)系統(tǒng)做下來(lái)我最大的感受是課設(shè)級(jí)別的項(xiàng)目重點(diǎn)不在于技術(shù)多新多全而在于邏輯閉環(huán)。你做一個(gè)售票系統(tǒng)就要保證從注冊(cè)到購(gòu)票到支付到核銷到退票整條鏈路每一個(gè)分支都處理到位。我見(jiàn)過(guò)太多項(xiàng)目演示時(shí)主流程很順暢一展示管理員退款就報(bào)錯(cuò)一展示庫(kù)存不足就白屏——這種硬傷特別致命。我自己的習(xí)慣是交付前花半天時(shí)間把核心業(yè)務(wù)鏈路的每一個(gè)接口用 Postman 過(guò)一遍包括異常場(chǎng)景未登錄訪問(wèn)訂單接口、庫(kù)存為 0 時(shí)下單、重復(fù)核銷、非法參數(shù)請(qǐng)求。把這些異常處理正常了演示再過(guò)不了只能說(shuō)明運(yùn)氣不好。另外記得MySQL 和 Redis 的本地環(huán)境配置、數(shù)據(jù)庫(kù)初始化腳本、Redis 數(shù)據(jù)預(yù)置命令全都要寫(xiě)進(jìn) README。換一臺(tái)電腦就跑不起來(lái)這比你代碼寫(xiě)得漂亮但要花三小時(shí)才能啟動(dòng)要致命得多。