1. 為什么每年都有人做預(yù)約系統(tǒng)但這個(gè)題其實(shí)并不簡(jiǎn)單Spring Boot配體育場(chǎng)館設(shè)施預(yù)約系統(tǒng)這個(gè)搭配我在畢業(yè)設(shè)計(jì)的選題名單里看了好幾年可以說(shuō)年年有但絕大多數(shù)人第一反應(yīng)都是“不就是增刪改查嗎”。真到開(kāi)題答辯、中期檢查、最后演示的時(shí)候同一個(gè)題能分出明顯差距有人只演示了頁(yè)面上點(diǎn)擊預(yù)約成功評(píng)委一問(wèn)“兩個(gè)人同時(shí)約同一塊場(chǎng)地怎么辦”就卡殼有人卻能把并發(fā)控制、狀態(tài)機(jī)、超時(shí)釋放、支付冪等全部講清楚答辯變成加分現(xiàn)場(chǎng)。先說(shuō)結(jié)論預(yù)約類(lèi)系統(tǒng)非常適合做畢設(shè)因?yàn)閺?fù)雜度剛好卡在“入門(mén)之上、工程之下”的位置。你說(shuō)它難它沒(méi)有高深的算法你說(shuō)它容易它又牽扯并發(fā)、狀態(tài)流轉(zhuǎn)、資源競(jìng)爭(zhēng)和業(yè)務(wù)規(guī)則稍微處理不好就是臟數(shù)據(jù)。這篇文章我打算把做這類(lèi)系統(tǒng)的完整思路寫(xiě)一遍從選題定調(diào)、功能邊界、數(shù)據(jù)庫(kù)設(shè)計(jì)、訂單狀態(tài)機(jī)到真實(shí)開(kāi)發(fā)中反復(fù)踩過(guò)的坑再到答辯如何講出含金量逐個(gè)拆開(kāi)講透。正在準(zhǔn)備畢設(shè)的同學(xué)應(yīng)該知道預(yù)約系統(tǒng)的套路一旦吃透圖書(shū)館座位預(yù)約、會(huì)議室預(yù)約、健身房課程預(yù)約本質(zhì)都是同一套邏輯換個(gè)業(yè)務(wù)名詞就能復(fù)用。1.1 畢設(shè)選型的“性價(jià)比”判斷復(fù)雜度適中、就業(yè)導(dǎo)向明確為什么推薦這個(gè)題目三個(gè)原因。第一技術(shù)棧主流且成熟。Spring Boot是這兩年企業(yè)開(kāi)發(fā)的事實(shí)標(biāo)準(zhǔn)配上MySQL、MyBatis或Spring Data JPA網(wǎng)上資料一抓一大把遇到問(wèn)題搜得到答案不至于卡死在某個(gè)冷門(mén)技術(shù)上。第二業(yè)務(wù)模型清晰但又不失深度。場(chǎng)館、場(chǎng)地、時(shí)間片、訂單、支付、狀態(tài)流轉(zhuǎn)一層層拆下來(lái)既有常規(guī)CRUD也有真正需要?jiǎng)幽X的并發(fā)與狀態(tài)設(shè)計(jì)工作量適合一個(gè)學(xué)期的周期。第三演示效果好。做出來(lái)的東西能看、能操作、能講用戶端加管理端界面和功能都直觀比某些純算法題更容易讓答辯老師快速理解你做了什么。但這里要提醒一句正因?yàn)轭}目經(jīng)典答辯老師也見(jiàn)多了這個(gè)題所以“能跑”只是及格線。如果你只做到了“用戶能預(yù)約、管理員能看訂單”那大概率就是及格分。拉開(kāi)差距的點(diǎn)在于你有沒(méi)有想清楚資源沖突怎么防止、訂單狀態(tài)怎么流轉(zhuǎn)、超時(shí)訂單怎么處理。這些內(nèi)容不是頁(yè)面堆砌出來(lái)的而是設(shè)計(jì)層面的東西必須在動(dòng)手寫(xiě)代碼之前就定下來(lái)。1.2 先把三個(gè)設(shè)計(jì)抉擇定下來(lái)后面才不會(huì)返工我做這個(gè)類(lèi)型的系統(tǒng)有一個(gè)強(qiáng)烈的體會(huì)返工九成不是代碼寫(xiě)錯(cuò)而是業(yè)務(wù)模型沒(méi)定清楚就開(kāi)始建表。下面三個(gè)問(wèn)題建議在動(dòng)手前先回答。第一個(gè)問(wèn)題預(yù)約的粒度是什么按“場(chǎng)地”還是按“場(chǎng)次”場(chǎng)地維度指的是用戶選擇某塊場(chǎng)地比如羽毛球3號(hào)場(chǎng)的某個(gè)時(shí)間段進(jìn)行預(yù)約適合散客自由約球場(chǎng)次維度指的是管理員預(yù)先排好某些固定時(shí)段比如19:00-20:00羽毛球小班課用戶搶的是這個(gè)場(chǎng)次的名額。體育場(chǎng)館實(shí)際業(yè)務(wù)中兩種都存在但畢設(shè)沒(méi)必要一上來(lái)就做混合模式。我建議以“場(chǎng)地時(shí)間段”作為核心模型時(shí)間片表作為連接場(chǎng)地和訂單的樞紐這樣最貼近真實(shí)場(chǎng)館運(yùn)營(yíng)也最容易把并發(fā)的點(diǎn)設(shè)計(jì)清楚。第二個(gè)問(wèn)題時(shí)間片是固定排好的還是下單時(shí)動(dòng)態(tài)計(jì)算有一個(gè)省事的做法是不建時(shí)間片表用戶下單時(shí)傳“開(kāi)始時(shí)間結(jié)束時(shí)間”服務(wù)端去訂單表里掃一遍有沒(méi)有沖突。這種方案在小數(shù)據(jù)量下確實(shí)能跑但問(wèn)題很明顯一是熱門(mén)時(shí)段用戶同時(shí)搶的時(shí)候沖突檢測(cè)會(huì)非常頻繁二是“判斷是否沖突”的邏輯散落在多個(gè)接口里很容易寫(xiě)漏。我的建議是引入時(shí)間片表讓管理員按場(chǎng)館開(kāi)放時(shí)間和場(chǎng)地類(lèi)型批量生成未來(lái)N天的時(shí)間片用戶只能從空閑時(shí)間片里選。這樣做的一個(gè)隱藏好處是時(shí)間沖突校驗(yàn)被前置到了排期生成階段下單接口只需要關(guān)心“時(shí)間片是否空閑”復(fù)雜度一下就降下來(lái)了。第三個(gè)問(wèn)題單場(chǎng)館還是多場(chǎng)館從表結(jié)構(gòu)設(shè)計(jì)角度我建議從一開(kāi)始就支持“多場(chǎng)館—多場(chǎng)地”的層級(jí)關(guān)系。哪怕你演示的時(shí)候只放一個(gè)體育館的數(shù)據(jù)表結(jié)構(gòu)上也把場(chǎng)館表、場(chǎng)地表分開(kāi)。這樣寫(xiě)論文時(shí)可以說(shuō)“系統(tǒng)支持多場(chǎng)館擴(kuò)展”答辯時(shí)也能應(yīng)對(duì)“如果學(xué)校有好幾個(gè)館怎么處理”的追問(wèn)。2. 功能邊界與業(yè)務(wù)規(guī)則先想清楚“預(yù)約什么”再動(dòng)手功能列表看似簡(jiǎn)單但很多同學(xué)列出十幾個(gè)模塊最后做不完就是因?yàn)闆](méi)有分清“核心鏈路”和“包裝功能”。我通常把功能分成用戶端、管理端和三條業(yè)務(wù)規(guī)則先定邊界再寫(xiě)代碼。2.1 用戶端和管理端到底要做哪些事用戶端核心功能可以控制在六項(xiàng)左右注冊(cè)登錄、瀏覽場(chǎng)館和場(chǎng)地、按日期查詢可約時(shí)間片、提交預(yù)約訂單、模擬支付、取消訂單。再加一個(gè)歷史訂單列表用于查看預(yù)約狀態(tài)。至于收藏、評(píng)論、積分、會(huì)員等級(jí)這些如果時(shí)間和精力允許可以錦上添花但不建議在核心鏈路還沒(méi)跑通之前碰它們。管理端包括場(chǎng)館管理、場(chǎng)地管理、時(shí)間片排期管理、訂單管理、用戶管理。時(shí)間片排期是管理端最重要也最容易忽略的功能它決定了系統(tǒng)能不能真正運(yùn)轉(zhuǎn)起來(lái)。如果時(shí)間片都是手動(dòng)一條條插入數(shù)據(jù)庫(kù)演示時(shí)既難看又容易出錯(cuò)所以一定要做一個(gè)“按日期范圍場(chǎng)地批量生成時(shí)間片”的功能這是管理端的一個(gè)小亮點(diǎn)也是后面很多設(shè)計(jì)的基礎(chǔ)。2.2 三條業(yè)務(wù)規(guī)則提前量、訂單數(shù)上限、最晚取消時(shí)間功能定了之后要寫(xiě)明白的是業(yè)務(wù)規(guī)則這些規(guī)則會(huì)直接影響接口校驗(yàn)邏輯。我見(jiàn)過(guò)不少同學(xué)建完表直接寫(xiě)接口寫(xiě)到一半發(fā)現(xiàn)“這個(gè)狀態(tài)什么時(shí)候能取消”“一個(gè)人能不能同時(shí)占幾塊場(chǎng)地”這些問(wèn)題根本沒(méi)定義代碼越寫(xiě)越別扭。建議先定三條規(guī)則。第一可提前預(yù)約的天數(shù)。比如只能預(yù)約未來(lái)7天內(nèi)的場(chǎng)地避免排期過(guò)遠(yuǎn)導(dǎo)致運(yùn)營(yíng)變動(dòng)后數(shù)據(jù)對(duì)不上。第二單個(gè)用戶同時(shí)有效的預(yù)約單數(shù)量。比如最多同時(shí)有3個(gè)“待支付已支付”狀態(tài)下的訂單防止有人把黃金時(shí)段全部占住。這個(gè)規(guī)則看起來(lái)簡(jiǎn)單但它是防止惡意占位的第一道防線。第三最晚取消時(shí)間。比如開(kāi)球時(shí)間前2小時(shí)可以免費(fèi)取消超過(guò)這個(gè)時(shí)間就不能在用戶端取消了避免場(chǎng)地資源被臨時(shí)放鴿子。這三條規(guī)則在寫(xiě)代碼前用文字列出來(lái)數(shù)據(jù)庫(kù)校驗(yàn)、接口邏輯、前端提示都有了依據(jù)。還有一條容易被忽略的邊界場(chǎng)館的開(kāi)放時(shí)間。比如體育館營(yíng)業(yè)時(shí)間是8:00到22:00那時(shí)間片生成、訂單校驗(yàn)、前端可選項(xiàng)都必須遵循這個(gè)范圍否則就會(huì)出現(xiàn)凌晨三點(diǎn)有人預(yù)約羽毛球場(chǎng)的詭異數(shù)據(jù)。3. 數(shù)據(jù)庫(kù)表結(jié)構(gòu)七張核心表和一條并發(fā)“鐵律”數(shù)據(jù)庫(kù)設(shè)計(jì)是這種系統(tǒng)最關(guān)鍵的部分沒(méi)有之一。因?yàn)轭A(yù)約系統(tǒng)的根問(wèn)題是“數(shù)據(jù)別打架”而數(shù)據(jù)打架的問(wèn)題最好在設(shè)計(jì)表的時(shí)候就徹底封死而不是靠代碼小心翼翼地繞。3.1 七張核心表的職責(zé)劃分拋開(kāi)擴(kuò)展表不談核心表我建議按下面這個(gè)清單設(shè)計(jì)每張表解決一類(lèi)問(wèn)題。表名核心職責(zé)關(guān)鍵字段說(shuō)明user用戶與管理員身份username唯一、password_hash、role(USER/ADMIN)、phonevenue場(chǎng)館name、location、open_time、close_time、statuscourt場(chǎng)地掛在場(chǎng)館下venue_id、name、type(羽毛球/籃球/游泳等)、base_price、statusschedule時(shí)間片連接場(chǎng)地與訂單court_id、date、start_time、end_time、price、status(OPEN/BOOKED/LOCKED)booking_order預(yù)約訂單order_no唯一、user_id、schedule_id、court_id、date、start_time、end_time、total_price、statuspayment_record支付流水order_id、pay_no、amount、status、paid_atadmin_config業(yè)務(wù)規(guī)則配置rule_key、rule_value用于存可預(yù)約天數(shù)、訂單上限等這些表之間的關(guān)系并不復(fù)雜場(chǎng)館1對(duì)多場(chǎng)地場(chǎng)地1對(duì)多時(shí)間片時(shí)間片1對(duì)1訂單訂單1對(duì)1支付流水。真正需要用心設(shè)計(jì)的不是關(guān)系而是字段層面的約束。3.2 并發(fā)鐵律把“同一時(shí)間片只可被預(yù)約一次”壓進(jìn)數(shù)據(jù)庫(kù)這是整篇內(nèi)容里我認(rèn)為最重要的一段。做預(yù)約系統(tǒng)最核心的技術(shù)問(wèn)題就是同一塊場(chǎng)地、同一個(gè)時(shí)間段絕不能出現(xiàn)兩個(gè)有效訂單。很多同學(xué)的做法是下單時(shí)先查詢一下這個(gè)時(shí)間段有沒(méi)有訂單沒(méi)有就插入。這在單用戶操作時(shí)沒(méi)有任何問(wèn)題但一遇到并發(fā)就露餡兩個(gè)請(qǐng)求同時(shí)查到“空閑”然后同時(shí)插入訂單超賣(mài)就發(fā)生了。正確的做法是在數(shù)據(jù)庫(kù)層面把它“焊死”。具體有兩道防線。第一道防線是唯一索引。schedule表上應(yīng)該加上(court_id, date, start_time)的唯一約束意思是同一塊場(chǎng)地同一天同一個(gè)開(kāi)始時(shí)間只能存在一個(gè)時(shí)間片記錄。這是從源頭上保證時(shí)間片本身不重復(fù)。第二道防線是下單時(shí)的原子占位。用一條帶狀態(tài)條件的UPDATE語(yǔ)句搶占時(shí)間片UPDATE schedule SET status BOOKED WHERE id #{scheduleId} AND status OPEN;如果影響行數(shù)為1說(shuō)明這塊場(chǎng)地被你占住了可以繼續(xù)創(chuàng)建訂單如果影響行數(shù)為0說(shuō)明別人已經(jīng)搶先一步直接提示“該時(shí)段已被預(yù)約”。這個(gè)方案依賴(lài)數(shù)據(jù)庫(kù)行鎖避免了先查詢?cè)俨迦氲臅r(shí)間窗口是最直接也最好向評(píng)委解釋的方案。如果你用的是JPA等ORM框架也可以走樂(lè)觀鎖路線在schedule表上加一個(gè)version字段更新時(shí)帶上版本號(hào)條件更新失敗就重試或提示。兩種方案選一種即可但建議在論文中把兩種都寫(xiě)清楚這本身就是很好的答辯素材。3.3 字段細(xì)節(jié)與三個(gè)隱藏約定除了核心字段還有幾個(gè)必須注意的細(xì)節(jié)。第一訂單表要冗余場(chǎng)地名、場(chǎng)館名、時(shí)間段、價(jià)格等信息而不是只存外鍵。為什么因?yàn)槿绻芾韱T后續(xù)調(diào)整了場(chǎng)地名稱(chēng)或者價(jià)格歷史訂單不能被影響而且列表頁(yè)展示時(shí)不需要反復(fù)聯(lián)表查詢。第二業(yè)務(wù)訂單號(hào)order_no要認(rèn)真生成比如用日期加隨機(jī)序列并加上唯一索引。它不只是為了好看也是后續(xù)模擬支付、對(duì)賬時(shí)的標(biāo)識(shí)。第三所有時(shí)間字段建議統(tǒng)一用datetime類(lèi)型Java側(cè)用LocalDateTime避免各種時(shí)區(qū)換算帶來(lái)的詭異問(wèn)題這一點(diǎn)后面第五部分會(huì)詳細(xì)展開(kāi)。還有一個(gè)容易被忽視的點(diǎn)schedule表的price雖然是冗余字段但它的值應(yīng)該從court表的base_price復(fù)制過(guò)來(lái)而不是下單時(shí)臨時(shí)算。因?yàn)閳?chǎng)館調(diào)價(jià)后已經(jīng)生成的時(shí)間片價(jià)格不應(yīng)該跟著飄。這種“快照”思想在訂單系統(tǒng)里很常見(jiàn)寫(xiě)論文時(shí)值得單獨(dú)講一講。4. 核心流程與六個(gè)狀態(tài)一個(gè)預(yù)約訂單的一生下單不是簡(jiǎn)單insert一條記錄而是一系列狀態(tài)流轉(zhuǎn)。我建議把訂單的生命周期單獨(dú)作為一個(gè)設(shè)計(jì)重點(diǎn)因?yàn)樵诖疝q中狀態(tài)機(jī)是比CRUD高級(jí)得多的表達(dá)。4.1 從查詢到入場(chǎng)的五個(gè)步驟一次完整預(yù)約流程可以分為五步查詢可約時(shí)間片、創(chuàng)建預(yù)約訂單、支付、核銷(xiāo)入場(chǎng)、完成。查詢階段只展示狀態(tài)為OPEN的時(shí)間片創(chuàng)建訂單時(shí)通過(guò)上面說(shuō)的原子占位把schedule改成BOOKED同時(shí)生成狀態(tài)為“待支付”的訂單支付成功后把訂單改為“已支付”用戶到場(chǎng)后由管理員核銷(xiāo)或掃碼確認(rèn)訂單變?yōu)椤耙淹瓿伞薄＿@里有一個(gè)設(shè)計(jì)上的關(guān)鍵點(diǎn)創(chuàng)建訂單和鎖定時(shí)間片必須在同一個(gè)事務(wù)里完成否則會(huì)出現(xiàn)訂單創(chuàng)建失敗但時(shí)間片被鎖住的情況。實(shí)現(xiàn)上可以這樣組織先執(zhí)行UPDATE占位再insert訂單如果訂單插入失敗則拋異?；貪L讓UPDATE也回滾時(shí)間片自然恢復(fù)為OPEN。4.2 訂單狀態(tài)機(jī)六個(gè)狀態(tài)怎么流轉(zhuǎn)我建議訂單表用整數(shù)來(lái)表示狀態(tài)配合一張狀態(tài)說(shuō)明表方便查詢和展示。六個(gè)狀態(tài)如下?tīng)顟B(tài)值狀態(tài)名含義可流轉(zhuǎn)去向0待支付已鎖定時(shí)間片但未付款已支付、已取消、超時(shí)關(guān)閉1已支付用戶已付款等待入場(chǎng)已完成、已取消2已完成已被核銷(xiāo)行程結(jié)束終態(tài)3已取消用戶主動(dòng)取消終態(tài)4超時(shí)關(guān)閉系統(tǒng)自動(dòng)關(guān)閉未支付訂單終態(tài)5已退款已支付訂單取消后退款終態(tài)狀態(tài)機(jī)的核心原則是任何狀態(tài)之間的跳轉(zhuǎn)都必須有明確的觸發(fā)條件和操作入口不能讓一條訂單同時(shí)處于兩個(gè)狀態(tài)。比如用戶取消時(shí)只有“待支付”和“已支付”狀態(tài)能走取消流程取消成功后如果之前已支付就再進(jìn)入“已退款”。超時(shí)關(guān)閉只針對(duì)“待支付”狀態(tài)已支付的訂單不能被定時(shí)任務(wù)直接關(guān)閉否則會(huì)引發(fā)支付和訂單狀態(tài)不一致。4.3 三個(gè)核心接口與超時(shí)釋放預(yù)約系統(tǒng)的接口不必很多但三個(gè)核心接口的邏輯要足夠健壯。創(chuàng)建預(yù)約接口的核心是原子占位加事務(wù)支付接口的核心是冪等無(wú)論用戶點(diǎn)擊多少次支付按鈕或者模擬支付回調(diào)重復(fù)通知都不能產(chǎn)生多筆有效流水取消接口的核心是釋放資源不管訂單狀態(tài)改成了什么最終必須把對(duì)應(yīng)schedule的狀態(tài)改回OPEN讓其他用戶能繼續(xù)約。還有一個(gè)業(yè)務(wù)上很現(xiàn)實(shí)的問(wèn)題用戶下單后不付款場(chǎng)地被一直鎖著怎么辦。我在實(shí)際設(shè)計(jì)里用了“定時(shí)任務(wù)掃描用戶主動(dòng)取消”雙通道。定時(shí)任務(wù)每隔幾分鐘掃一次把超過(guò)15分鐘仍未支付的待支付訂單改成超時(shí)關(guān)閉并釋放對(duì)應(yīng)時(shí)間片。同時(shí)在用戶端允許用戶主動(dòng)取消待支付訂單取消時(shí)同樣釋放時(shí)間片。兩個(gè)通道都做是因?yàn)槿魏螁我粰C(jī)制都可能因?yàn)橛脩敉岁P(guān)頁(yè)面而導(dǎo)致座位被無(wú)效占用。5. 我在開(kāi)發(fā)中反復(fù)踩過(guò)的六個(gè)坑這一部分是我最想寫(xiě)的。網(wǎng)上教程只會(huì)告訴你“應(yīng)該怎么做”但實(shí)際開(kāi)發(fā)中真正讓人崩潰的往往是那些看起來(lái)不起眼、卻能把整個(gè)邏輯帶偏的細(xì)節(jié)。下面六個(gè)問(wèn)題都是我在做類(lèi)似系統(tǒng)時(shí)真實(shí)遇到過(guò)、也幫人排查過(guò)的。5.1 并發(fā)下單時(shí)場(chǎng)地“超賣(mài)”了前面提到了countinsert方式的隱患這里用更實(shí)際的場(chǎng)景描述一遍。我最初做第一版時(shí)創(chuàng)建預(yù)約的代碼是先查schedule狀態(tài)再判斷是否為空然后插入訂單。用Postman模擬兩個(gè)請(qǐng)求同時(shí)打同一個(gè)時(shí)間片接口時(shí)兩個(gè)請(qǐng)求都打印了“當(dāng)前狀態(tài)為空閑”然后都成功創(chuàng)建了訂單。那一刻我才意識(shí)到應(yīng)用層的“先查后寫(xiě)”永遠(yuǎn)存在競(jìng)態(tài)窗口解決問(wèn)題必須靠數(shù)據(jù)庫(kù)的原子操作。后來(lái)改成UPDATE ... WHERE statusOPEN之后再并發(fā)測(cè)試就穩(wěn)定了。這里給一個(gè)排查建議凡是涉及資源搶占的邏輯不要相信“我在代碼里加了if判斷”直接用數(shù)據(jù)庫(kù)的原子更新或唯一的數(shù)據(jù)庫(kù)約束驗(yàn)證然后用并發(fā)請(qǐng)求實(shí)測(cè)別只靠點(diǎn)頁(yè)面測(cè)。5.2 內(nèi)部自調(diào)用讓Transactional形同虛設(shè)這是一個(gè)很經(jīng)典的Spring Boot陷阱。我在取消訂單時(shí)寫(xiě)了這樣一個(gè)結(jié)構(gòu)訂單Service里有一個(gè)cancel方法內(nèi)部調(diào)用了同類(lèi)里的releaseSchedule方法而releaseSchedule上加了Transactional注解。測(cè)試時(shí)發(fā)現(xiàn)如果cancel方法本身在事務(wù)里調(diào)用releaseSchedule的事務(wù)還能沾點(diǎn)光但當(dāng)我單獨(dú)調(diào)用releaseSchedule時(shí)事務(wù)根本不生效。原因很簡(jiǎn)單同類(lèi)內(nèi)部方法調(diào)用不會(huì)經(jīng)過(guò)Spring的代理對(duì)象注解自然就不起作用。解決辦法也很直接把釋放場(chǎng)地的邏輯放到另一個(gè)Service比如ScheduleService里讓訂單Service調(diào)用ScheduleService的方法。這樣事務(wù)邊界既清晰又有效。這個(gè)坑在寫(xiě)論文時(shí)其實(shí)可以當(dāng)作一個(gè)“踩坑記錄”寫(xiě)進(jìn)去反而顯得真實(shí)。5.3 時(shí)間重疊判斷的邊界條件如果哪天你決定不按時(shí)間片結(jié)構(gòu)做而是下單時(shí)動(dòng)態(tài)校驗(yàn)時(shí)間段那么“判斷時(shí)間段是否重疊”就是一個(gè)躲不開(kāi)的邏輯。很多人在這里栽過(guò)跟頭。正確判斷兩組時(shí)間區(qū)間[aStart, aEnd)和[bStart, bEnd)是否重疊的條件是aStart bEnd bStart aEnd。用Java代碼寫(xiě)就是public boolean isOverlap(LocalDateTime aStart, LocalDateTime aEnd, LocalDateTime bStart, LocalDateTime bEnd) { return aStart.isBefore(bEnd) bStart.isBefore(aEnd); }重點(diǎn)在于使用半開(kāi)區(qū)間也就是開(kāi)始時(shí)間包含、結(jié)束時(shí)間不包含。這樣14:00-16:00和16:00-18:00兩個(gè)相鄰時(shí)間片會(huì)返回false不會(huì)誤判成沖突。很多同學(xué)用閉區(qū)間思維把條件寫(xiě)成aStart bEnd bStart aEnd結(jié)果兩個(gè)緊挨著的預(yù)約被當(dāng)成沖突調(diào)試半天不知道原因。5.4 待支付訂單把黃金時(shí)段“焊死”這個(gè)問(wèn)題我在聯(lián)調(diào)時(shí)才意識(shí)到有多惡心。當(dāng)時(shí)為了測(cè)試我連續(xù)創(chuàng)建了好幾個(gè)待支付訂單把晚高峰的幾個(gè)時(shí)間片全鎖住了然后關(guān)閉頁(yè)面不再操作這些時(shí)間片就永久處于BOOKED狀態(tài)其他用戶根本約不了。如果不做超時(shí)釋放整個(gè)場(chǎng)館的可約資源會(huì)慢慢被垃圾訂單占滿。解決方案就是前面說(shuō)的定時(shí)任務(wù)加主動(dòng)取消雙通道。實(shí)現(xiàn)上我有一個(gè)心得定時(shí)任務(wù)不要掃描所有訂單而是只查“狀態(tài)為待支付且創(chuàng)建時(shí)間早于當(dāng)前時(shí)間15分鐘”的訂單這樣即使訂單量大了也不會(huì)太慢。釋放時(shí)間片和關(guān)閉訂單這兩個(gè)操作同樣要在事務(wù)里完成。5.5 懶加載異常在聯(lián)調(diào)時(shí)才暴露如果用Spring Data JPA做關(guān)聯(lián)查詢訂單表里的court、venue這些關(guān)聯(lián)對(duì)象默認(rèn)是懶加載的。在Service層開(kāi)啟事務(wù)時(shí)沒(méi)問(wèn)題一旦把實(shí)體直接返回給ControllerJackson序列化時(shí)訪問(wèn)關(guān)聯(lián)屬性就會(huì)拋LazyInitializationException。這個(gè)問(wèn)題屬于典型的“單測(cè)測(cè)不出來(lái)、聯(lián)調(diào)必現(xiàn)”的坑。解決方式有幾個(gè)我個(gè)人推薦在Service層就把實(shí)體轉(zhuǎn)換成DTO或VO不要在Controller里直接返回實(shí)體。這樣既避免懶加載問(wèn)題也防止實(shí)體內(nèi)部結(jié)構(gòu)暴露給前端還方便在DTO里組裝展示字段。養(yǎng)成這個(gè)習(xí)慣之后答辯時(shí)也能順帶聊聊分層設(shè)計(jì)比單純講CRUD強(qiáng)得多。5.6 前后相差8小時(shí)的詭異預(yù)約時(shí)間這是一個(gè)看著玄學(xué)、查了半小時(shí)才發(fā)現(xiàn)的坑。用戶在頁(yè)面上選的18:00存進(jìn)數(shù)據(jù)庫(kù)變成了10:00或者反過(guò)來(lái)查詢時(shí)全部偏了8小時(shí)。問(wèn)題根源在時(shí)區(qū)MySQL連接串沒(méi)有指定serverTimezoneJVM時(shí)區(qū)和數(shù)據(jù)庫(kù)時(shí)區(qū)不一致Timestamp類(lèi)型在轉(zhuǎn)換時(shí)被自動(dòng)調(diào)整了。我的解決方式是統(tǒng)一三處約定數(shù)據(jù)庫(kù)連接串顯式帶上serverTimezoneAsia/ShanghaiJava側(cè)全部使用LocalDateTime而不是Date數(shù)據(jù)庫(kù)表字段統(tǒng)一用datetime而不是timestamp。這里不建議用timestamp是因?yàn)樗鼉?nèi)部轉(zhuǎn)換邏輯太容易受時(shí)區(qū)影響對(duì)預(yù)約系統(tǒng)這種需要精確時(shí)間段的場(chǎng)景不太友好。6. 答辯怎么講從“系統(tǒng)”到“并發(fā)場(chǎng)景下的資源預(yù)定引擎”最后這部分很實(shí)在因?yàn)榇a寫(xiě)得再好答辯講不出來(lái)也白搭。我見(jiàn)過(guò)不少同學(xué)功能都做完了但匯報(bào)時(shí)只會(huì)打開(kāi)頁(yè)面一個(gè)個(gè)點(diǎn)評(píng)委看到的只是“這個(gè)按鈕能跳轉(zhuǎn)”自然覺(jué)得是普通管理系統(tǒng)。你得換一種講法。6.1 答辯展示的三層敘事建議按三層來(lái)講。第一層講數(shù)據(jù)庫(kù)設(shè)計(jì)重點(diǎn)講為什么引入時(shí)間片表、為什么把沖突校驗(yàn)前置到排期生成階段而不是下單時(shí)去掃訂單表。第二層講并發(fā)控制把“兩人同時(shí)約同一塊場(chǎng)地”這個(gè)問(wèn)題拋出來(lái)然后展示唯一索引加原子占位更新的解決方案。第三層講訂單狀態(tài)機(jī)從待支付到超時(shí)關(guān)閉、已支付到已完成把六個(gè)狀態(tài)的流轉(zhuǎn)圖畫(huà)清楚同時(shí)說(shuō)明超時(shí)釋放的雙通道設(shè)計(jì)。演示時(shí)也可以準(zhǔn)備兩個(gè)對(duì)比場(chǎng)景第一次演示正常下單第二次用并發(fā)工具模擬兩個(gè)請(qǐng)求同時(shí)搶同一個(gè)時(shí)間片展示只有一個(gè)能成功。這個(gè)演示比任何PPT文字都更有說(shuō)服力。切記在論文里寫(xiě)了Redis、消息隊(duì)列、分布式鎖這類(lèi)技術(shù)點(diǎn)就一定要自己動(dòng)手實(shí)現(xiàn)過(guò)否則評(píng)委追問(wèn)一個(gè)細(xì)節(jié)就可能露餡。如果只在數(shù)據(jù)庫(kù)層面做了并發(fā)控制那就誠(chéng)實(shí)地講數(shù)據(jù)庫(kù)方案這已經(jīng)很扎實(shí)了。6.2 七周開(kāi)發(fā)節(jié)奏與優(yōu)先級(jí)建議我建議拿七周左右的完整周期來(lái)做這個(gè)題每周有明確產(chǎn)出避免前松后緊。大致節(jié)奏如下周次任務(wù)關(guān)鍵產(chǎn)出第1周需求分析 數(shù)據(jù)庫(kù)設(shè)計(jì) 頁(yè)面草圖文檔、ER圖、表結(jié)構(gòu)第2周Spring Boot工程搭建 用戶場(chǎng)館基礎(chǔ)CRUD可用工程、完成登錄第3周時(shí)間片生成 預(yù)約下單主鏈路從選時(shí)間到生成訂單第4周訂單狀態(tài)機(jī) 模擬支付 超時(shí)任務(wù)狀態(tài)流轉(zhuǎn)完整第5周管理端頁(yè)面 前端聯(lián)調(diào)前后端跑通第6周并發(fā)測(cè)試 邊界修復(fù)并發(fā)過(guò)測(cè)、修復(fù)八小時(shí)時(shí)區(qū)等問(wèn)題第7周寫(xiě)論文 準(zhǔn)備演示 模擬答辯管理端展示不花哨核心鏈路流暢優(yōu)先級(jí)上先打通“選時(shí)間片—下單—支付—核銷(xiāo)”這條主干道再做取消、超時(shí)、退款這些分支邏輯最后還有時(shí)間才做統(tǒng)計(jì)報(bào)表和頁(yè)面美化。很多同學(xué)一開(kāi)始就折騰前端動(dòng)畫(huà)、UI特效最后發(fā)現(xiàn)核心流程還沒(méi)走通這是最可惜的。最后說(shuō)一點(diǎn)個(gè)人體會(huì)這種系統(tǒng)最怕的不是不會(huì)寫(xiě)代碼而是拿到題目就悶頭建表寫(xiě)Controller。我見(jiàn)過(guò)不少同學(xué)把所有表建完才開(kāi)始想業(yè)務(wù)規(guī)則結(jié)果狀態(tài)沒(méi)定義清楚改了三遍代碼。如果你看完這篇還是不知道從哪里下手我的建議是先打開(kāi)一個(gè)文檔把“用戶能做什么、管理員能做什么、訂單有幾個(gè)狀態(tài)、同一個(gè)時(shí)間片被搶怎么辦”這四個(gè)問(wèn)題各寫(xiě)一段話寫(xiě)明白了再動(dòng)手。抓住并發(fā)和狀態(tài)這兩條主線這套系統(tǒng)就會(huì)走得穩(wěn)答辯時(shí)也有話可講。