約系統(tǒng)開發(fā)實戰(zhàn)：并發(fā)控制、數(shù)據(jù)庫與狀態(tài)流轉(zhuǎn))
1. 項目核心思路與需求拆解1.1 高校講座預(yù)約的真實痛點先講個身邊的場景。某高校每學(xué)期都會安排幾十場講座涵蓋學(xué)術(shù)前沿、就業(yè)指導(dǎo)、心理健康、通識素養(yǎng)等方向。以前是怎么管的學(xué)生會發(fā)通知大家到現(xiàn)場排隊簽到熱門講座經(jīng)常出現(xiàn)兩種情況一是報告廳擠爆了過道里都站滿人消防通道都被堵住二是某些冷門講座來了不到三分之一臺上專家講得尷尬臺下學(xué)生玩手機。后來有人嘗試用在線文檔接龍報名但信息混亂、容易串改、無法統(tǒng)計到場率管理員光是核對名單就要花小半天。這個系統(tǒng)的核心價值就是把“講座預(yù)約”這件事從人工排隊和Excel表里解放出來形成一個學(xué)生在線預(yù)約、后臺統(tǒng)一管理、簽到數(shù)據(jù)自動統(tǒng)計的閉環(huán)。它不是一個花里胡哨的Demo而是真正能部署到校醫(yī)院、圖書館報告廳、教學(xué)樓多媒體教室這類場景里用的管理系統(tǒng)。目標用戶很明確學(xué)生、教師講座主講人、院系管理員、系統(tǒng)超級管理員四類角色。面向的學(xué)生可能幾千人甚至上萬人所以并發(fā)預(yù)約不能被一個簡單的開關(guān)按鈕帶崩。從技術(shù)上我選了Spring Boot作為后端框架配合MyBatis Plus操作數(shù)據(jù)庫前端用Vue或者Thymeleaf模板引擎做頁面。數(shù)據(jù)庫用MySQL部署在服務(wù)器上用Maven打包成jar直接跑。整套技術(shù)棧不新但勝在穩(wěn)定、資料多、團隊協(xié)作時上手快學(xué)生開發(fā)者照著官方文檔也能七天落地。1.2 角色劃分與核心業(yè)務(wù)流程這個系統(tǒng)不是孤立的預(yù)約工具它要覆蓋講座從發(fā)布到結(jié)束的完整生命周期。我們梳理下來核心角色分成四類學(xué)生用戶瀏覽講座列表、查看詳情、在線預(yù)約、取消預(yù)約、講座簽到、查看自己的預(yù)約記錄和學(xué)分/學(xué)時累計。講座主講人教師提交講座申請?zhí)顚懼黝}、內(nèi)容簡介、時間、地點、容量等信息查看自己講座的預(yù)約情況和到場率。院系管理員審核主講人提交的講座申請排定講座計劃查看本院系的預(yù)約數(shù)據(jù)統(tǒng)計導(dǎo)出參與名單。系統(tǒng)超級管理員維護基礎(chǔ)數(shù)據(jù)教室、時間段、管理用戶和角色權(quán)限、處理異常數(shù)據(jù)、查看全局統(tǒng)計報表。核心流程其實只有一條主線主講人提交講座申請管理員審核通過后講座狀態(tài)變?yōu)椤翱深A(yù)約”學(xué)生在預(yù)約開放時間內(nèi)搶名額講座開始前或現(xiàn)場進行簽到講座結(jié)束后管理員確認講座完成并統(tǒng)計實際到場人數(shù)。整個流程里有一個容易被忽略的細節(jié)預(yù)約不是無限開放的必須區(qū)分“預(yù)約開始時間”和“預(yù)約截止時間”否則學(xué)生會提前好幾天把名額占滿后面想聽的人進不來。這個需求我在第一版設(shè)計時漏掉了結(jié)果被某院系老師反饋“學(xué)生下午四點半的講座凌晨十二點就把票搶光了”后來才補上預(yù)約窗口的字段。1.3 功能邊界與優(yōu)先級取舍很多人做管理系統(tǒng)容易犯一個毛病啥功能都想加結(jié)果代碼一團亂麻。我理功能清單的時候把需求分成“必須有”和“可以有”兩檔。必須有登錄認證、角色權(quán)限控制、講座CRUD、預(yù)約/取消、簽到、預(yù)約記錄查詢、用戶管理、基礎(chǔ)數(shù)據(jù)統(tǒng)計?？梢杂械珒?yōu)先級低消息通知站內(nèi)信、郵件、二維碼電子票、黑名單機制、講座評價、打印簽到表、數(shù)據(jù)導(dǎo)出Excel。實際開發(fā)中我建議把二維碼電子票和Excel導(dǎo)出放到第二階段。不是說不重要而是第一版先把預(yù)約主流程跑通讓學(xué)生能約、管理員能統(tǒng)計這就是上線的最小可用閉環(huán)。我們第一版上線時連二維碼都沒做簽到用的是管理員手機端搜索學(xué)號手工確認雖然原始了一點但核心數(shù)據(jù)鏈路已經(jīng)走通了。后來第二版加了二維碼簽到入場速度從每人20秒降到了3秒體驗差異非常明顯。2. 技術(shù)選型與架構(gòu)設(shè)計解析2.1 為什么是Spring Boot而非其他方案我遇到過不少同學(xué)問為什么不用PHP或者Node.js甚至有人建議用Python的Flask。我的回答是Spring Boot在這個場景下不是“最好”的但它是“最不容易出錯”的。首先高校里的系統(tǒng)往往要運行很多年維護的人可能是下一屆的學(xué)生、另一個部門的老師甚至外包團隊。Spring Boot加Java的技術(shù)棧是市場保有量最大的接手的人大概率見過這類代碼不至于完全看不懂。其次Spring Boot的生態(tài)太完整了做權(quán)限有Spring Security做接口文檔有Knife4j做數(shù)據(jù)庫操作有MyBatis Plus出問題百度一搜全是解決方案。最后高校系統(tǒng)通常部署在校內(nèi)服務(wù)器環(huán)境多半是老舊的CentOS或者Windows ServerJava的跨平臺能力在這種環(huán)境下非常省心一個JDK加一個Jar包就完事了。對比一下其他方案的短板技術(shù)方案優(yōu)勢在本項目中的短板PHP部署簡單、上手快長期維護的代碼規(guī)范性往往不如Spring體系復(fù)雜業(yè)務(wù)邏輯容易寫成面條代碼Node.js高并發(fā)IO能力強高校運維團隊對Node生態(tài)相對陌生部署和排障成本高Flask輕量靈活缺乏完整的權(quán)限、事務(wù)、ORM生態(tài)做管理系統(tǒng)需要自己拼裝太多零件2.2 整體技術(shù)棧構(gòu)成這個項目的技術(shù)棧我可以直接列出來都是很主流的組合JDK 8我用的是JDK 8穩(wěn)定且兼容性好新項目也可以直接上JDK 17Spring Boot 2.7.x3.x也OK但要注意部分第三方starter的兼容性MyBatis Plus 3.5.x單表CRUD幾乎不需要寫SQL節(jié)省大量時間MySQL 5.7或8.08.0的窗口函數(shù)做統(tǒng)計非常方便Redis用于緩存講座列表和分布式鎖如果數(shù)據(jù)量不大也可以先不引入Vue 2 Element UI前端管理端學(xué)生端我用的是Thymeleaf加Bootstrap因為學(xué)生端的頁面比較輕不需要太大的前端工程Maven依賴管理和打包這套組合的核心思路是后端業(yè)務(wù)邏輯用Spring Boot的依賴注入和事務(wù)管理來組織數(shù)據(jù)庫操作交給MyBatis Plus減少樣板代碼緩存和鎖用Redis解決熱點數(shù)據(jù)的并發(fā)問題。比如講座詳情頁會被頻繁刷新第一次查完放進Redis后面直接命中緩存數(shù)據(jù)庫的壓力會大大降低。2.3 工程結(jié)構(gòu)與分層設(shè)計工程結(jié)構(gòu)上我采用了經(jīng)典的四層架構(gòu)沒有過度設(shè)計。如果你拉過太多開源項目會發(fā)現(xiàn)很多人喜歡建一堆模塊結(jié)果一個幾百兆的小項目拆成七八個Maven子模塊看起來高大上實際維護起來想哭。我建議用單模塊加包名分層的方案簡單直接的代碼樹com.example.lecture ├── controller // 接口入口只做參數(shù)接收和結(jié)果封裝 ├── service // 業(yè)務(wù)邏輯層事務(wù)邊界都在這一層 │ └── impl ├── mapper // MyBatis Plus的Mapper接口 ├── entity // 數(shù)據(jù)庫實體類 ├── dto // 前端交互的數(shù)據(jù)傳輸對象 ├── vo // 視圖對象聚合多表查詢結(jié)果 ├── config // 配置類Redis、攔截器、跨域等 ├── common // 通用工具類、統(tǒng)一返回結(jié)果、異常處理 └── enums // 狀態(tài)枚舉分層設(shè)計最重要的一個原則Controller只做參數(shù)校驗和調(diào)用Service不要在里面寫業(yè)務(wù)邏輯。我見過太多人把查詢數(shù)據(jù)庫的代碼寫在Controller里導(dǎo)致后面想復(fù)用邏輯的時候只能復(fù)制粘貼。Service層的每個方法代表一個完整的業(yè)務(wù)動作方法上標注事務(wù)注解。DTO和VO分開的好處是數(shù)據(jù)庫字段變化不會直接暴露給前端接口。舉個例子講座實體類里有“備注”字段但前端展示時不需要這個字段VO里不包含就可以了返回給用戶的JSON就干干凈凈。3. 數(shù)據(jù)庫設(shè)計與核心表結(jié)構(gòu)3.1 概念模型與ER分析數(shù)據(jù)庫設(shè)計是整個項目的基石表結(jié)構(gòu)沒設(shè)計好后面寫業(yè)務(wù)代碼就是在爛地基上蓋樓。我畫ER圖時先列出核心實體用戶、講座、預(yù)約記錄、教室/場地、學(xué)院。關(guān)系也很清晰一個用戶學(xué)生可以預(yù)約多個講座一個講座可以被多個用戶預(yù)約這是典型的多對多關(guān)系通過中間表“預(yù)約記錄表”來解除多對多關(guān)聯(lián)。講座與教室是多對一教室與學(xué)院是一對多。這里有一個建模時容易犯的錯誤把預(yù)約人數(shù)當成字段直接存在講座表里比如reserved_count而不是通過預(yù)約記錄表實時count。如果并發(fā)量不大直接count也能用但每次查詢都要全表聯(lián)合統(tǒng)計數(shù)據(jù)庫會很吃力。我的做法是在講座表里維護一個冗余字段reserved_count預(yù)約成功時加1取消預(yù)約時減1。這種用空間換時間的做法在中小型系統(tǒng)里非常實用配合事務(wù)控制數(shù)據(jù)一致性是可以保證的。3.2 核心表結(jié)構(gòu)詳解直接上核心建表SQL這幾個表就是系統(tǒng)的骨架CREATE TABLE sys_user ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主鍵ID, username varchar(50) NOT NULL COMMENT 登錄賬號學(xué)號或工號, password varchar(100) NOT NULL COMMENT 加密后的密碼, real_name varchar(50) NOT NULL COMMENT 真實姓名, role tinyint(4) NOT NULL DEFAULT 1 COMMENT 角色1學(xué)生 2教師 3院系管理員 4系統(tǒng)管理員, college_id bigint(20) DEFAULT NULL COMMENT 所屬學(xué)院ID, phone varchar(20) DEFAULT NULL COMMENT 手機號, email varchar(100) DEFAULT NULL COMMENT 郵箱, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 狀態(tài)1正常 0禁用, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 創(chuàng)建時間, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用戶表;CREATE TABLE lecture ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主鍵ID, title varchar(200) NOT NULL COMMENT 講座標題, speaker varchar(50) NOT NULL COMMENT 主講人姓名, speaker_intro varchar(500) DEFAULT NULL COMMENT 主講人簡介, content text COMMENT 講座內(nèi)容簡介, location varchar(100) NOT NULL COMMENT 講座地點, start_time datetime NOT NULL COMMENT 開始時間, end_time datetime NOT NULL COMMENT 結(jié)束時間, reserve_start_time datetime NOT NULL COMMENT 預(yù)約開始時間, reserve_end_time datetime NOT NULL COMMENT 預(yù)約截止時間, capacity int(11) NOT NULL DEFAULT 0 COMMENT 最大可預(yù)約人數(shù), reserved_count int(11) NOT NULL DEFAULT 0 COMMENT 已預(yù)約人數(shù), status tinyint(4) NOT NULL DEFAULT 0 COMMENT 狀態(tài)0待審核 1已審核/可預(yù)約 2已截止 3已完成 4已取消, creator_id bigint(20) NOT NULL COMMENT 創(chuàng)建人主講人ID, audit_remark varchar(200) DEFAULT NULL COMMENT 審核備注, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 創(chuàng)建時間, update_time datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT 更新時間, PRIMARY KEY (id), KEY idx_start_time (start_time), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT講座表;CREATE TABLE reservation ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主鍵ID, lecture_id bigint(20) NOT NULL COMMENT 講座ID, user_id bigint(20) NOT NULL COMMENT 用戶ID, reserve_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 預(yù)約時間, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 狀態(tài)0已預(yù)約 1已簽到 2已取消 3爽約, check_time datetime DEFAULT NULL COMMENT 簽到時間, source tinyint(4) DEFAULT 0 COMMENT 來源0網(wǎng)頁 1移動端, PRIMARY KEY (id), UNIQUE KEY uk_lecture_user (lecture_id, user_id), KEY idx_user_id (user_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT預(yù)約記錄表;這三張表是核心其他表比如學(xué)院表、教室表、操作日志表就按常規(guī)設(shè)計。需要注意的有幾點第一預(yù)約記錄表里的聯(lián)合唯一索引uk_lecture_user它的作用是防止同一個人對同一場講座重復(fù)預(yù)約這是數(shù)據(jù)庫層面的最后一道防線即使業(yè)務(wù)邏輯有bug這條索引也能攔住臟數(shù)據(jù)。第二所有表的主鍵都用bigint自增不用雪花算法也不用UUID因為并發(fā)量沒那么大自增主鍵在InnoDB里性能和存儲上都更好。第三狀態(tài)字段用tinyint而不是varchar省空間、查詢快配合項目里的枚舉類做對應(yīng)映射可讀性也不差。3.3 狀態(tài)字段設(shè)計的重要性狀態(tài)字段在整個系統(tǒng)里扮演的角色比我最初設(shè)想的更重要。講座表里的status字段我特意設(shè)計了從0到4五個狀態(tài)值分別對應(yīng)待審核、已審核可預(yù)約、已截止、已完成、已取消。每個狀態(tài)的流轉(zhuǎn)方向是有約束的比如“已完成”的講座不能再變回“可預(yù)約”“已取消”的講座不允許再被預(yù)約。這就像現(xiàn)實中的流程一樣講座一旦結(jié)束數(shù)據(jù)就是歷史數(shù)據(jù)不能隨便改。預(yù)約記錄表的status字段也有講究0已預(yù)約、1已簽到、2已取消、3爽約。區(qū)分“已取消”和“爽約”特別重要因為很多高校會把講座考勤納入第二課堂學(xué)分或綜合素質(zhì)評價。如果學(xué)生預(yù)約了但沒去系統(tǒng)應(yīng)該記錄為“爽約”而不是簡簡單單刪除記錄。后來做統(tǒng)計報表時這個設(shè)計的價值就體現(xiàn)出來了輔導(dǎo)員可以直接看到每個學(xué)生的爽約次數(shù)不再需要人工翻聊天記錄。4. 核心功能實現(xiàn)與關(guān)鍵代碼解析4.1 預(yù)約流程控制與庫存扣減預(yù)約是整個系統(tǒng)最核心的接口也是并發(fā)壓力最大的地方。想象一下一場熱門講座放出來200個名額學(xué)生們在同一時間點瘋狂點擊預(yù)約按鈕如果代碼寫得不對超出了預(yù)約數(shù)量上限超賣問題就來了。我見過很多新手寫的預(yù)約邏輯是這樣的先查講座的reserved_count判斷是否小于capacity如果小于就加1然后插入預(yù)約記錄。這代碼表面上邏輯沒問題但在高并發(fā)下會出大問題。兩個請求同時查到reserved_count199都判斷小于200于是都執(zhí)行了加1操作結(jié)果reserved_count變成了201超出了容量限制。為什么會這樣因為查詢和更新之間不是一個原子操作中間有間隙。正確的做法是利用數(shù)據(jù)庫的行鎖或樂觀鎖機制。我推薦的做法是直接在SQL層面做原子扣減Transactional(rollbackFor Exception.class) public ReserveResult reserveLecture(ReserveRequest request) { // 1. 校驗講座存在且狀態(tài)為可預(yù)約 Lecture lecture lectureMapper.selectById(request.getLectureId()); if (lecture null || lecture.getStatus() ! LectureStatus.REVIEWED.getCode()) { return ReserveResult.fail(講座不存在或不在預(yù)約時間內(nèi)); } // 2. 核心原子扣減庫存條件里帶上 reserved_count capacity int updateRows lectureMapper.reduceStock(request.getLectureId()); if (updateRows 0) { return ReserveResult.fail(手速慢了名額已被搶完); } // 3. 再插入預(yù)約記錄 Reservation reservation new Reservation(); reservation.setLectureId(request.getLectureId()); reservation.setUserId(request.getUserId()); reservation.setStatus(ReserveStatus.RESERVED.getCode()); reservationMapper.insert(reservation); return ReserveResult.success(); }對應(yīng)的Mapper SQLupdate idreduceStock UPDATE lecture SET reserved_count reserved_count 1 WHERE id #{lectureId} AND status 1 AND reserved_count lt; capacity /update這個update語句利用了MySQL的行鎖機制當多個事務(wù)同時更新同一行數(shù)據(jù)時它們會排隊執(zhí)行后執(zhí)行的事務(wù)會基于前一個事務(wù)更新后的值重新判斷條件。如果reserved_count已經(jīng)等于capacity了條件reserved_count capacity就不成立了影響行數(shù)為0說明名額搶完了。這種方式既保證了不超賣又不需要手動加鎖性能和安全性兼顧。4.2 沖突檢測同一時間段多講座另一個容易被忽略的需求是同一個學(xué)生能不能同時預(yù)約兩個時間重疊的講座從情理上講學(xué)生是不能分身同時出現(xiàn)在兩個會場的所以系統(tǒng)應(yīng)該阻止這種沖突。實現(xiàn)思路也簡單在插入預(yù)約記錄之前先查一下該用戶已預(yù)約且狀態(tài)為“已預(yù)約”或“已簽到”的講座看其中是否有與新講座時間重疊的記錄。Transactional(rollbackFor Exception.class) public ReserveResult reserveLecture(ReserveRequest request) { // ... 省略前面的庫存校驗邏輯 ... // 新增時間沖突檢測 Lecture newLecture lectureMapper.selectById(request.getLectureId()); ListLecture userLectures lectureMapper.selectOverlappingLectures( request.getUserId(), newLecture.getStartTime(), newLecture.getEndTime(), Arrays.asList(ReserveStatus.RESERVED.getCode(), ReserveStatus.CHECKED.getCode()) ); if (!userLectures.isEmpty()) { return ReserveResult.fail(您已預(yù)約了時間沖突的講座 userLectures.get(0).getTitle()); } }對應(yīng)的SQLSELECT DISTINCT l.* FROM reservation r INNER JOIN lecture l ON r.lecture_id l.id WHERE r.user_id #{userId} AND r.status IN (0, 1) AND l.status IN (1, 2) AND NOT (#{newEndTime} lt; l.start_time OR #{newStartTime} l.end_time)這個“NOT (結(jié)束時間小于等于對方開始時間 或 開始時間大于等于對方結(jié)束時間)”的判斷就是區(qū)間重疊檢測的經(jīng)典寫法涵蓋了包含、被包含、交叉等所有重疊情況。4.3 簽到邏輯與狀態(tài)流轉(zhuǎn)簽到功能在第二版才加入二維碼。管理員手機上打開一個小程序頁面其實就是一個適配移動端的網(wǎng)頁掃描學(xué)生出示的二維碼識別學(xué)號后調(diào)用簽到接口。簽到接口的邏輯不復(fù)雜Transactional(rollbackFor Exception.class) public CheckResult checkIn(CheckInRequest request) { // 1. 判斷當前時間是否在講座開始前30分鐘到結(jié)束后1小時之間 Lecture lecture lectureMapper.selectById(request.getLectureId()); Date now new Date(); if (now.before(DateUtil.addMinutes(lecture.getStartTime(), -30)) || now.after(DateUtil.addHours(lecture.getEndTime(), 1))) { return CheckResult.fail(不在簽到時間段內(nèi)); } // 2. 查詢預(yù)約記錄 Reservation reservation reservationMapper.selectByLectureIdAndUserId( request.getLectureId(), request.getUserId()); if (reservation null) { return CheckResult.fail(未查詢到該學(xué)生的預(yù)約記錄); } if (reservation.getStatus() ReserveStatus.CHECKED.getCode()) { return CheckResult.fail(該學(xué)生已簽到請勿重復(fù)操作); } if (reservation.getStatus() ReserveStatus.CANCELED.getCode()) { return CheckResult.fail(該學(xué)生的預(yù)約已取消); } // 3. 更新簽到狀態(tài) reservation.setStatus(ReserveStatus.CHECKED.getCode()); reservation.setCheckTime(now); reservationMapper.updateById(reservation); return CheckResult.success(); }簽到狀態(tài)的變化會聯(lián)動講座表的一個統(tǒng)計字段實際到場人數(shù)。講座結(jié)束后管理員把這些到場人數(shù)對比預(yù)約人數(shù)就能得出到場率。這個數(shù)據(jù)在學(xué)期末做第二課堂學(xué)分認定時很有用。4.4 管理端講座發(fā)布與審核管理端的核心操作是講座的發(fā)布與審核。主講人提交講座申請后需要院系管理員審核。審核通過后講座狀態(tài)變?yōu)椤翱深A(yù)約”系統(tǒng)會給學(xué)生推送消息如果有消息模塊的話。審核的操作很簡單就是一個update操作但審核后有一個關(guān)鍵動作初始化預(yù)約時間窗口。在講座表里reserve_start_time和reserve_end_time這兩個字段是在審核通過時由系統(tǒng)自動設(shè)置的。默認情況下預(yù)約開始時間是審核通過時刻預(yù)約截止時間是講座開始前2小時。這樣設(shè)計的考慮是主講人提前一周提交申請管理員審核通過后立即開放預(yù)約到講座開始前2小時截止讓學(xué)生能從容安排時間。如果某個院系想設(shè)置自定義的預(yù)約窗口也可以在審核頁面手動修改。審核這里還有一個細節(jié)講座狀態(tài)是“待審核”時學(xué)生端是看不到這條講座的。我第一版沒注意結(jié)果學(xué)生端把待審核的講座也展示出來了學(xué)生點了預(yù)約結(jié)果提示“講座暫未開放預(yù)約”搞得大家一頭霧水。后來我在查詢講座列表時加了一個過濾條件學(xué)生端只能看到status為1可預(yù)約和2已截止的講座避免數(shù)據(jù)混亂。5. 前端頁面與交互設(shè)計思路5.1 頁面結(jié)構(gòu)與路由組織這個系統(tǒng)我做了兩個端管理端和學(xué)生端。管理端的頁面比較重用了Vue加Element UI典型的后臺管理布局左側(cè)菜單頂部導(dǎo)航中間內(nèi)容區(qū)。菜單包括講座管理、預(yù)約管理、用戶管理、統(tǒng)計報表、系統(tǒng)設(shè)置。學(xué)生端則輕量很多用Thymeleaf模板渲染頁面包括首頁講座列表、講座詳情、我的預(yù)約、個人中心。學(xué)生端的講座列表頁是整個系統(tǒng)訪問量最高的頁面必須做分頁。我一開始做的是全量查詢結(jié)果講座多了以后頁面加載明顯變慢后來改成了MyBatis Plus自帶的分頁插件每頁10條配合標題模糊搜索和時間排序體驗就好多了。列表頁每個講座卡片上要展示講座標題、主講人、時間、地點、剩余名額。剩余名額這個字段很關(guān)鍵它會刺激學(xué)生的緊迫感也是預(yù)約轉(zhuǎn)化率的重要推動因素。講座詳情頁則需要更完整的信息講座簡介、主講人背景、內(nèi)容大綱、往期評價如果有的話。頁面上最重要的按鈕是“立即預(yù)約”這個按鈕不是永遠可點的要根據(jù)講座狀態(tài)動態(tài)變灰或變紅。狀態(tài)為“可預(yù)約”且當前時間在預(yù)約窗口內(nèi)按鈕顯示“立即預(yù)約”名額滿了顯示“已滿員”預(yù)約截止了顯示“預(yù)約已結(jié)束”講座已完成顯示“查看回放”如果沒有回放就顯示“已結(jié)束”。這些狀態(tài)判斷在前端做一次后端接口再做一次雙保險。5.2 移動端適配與用戶體驗必須強調(diào)學(xué)生端一定要優(yōu)先考慮移動端體驗?，F(xiàn)在大學(xué)生基本都是用手機刷講座信息沒人會打開電腦登錄系統(tǒng)去預(yù)約。我在第二版改版時專門把學(xué)生端做成了響應(yīng)式布局Bootstrap柵格系統(tǒng)搭配媒體查詢讓頁面在手機瀏覽器上能流暢操作。具體來說幾個關(guān)鍵頁面的移動端適配方案講座列表卡片式設(shè)計一張卡片就是一整屏寬度的信息塊標題在頂部中間是講座信息底部是預(yù)約按鈕。講座詳情頭部大標題下方時間地點信息用圖標加文字排列簡介部分可折疊默認只顯示兩行點擊展開。我的預(yù)約用Tab切換“已預(yù)約”“已簽到”“已取消”“爽約記錄”四類每條記錄展示講座信息、狀態(tài)標簽和操作按鈕取消預(yù)約、查看電子票。還有一個小細節(jié)預(yù)約按鈕的點擊反饋要即時。我加了按鈕防重復(fù)點擊的機制前端通過disabled屬性控制點擊一次后按鈕變成“處理中...”等接口響應(yīng)后再更新狀態(tài)。不然學(xué)生們連點五下后端就要處理五次請求雖然事務(wù)能兜底但日志里全是重復(fù)操作的記錄排查問題時看著就心煩。6. 常見問題與排查技巧實錄6.1 并發(fā)預(yù)約導(dǎo)致的超賣問題第一個要說的坑肯定是超賣。我上面雖然講了原子扣減的寫法但第一次上線時用的就是經(jīng)典的“先查后寫”結(jié)果就被現(xiàn)實教育了。當時某學(xué)院發(fā)布了一場知名校友的講座開放預(yù)約后幾十秒內(nèi)就涌入幾百個請求后臺日志里出現(xiàn)了reserved_count超過capacity的情況一條講座數(shù)據(jù)被預(yù)約了201人容量只有200。排查過程是這樣的打開后臺日志搜索對應(yīng)講座的預(yù)約操作記錄發(fā)現(xiàn)同一秒內(nèi)有三個請求都查到了reserved_count199都滿足了小于200的條件然后依次執(zhí)行了更新和插入。雖然每條記錄都成功了但庫存已經(jīng)超了。解決方式就是前面提到的把“查詢更新”合并成一條原子UPDATE語句。改完之后我又加了一個保險在插入預(yù)約記錄前先用聯(lián)合唯一索引做一次捕獲如果插重復(fù)了就報錯回滾雙保險更穩(wěn)。6.2 事務(wù)失效的場景說到事務(wù)很多人只知道在方法上加Transactional注解但注解不是萬能的。我遇到過事務(wù)不生效的情況排查了好久才發(fā)現(xiàn)原因方法內(nèi)部自己調(diào)了自己。Spring的事務(wù)代理機制是基于AOP的只有通過代理對象調(diào)用方法時事務(wù)注解才會生效。如果你在一個Service方法里直接調(diào)用同一個類的另一個帶事務(wù)注解的方法事務(wù)是不會啟用的因為調(diào)用的是this對象的方法沒有走代理。那個場景是這樣的我在Service里寫了一個公開方法createLectureAndPublish它調(diào)用了同一個類里的createLecture方法該方法上有Transactional注解。結(jié)果createLecture里的操作沒被事務(wù)管理哪怕拋了異常前面插入的數(shù)據(jù)也不會回滾。解決辦法有兩個要么把需要事務(wù)的方法拆到另一個Service類里要么在調(diào)用時通過Spring注入的代理對象調(diào)用。我選擇了拆類的方案更清晰也更符合單一職責。另外還有一個容易踩的坑事務(wù)方法內(nèi)部catch了異常不往外拋。事務(wù)回滾的觸發(fā)條件是異常傳播超過了事務(wù)邊界如果你在方法內(nèi)部把異常吞掉了事務(wù)自然認為一切正常不會回滾。所以catch塊里至少要拋出RuntimeException或者用rollbackFor顯式指定回滾的異常類型。6.3 狀態(tài)不一致的現(xiàn)場還原還有一個數(shù)據(jù)一致性問題是簽到和預(yù)約統(tǒng)計對不上。有一次管理員反饋某場講座預(yù)約顯示了180人但實際簽到表只有120人差了整整60人。我第一反應(yīng)是簽到功能有bug但查了半天代碼邏輯沒問題。后來發(fā)現(xiàn)原因在業(yè)務(wù)規(guī)則上系統(tǒng)允許學(xué)生在講座開始前取消預(yù)約取消后reserved_count會減1但講座的“實際到場人數(shù)”統(tǒng)計的是簽到表中狀態(tài)為“已簽到”的記錄。所以預(yù)約人數(shù)180人包含了中途取消又新增的預(yù)約實際到場120人是最終的簽到人數(shù)兩者之間沒有直接關(guān)系。這不是bug是統(tǒng)計口徑的問題。解決方案是在統(tǒng)計報表里分別展示“累計預(yù)約人次”“當前有效預(yù)約人數(shù)”“實際簽到人數(shù)”“取消次數(shù)”“爽約次數(shù)”五個指標讓管理員根據(jù)自己的需要選擇使用哪個口徑。同時在報表頁面加了一個文字說明解釋每個指標的計算方式避免再被當成bug提過來。6.4 常見問題速查表問題現(xiàn)象可能原因解決方案預(yù)約人數(shù)超容量查詢和更新非原子操作改用UPDATE原子扣減SQL事務(wù)不起作用同類內(nèi)部方法調(diào)用拆分Service類或使用代理對象調(diào)用用戶能重復(fù)預(yù)約一場講座業(yè)務(wù)校驗遺漏加聯(lián)合唯一索引兜底學(xué)生端可以看到待審核講座查詢過濾條件缺失列表查詢條件限制status范圍簽到時間判斷不準確時區(qū)或DateFormat問題統(tǒng)一用服務(wù)器時區(qū)傳參用時間戳預(yù)約了但名單上沒有預(yù)約記錄被誤刪用狀態(tài)標記替代物理刪除同一個時間段預(yù)約了多場講座沖突檢測邏輯缺失加區(qū)間重疊檢測SQL管理員導(dǎo)出名單亂碼Excel工具類未設(shè)置編碼使用EasyExcel并指定UTF-8提示排查問題的時候不要一上來就去看代碼先復(fù)現(xiàn)問題、確認現(xiàn)象再根據(jù)現(xiàn)象反推代碼路徑。很多“bug”其實是使用方式和業(yè)務(wù)口徑的問題先和提出方對齊需求能省下大量無用功。我個人在實際操作中的體會是這個系統(tǒng)的技術(shù)難度其實不大真正的難點在于把業(yè)務(wù)規(guī)則想清楚然后把數(shù)據(jù)模型設(shè)計得足夠穩(wěn)。很多看起來很復(fù)雜的功能比如并發(fā)預(yù)約、時間沖突檢測、簽到統(tǒng)計本質(zhì)上都是幾個字段和幾條SQL的事。反而是那些不起眼的小細節(jié)——預(yù)約窗口的時間控制、狀態(tài)流轉(zhuǎn)的約束、統(tǒng)計口徑的統(tǒng)一——決定了整個系統(tǒng)好不好用。后面如果要擴展可以在這個基礎(chǔ)上加消息推送預(yù)約成功通知、講座開始前提醒、講座評價打分、線上直播鏈接集成甚至對接學(xué)校的統(tǒng)一身份認證那基本上就是一個貼近生產(chǎn)的完整平臺了。你可以先把核心流程跑通再根據(jù)實際反饋迭代這是做這類管理系統(tǒng)最務(wù)實的一條路。 Spring Boot高校講座預(yù)約系統(tǒng)開發(fā)實戰(zhàn)：并發(fā)控制、數(shù)據(jù)庫與狀態(tài)流轉(zhuǎn)
1. 項目核心思路與需求拆解1.1 高校講座預(yù)約的真實痛點先講個身邊的場景。某高校每學(xué)期都會安排幾十場講座涵蓋學(xué)術(shù)前沿、就業(yè)指導(dǎo)、心理健康、通識素養(yǎng)等方向。以前是怎么管的學(xué)生會發(fā)通知大家到現(xiàn)場排隊簽到熱門講座經(jīng)常出現(xiàn)兩種情況一是報告廳擠爆了過道里都站滿人消防通道都被堵住二是某些冷門講座來了不到三分之一臺上專家講得尷尬臺下學(xué)生玩手機。后來有人嘗試用在線文檔接龍報名但信息混亂、容易串改、無法統(tǒng)計到場率管理員光是核對名單就要花小半天。這個系統(tǒng)的核心價值就是把“講座預(yù)約”這件事從人工排隊和Excel表里解放出來形成一個學(xué)生在線預(yù)約、后臺統(tǒng)一管理、簽到數(shù)據(jù)自動統(tǒng)計的閉環(huán)。它不是一個花里胡哨的Demo而是真正能部署到校醫(yī)院、圖書館報告廳、教學(xué)樓多媒體教室這類場景里用的管理系統(tǒng)。目標用戶很明確學(xué)生、教師講座主講人、院系管理員、系統(tǒng)超級管理員四類角色。面向的學(xué)生可能幾千人甚至上萬人所以并發(fā)預(yù)約不能被一個簡單的開關(guān)按鈕帶崩。從技術(shù)上我選了Spring Boot作為后端框架配合MyBatis Plus操作數(shù)據(jù)庫前端用Vue或者Thymeleaf模板引擎做頁面。數(shù)據(jù)庫用MySQL部署在服務(wù)器上用Maven打包成jar直接跑。整套技術(shù)棧不新但勝在穩(wěn)定、資料多、團隊協(xié)作時上手快學(xué)生開發(fā)者照著官方文檔也能七天落地。1.2 角色劃分與核心業(yè)務(wù)流程這個系統(tǒng)不是孤立的預(yù)約工具它要覆蓋講座從發(fā)布到結(jié)束的完整生命周期。我們梳理下來核心角色分成四類學(xué)生用戶瀏覽講座列表、查看詳情、在線預(yù)約、取消預(yù)約、講座簽到、查看自己的預(yù)約記錄和學(xué)分/學(xué)時累計。講座主講人教師提交講座申請?zhí)顚懼黝}、內(nèi)容簡介、時間、地點、容量等信息查看自己講座的預(yù)約情況和到場率。院系管理員審核主講人提交的講座申請排定講座計劃查看本院系的預(yù)約數(shù)據(jù)統(tǒng)計導(dǎo)出參與名單。系統(tǒng)超級管理員維護基礎(chǔ)數(shù)據(jù)教室、時間段、管理用戶和角色權(quán)限、處理異常數(shù)據(jù)、查看全局統(tǒng)計報表。核心流程其實只有一條主線主講人提交講座申請管理員審核通過后講座狀態(tài)變?yōu)椤翱深A(yù)約”學(xué)生在預(yù)約開放時間內(nèi)搶名額講座開始前或現(xiàn)場進行簽到講座結(jié)束后管理員確認講座完成并統(tǒng)計實際到場人數(shù)。整個流程里有一個容易被忽略的細節(jié)預(yù)約不是無限開放的必須區(qū)分“預(yù)約開始時間”和“預(yù)約截止時間”否則學(xué)生會提前好幾天把名額占滿后面想聽的人進不來。這個需求我在第一版設(shè)計時漏掉了結(jié)果被某院系老師反饋“學(xué)生下午四點半的講座凌晨十二點就把票搶光了”后來才補上預(yù)約窗口的字段。1.3 功能邊界與優(yōu)先級取舍很多人做管理系統(tǒng)容易犯一個毛病啥功能都想加結(jié)果代碼一團亂麻。我理功能清單的時候把需求分成“必須有”和“可以有”兩檔。必須有登錄認證、角色權(quán)限控制、講座CRUD、預(yù)約/取消、簽到、預(yù)約記錄查詢、用戶管理、基礎(chǔ)數(shù)據(jù)統(tǒng)計?？梢杂械珒?yōu)先級低消息通知站內(nèi)信、郵件、二維碼電子票、黑名單機制、講座評價、打印簽到表、數(shù)據(jù)導(dǎo)出Excel。實際開發(fā)中我建議把二維碼電子票和Excel導(dǎo)出放到第二階段。不是說不重要而是第一版先把預(yù)約主流程跑通讓學(xué)生能約、管理員能統(tǒng)計這就是上線的最小可用閉環(huán)。我們第一版上線時連二維碼都沒做簽到用的是管理員手機端搜索學(xué)號手工確認雖然原始了一點但核心數(shù)據(jù)鏈路已經(jīng)走通了。后來第二版加了二維碼簽到入場速度從每人20秒降到了3秒體驗差異非常明顯。2. 技術(shù)選型與架構(gòu)設(shè)計解析2.1 為什么是Spring Boot而非其他方案我遇到過不少同學(xué)問為什么不用PHP或者Node.js甚至有人建議用Python的Flask。我的回答是Spring Boot在這個場景下不是“最好”的但它是“最不容易出錯”的。首先高校里的系統(tǒng)往往要運行很多年維護的人可能是下一屆的學(xué)生、另一個部門的老師甚至外包團隊。Spring Boot加Java的技術(shù)棧是市場保有量最大的接手的人大概率見過這類代碼不至于完全看不懂。其次Spring Boot的生態(tài)太完整了做權(quán)限有Spring Security做接口文檔有Knife4j做數(shù)據(jù)庫操作有MyBatis Plus出問題百度一搜全是解決方案。最后高校系統(tǒng)通常部署在校內(nèi)服務(wù)器環(huán)境多半是老舊的CentOS或者Windows ServerJava的跨平臺能力在這種環(huán)境下非常省心一個JDK加一個Jar包就完事了。對比一下其他方案的短板技術(shù)方案優(yōu)勢在本項目中的短板PHP部署簡單、上手快長期維護的代碼規(guī)范性往往不如Spring體系復(fù)雜業(yè)務(wù)邏輯容易寫成面條代碼Node.js高并發(fā)IO能力強高校運維團隊對Node生態(tài)相對陌生部署和排障成本高Flask輕量靈活缺乏完整的權(quán)限、事務(wù)、ORM生態(tài)做管理系統(tǒng)需要自己拼裝太多零件2.2 整體技術(shù)棧構(gòu)成這個項目的技術(shù)棧我可以直接列出來都是很主流的組合JDK 8我用的是JDK 8穩(wěn)定且兼容性好新項目也可以直接上JDK 17Spring Boot 2.7.x3.x也OK但要注意部分第三方starter的兼容性MyBatis Plus 3.5.x單表CRUD幾乎不需要寫SQL節(jié)省大量時間MySQL 5.7或8.08.0的窗口函數(shù)做統(tǒng)計非常方便Redis用于緩存講座列表和分布式鎖如果數(shù)據(jù)量不大也可以先不引入Vue 2 Element UI前端管理端學(xué)生端我用的是Thymeleaf加Bootstrap因為學(xué)生端的頁面比較輕不需要太大的前端工程Maven依賴管理和打包這套組合的核心思路是后端業(yè)務(wù)邏輯用Spring Boot的依賴注入和事務(wù)管理來組織數(shù)據(jù)庫操作交給MyBatis Plus減少樣板代碼緩存和鎖用Redis解決熱點數(shù)據(jù)的并發(fā)問題。比如講座詳情頁會被頻繁刷新第一次查完放進Redis后面直接命中緩存數(shù)據(jù)庫的壓力會大大降低。2.3 工程結(jié)構(gòu)與分層設(shè)計工程結(jié)構(gòu)上我采用了經(jīng)典的四層架構(gòu)沒有過度設(shè)計。如果你拉過太多開源項目會發(fā)現(xiàn)很多人喜歡建一堆模塊結(jié)果一個幾百兆的小項目拆成七八個Maven子模塊看起來高大上實際維護起來想哭。我建議用單模塊加包名分層的方案簡單直接的代碼樹com.example.lecture ├── controller // 接口入口只做參數(shù)接收和結(jié)果封裝 ├── service // 業(yè)務(wù)邏輯層事務(wù)邊界都在這一層 │ └── impl ├── mapper // MyBatis Plus的Mapper接口 ├── entity // 數(shù)據(jù)庫實體類 ├── dto // 前端交互的數(shù)據(jù)傳輸對象 ├── vo // 視圖對象聚合多表查詢結(jié)果 ├── config // 配置類Redis、攔截器、跨域等 ├── common // 通用工具類、統(tǒng)一返回結(jié)果、異常處理 └── enums // 狀態(tài)枚舉分層設(shè)計最重要的一個原則Controller只做參數(shù)校驗和調(diào)用Service不要在里面寫業(yè)務(wù)邏輯。我見過太多人把查詢數(shù)據(jù)庫的代碼寫在Controller里導(dǎo)致后面想復(fù)用邏輯的時候只能復(fù)制粘貼。Service層的每個方法代表一個完整的業(yè)務(wù)動作方法上標注事務(wù)注解。DTO和VO分開的好處是數(shù)據(jù)庫字段變化不會直接暴露給前端接口。舉個例子講座實體類里有“備注”字段但前端展示時不需要這個字段VO里不包含就可以了返回給用戶的JSON就干干凈凈。3. 數(shù)據(jù)庫設(shè)計與核心表結(jié)構(gòu)3.1 概念模型與ER分析數(shù)據(jù)庫設(shè)計是整個項目的基石表結(jié)構(gòu)沒設(shè)計好后面寫業(yè)務(wù)代碼就是在爛地基上蓋樓。我畫ER圖時先列出核心實體用戶、講座、預(yù)約記錄、教室/場地、學(xué)院。關(guān)系也很清晰一個用戶學(xué)生可以預(yù)約多個講座一個講座可以被多個用戶預(yù)約這是典型的多對多關(guān)系通過中間表“預(yù)約記錄表”來解除多對多關(guān)聯(lián)。講座與教室是多對一教室與學(xué)院是一對多。這里有一個建模時容易犯的錯誤把預(yù)約人數(shù)當成字段直接存在講座表里比如reserved_count而不是通過預(yù)約記錄表實時count。如果并發(fā)量不大直接count也能用但每次查詢都要全表聯(lián)合統(tǒng)計數(shù)據(jù)庫會很吃力。我的做法是在講座表里維護一個冗余字段reserved_count預(yù)約成功時加1取消預(yù)約時減1。這種用空間換時間的做法在中小型系統(tǒng)里非常實用配合事務(wù)控制數(shù)據(jù)一致性是可以保證的。3.2 核心表結(jié)構(gòu)詳解直接上核心建表SQL這幾個表就是系統(tǒng)的骨架CREATE TABLE sys_user ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主鍵ID, username varchar(50) NOT NULL COMMENT 登錄賬號學(xué)號或工號, password varchar(100) NOT NULL COMMENT 加密后的密碼, real_name varchar(50) NOT NULL COMMENT 真實姓名, role tinyint(4) NOT NULL DEFAULT 1 COMMENT 角色1學(xué)生 2教師 3院系管理員 4系統(tǒng)管理員, college_id bigint(20) DEFAULT NULL COMMENT 所屬學(xué)院ID, phone varchar(20) DEFAULT NULL COMMENT 手機號, email varchar(100) DEFAULT NULL COMMENT 郵箱, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 狀態(tài)1正常 0禁用, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 創(chuàng)建時間, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用戶表;CREATE TABLE lecture ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主鍵ID, title varchar(200) NOT NULL COMMENT 講座標題, speaker varchar(50) NOT NULL COMMENT 主講人姓名, speaker_intro varchar(500) DEFAULT NULL COMMENT 主講人簡介, content text COMMENT 講座內(nèi)容簡介, location varchar(100) NOT NULL COMMENT 講座地點, start_time datetime NOT NULL COMMENT 開始時間, end_time datetime NOT NULL COMMENT 結(jié)束時間, reserve_start_time datetime NOT NULL COMMENT 預(yù)約開始時間, reserve_end_time datetime NOT NULL COMMENT 預(yù)約截止時間, capacity int(11) NOT NULL DEFAULT 0 COMMENT 最大可預(yù)約人數(shù), reserved_count int(11) NOT NULL DEFAULT 0 COMMENT 已預(yù)約人數(shù), status tinyint(4) NOT NULL DEFAULT 0 COMMENT 狀態(tài)0待審核 1已審核/可預(yù)約 2已截止 3已完成 4已取消, creator_id bigint(20) NOT NULL COMMENT 創(chuàng)建人主講人ID, audit_remark varchar(200) DEFAULT NULL COMMENT 審核備注, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 創(chuàng)建時間, update_time datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT 更新時間, PRIMARY KEY (id), KEY idx_start_time (start_time), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT講座表;CREATE TABLE reservation ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主鍵ID, lecture_id bigint(20) NOT NULL COMMENT 講座ID, user_id bigint(20) NOT NULL COMMENT 用戶ID, reserve_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 預(yù)約時間, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 狀態(tài)0已預(yù)約 1已簽到 2已取消 3爽約, check_time datetime DEFAULT NULL COMMENT 簽到時間, source tinyint(4) DEFAULT 0 COMMENT 來源0網(wǎng)頁 1移動端, PRIMARY KEY (id), UNIQUE KEY uk_lecture_user (lecture_id, user_id), KEY idx_user_id (user_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT預(yù)約記錄表;這三張表是核心其他表比如學(xué)院表、教室表、操作日志表就按常規(guī)設(shè)計。需要注意的有幾點第一預(yù)約記錄表里的聯(lián)合唯一索引uk_lecture_user它的作用是防止同一個人對同一場講座重復(fù)預(yù)約這是數(shù)據(jù)庫層面的最后一道防線即使業(yè)務(wù)邏輯有bug這條索引也能攔住臟數(shù)據(jù)。第二所有表的主鍵都用bigint自增不用雪花算法也不用UUID因為并發(fā)量沒那么大自增主鍵在InnoDB里性能和存儲上都更好。第三狀態(tài)字段用tinyint而不是varchar省空間、查詢快配合項目里的枚舉類做對應(yīng)映射可讀性也不差。3.3 狀態(tài)字段設(shè)計的重要性狀態(tài)字段在整個系統(tǒng)里扮演的角色比我最初設(shè)想的更重要。講座表里的status字段我特意設(shè)計了從0到4五個狀態(tài)值分別對應(yīng)待審核、已審核可預(yù)約、已截止、已完成、已取消。每個狀態(tài)的流轉(zhuǎn)方向是有約束的比如“已完成”的講座不能再變回“可預(yù)約”“已取消”的講座不允許再被預(yù)約。這就像現(xiàn)實中的流程一樣講座一旦結(jié)束數(shù)據(jù)就是歷史數(shù)據(jù)不能隨便改。預(yù)約記錄表的status字段也有講究0已預(yù)約、1已簽到、2已取消、3爽約。區(qū)分“已取消”和“爽約”特別重要因為很多高校會把講座考勤納入第二課堂學(xué)分或綜合素質(zhì)評價。如果學(xué)生預(yù)約了但沒去系統(tǒng)應(yīng)該記錄為“爽約”而不是簡簡單單刪除記錄。后來做統(tǒng)計報表時這個設(shè)計的價值就體現(xiàn)出來了輔導(dǎo)員可以直接看到每個學(xué)生的爽約次數(shù)不再需要人工翻聊天記錄。4. 核心功能實現(xiàn)與關(guān)鍵代碼解析4.1 預(yù)約流程控制與庫存扣減預(yù)約是整個系統(tǒng)最核心的接口也是并發(fā)壓力最大的地方。想象一下一場熱門講座放出來200個名額學(xué)生們在同一時間點瘋狂點擊預(yù)約按鈕如果代碼寫得不對超出了預(yù)約數(shù)量上限超賣問題就來了。我見過很多新手寫的預(yù)約邏輯是這樣的先查講座的reserved_count判斷是否小于capacity如果小于就加1然后插入預(yù)約記錄。這代碼表面上邏輯沒問題但在高并發(fā)下會出大問題。兩個請求同時查到reserved_count199都判斷小于200于是都執(zhí)行了加1操作結(jié)果reserved_count變成了201超出了容量限制。為什么會這樣因為查詢和更新之間不是一個原子操作中間有間隙。正確的做法是利用數(shù)據(jù)庫的行鎖或樂觀鎖機制。我推薦的做法是直接在SQL層面做原子扣減Transactional(rollbackFor Exception.class) public ReserveResult reserveLecture(ReserveRequest request) { // 1. 校驗講座存在且狀態(tài)為可預(yù)約 Lecture lecture lectureMapper.selectById(request.getLectureId()); if (lecture null || lecture.getStatus() ! LectureStatus.REVIEWED.getCode()) { return ReserveResult.fail(講座不存在或不在預(yù)約時間內(nèi)); } // 2. 核心原子扣減庫存條件里帶上 reserved_count capacity int updateRows lectureMapper.reduceStock(request.getLectureId()); if (updateRows 0) { return ReserveResult.fail(手速慢了名額已被搶完); } // 3. 再插入預(yù)約記錄 Reservation reservation new Reservation(); reservation.setLectureId(request.getLectureId()); reservation.setUserId(request.getUserId()); reservation.setStatus(ReserveStatus.RESERVED.getCode()); reservationMapper.insert(reservation); return ReserveResult.success(); }對應(yīng)的Mapper SQLupdate idreduceStock UPDATE lecture SET reserved_count reserved_count 1 WHERE id #{lectureId} AND status 1 AND reserved_count lt; capacity /update這個update語句利用了MySQL的行鎖機制當多個事務(wù)同時更新同一行數(shù)據(jù)時它們會排隊執(zhí)行后執(zhí)行的事務(wù)會基于前一個事務(wù)更新后的值重新判斷條件。如果reserved_count已經(jīng)等于capacity了條件reserved_count capacity就不成立了影響行數(shù)為0說明名額搶完了。這種方式既保證了不超賣又不需要手動加鎖性能和安全性兼顧。4.2 沖突檢測同一時間段多講座另一個容易被忽略的需求是同一個學(xué)生能不能同時預(yù)約兩個時間重疊的講座從情理上講學(xué)生是不能分身同時出現(xiàn)在兩個會場的所以系統(tǒng)應(yīng)該阻止這種沖突。實現(xiàn)思路也簡單在插入預(yù)約記錄之前先查一下該用戶已預(yù)約且狀態(tài)為“已預(yù)約”或“已簽到”的講座看其中是否有與新講座時間重疊的記錄。Transactional(rollbackFor Exception.class) public ReserveResult reserveLecture(ReserveRequest request) { // ... 省略前面的庫存校驗邏輯 ... // 新增時間沖突檢測 Lecture newLecture lectureMapper.selectById(request.getLectureId()); ListLecture userLectures lectureMapper.selectOverlappingLectures( request.getUserId(), newLecture.getStartTime(), newLecture.getEndTime(), Arrays.asList(ReserveStatus.RESERVED.getCode(), ReserveStatus.CHECKED.getCode()) ); if (!userLectures.isEmpty()) { return ReserveResult.fail(您已預(yù)約了時間沖突的講座 userLectures.get(0).getTitle()); } }對應(yīng)的SQLSELECT DISTINCT l.* FROM reservation r INNER JOIN lecture l ON r.lecture_id l.id WHERE r.user_id #{userId} AND r.status IN (0, 1) AND l.status IN (1, 2) AND NOT (#{newEndTime} lt; l.start_time OR #{newStartTime} l.end_time)這個“NOT (結(jié)束時間小于等于對方開始時間 或 開始時間大于等于對方結(jié)束時間)”的判斷就是區(qū)間重疊檢測的經(jīng)典寫法涵蓋了包含、被包含、交叉等所有重疊情況。4.3 簽到邏輯與狀態(tài)流轉(zhuǎn)簽到功能在第二版才加入二維碼。管理員手機上打開一個小程序頁面其實就是一個適配移動端的網(wǎng)頁掃描學(xué)生出示的二維碼識別學(xué)號后調(diào)用簽到接口。簽到接口的邏輯不復(fù)雜Transactional(rollbackFor Exception.class) public CheckResult checkIn(CheckInRequest request) { // 1. 判斷當前時間是否在講座開始前30分鐘到結(jié)束后1小時之間 Lecture lecture lectureMapper.selectById(request.getLectureId()); Date now new Date(); if (now.before(DateUtil.addMinutes(lecture.getStartTime(), -30)) || now.after(DateUtil.addHours(lecture.getEndTime(), 1))) { return CheckResult.fail(不在簽到時間段內(nèi)); } // 2. 查詢預(yù)約記錄 Reservation reservation reservationMapper.selectByLectureIdAndUserId( request.getLectureId(), request.getUserId()); if (reservation null) { return CheckResult.fail(未查詢到該學(xué)生的預(yù)約記錄); } if (reservation.getStatus() ReserveStatus.CHECKED.getCode()) { return CheckResult.fail(該學(xué)生已簽到請勿重復(fù)操作); } if (reservation.getStatus() ReserveStatus.CANCELED.getCode()) { return CheckResult.fail(該學(xué)生的預(yù)約已取消); } // 3. 更新簽到狀態(tài) reservation.setStatus(ReserveStatus.CHECKED.getCode()); reservation.setCheckTime(now); reservationMapper.updateById(reservation); return CheckResult.success(); }簽到狀態(tài)的變化會聯(lián)動講座表的一個統(tǒng)計字段實際到場人數(shù)。講座結(jié)束后管理員把這些到場人數(shù)對比預(yù)約人數(shù)就能得出到場率。這個數(shù)據(jù)在學(xué)期末做第二課堂學(xué)分認定時很有用。4.4 管理端講座發(fā)布與審核管理端的核心操作是講座的發(fā)布與審核。主講人提交講座申請后需要院系管理員審核。審核通過后講座狀態(tài)變?yōu)椤翱深A(yù)約”系統(tǒng)會給學(xué)生推送消息如果有消息模塊的話。審核的操作很簡單就是一個update操作但審核后有一個關(guān)鍵動作初始化預(yù)約時間窗口。在講座表里reserve_start_time和reserve_end_time這兩個字段是在審核通過時由系統(tǒng)自動設(shè)置的。默認情況下預(yù)約開始時間是審核通過時刻預(yù)約截止時間是講座開始前2小時。這樣設(shè)計的考慮是主講人提前一周提交申請管理員審核通過后立即開放預(yù)約到講座開始前2小時截止讓學(xué)生能從容安排時間。如果某個院系想設(shè)置自定義的預(yù)約窗口也可以在審核頁面手動修改。審核這里還有一個細節(jié)講座狀態(tài)是“待審核”時學(xué)生端是看不到這條講座的。我第一版沒注意結(jié)果學(xué)生端把待審核的講座也展示出來了學(xué)生點了預(yù)約結(jié)果提示“講座暫未開放預(yù)約”搞得大家一頭霧水。后來我在查詢講座列表時加了一個過濾條件學(xué)生端只能看到status為1可預(yù)約和2已截止的講座避免數(shù)據(jù)混亂。5. 前端頁面與交互設(shè)計思路5.1 頁面結(jié)構(gòu)與路由組織這個系統(tǒng)我做了兩個端管理端和學(xué)生端。管理端的頁面比較重用了Vue加Element UI典型的后臺管理布局左側(cè)菜單頂部導(dǎo)航中間內(nèi)容區(qū)。菜單包括講座管理、預(yù)約管理、用戶管理、統(tǒng)計報表、系統(tǒng)設(shè)置。學(xué)生端則輕量很多用Thymeleaf模板渲染頁面包括首頁講座列表、講座詳情、我的預(yù)約、個人中心。學(xué)生端的講座列表頁是整個系統(tǒng)訪問量最高的頁面必須做分頁。我一開始做的是全量查詢結(jié)果講座多了以后頁面加載明顯變慢后來改成了MyBatis Plus自帶的分頁插件每頁10條配合標題模糊搜索和時間排序體驗就好多了。列表頁每個講座卡片上要展示講座標題、主講人、時間、地點、剩余名額。剩余名額這個字段很關(guān)鍵它會刺激學(xué)生的緊迫感也是預(yù)約轉(zhuǎn)化率的重要推動因素。講座詳情頁則需要更完整的信息講座簡介、主講人背景、內(nèi)容大綱、往期評價如果有的話。頁面上最重要的按鈕是“立即預(yù)約”這個按鈕不是永遠可點的要根據(jù)講座狀態(tài)動態(tài)變灰或變紅。狀態(tài)為“可預(yù)約”且當前時間在預(yù)約窗口內(nèi)按鈕顯示“立即預(yù)約”名額滿了顯示“已滿員”預(yù)約截止了顯示“預(yù)約已結(jié)束”講座已完成顯示“查看回放”如果沒有回放就顯示“已結(jié)束”。這些狀態(tài)判斷在前端做一次后端接口再做一次雙保險。5.2 移動端適配與用戶體驗必須強調(diào)學(xué)生端一定要優(yōu)先考慮移動端體驗?，F(xiàn)在大學(xué)生基本都是用手機刷講座信息沒人會打開電腦登錄系統(tǒng)去預(yù)約。我在第二版改版時專門把學(xué)生端做成了響應(yīng)式布局Bootstrap柵格系統(tǒng)搭配媒體查詢讓頁面在手機瀏覽器上能流暢操作。具體來說幾個關(guān)鍵頁面的移動端適配方案講座列表卡片式設(shè)計一張卡片就是一整屏寬度的信息塊標題在頂部中間是講座信息底部是預(yù)約按鈕。講座詳情頭部大標題下方時間地點信息用圖標加文字排列簡介部分可折疊默認只顯示兩行點擊展開。我的預(yù)約用Tab切換“已預(yù)約”“已簽到”“已取消”“爽約記錄”四類每條記錄展示講座信息、狀態(tài)標簽和操作按鈕取消預(yù)約、查看電子票。還有一個小細節(jié)預(yù)約按鈕的點擊反饋要即時。我加了按鈕防重復(fù)點擊的機制前端通過disabled屬性控制點擊一次后按鈕變成“處理中...”等接口響應(yīng)后再更新狀態(tài)。不然學(xué)生們連點五下后端就要處理五次請求雖然事務(wù)能兜底但日志里全是重復(fù)操作的記錄排查問題時看著就心煩。6. 常見問題與排查技巧實錄6.1 并發(fā)預(yù)約導(dǎo)致的超賣問題第一個要說的坑肯定是超賣。我上面雖然講了原子扣減的寫法但第一次上線時用的就是經(jīng)典的“先查后寫”結(jié)果就被現(xiàn)實教育了。當時某學(xué)院發(fā)布了一場知名校友的講座開放預(yù)約后幾十秒內(nèi)就涌入幾百個請求后臺日志里出現(xiàn)了reserved_count超過capacity的情況一條講座數(shù)據(jù)被預(yù)約了201人容量只有200。排查過程是這樣的打開后臺日志搜索對應(yīng)講座的預(yù)約操作記錄發(fā)現(xiàn)同一秒內(nèi)有三個請求都查到了reserved_count199都滿足了小于200的條件然后依次執(zhí)行了更新和插入。雖然每條記錄都成功了但庫存已經(jīng)超了。解決方式就是前面提到的把“查詢更新”合并成一條原子UPDATE語句。改完之后我又加了一個保險在插入預(yù)約記錄前先用聯(lián)合唯一索引做一次捕獲如果插重復(fù)了就報錯回滾雙保險更穩(wěn)。6.2 事務(wù)失效的場景說到事務(wù)很多人只知道在方法上加Transactional注解但注解不是萬能的。我遇到過事務(wù)不生效的情況排查了好久才發(fā)現(xiàn)原因方法內(nèi)部自己調(diào)了自己。Spring的事務(wù)代理機制是基于AOP的只有通過代理對象調(diào)用方法時事務(wù)注解才會生效。如果你在一個Service方法里直接調(diào)用同一個類的另一個帶事務(wù)注解的方法事務(wù)是不會啟用的因為調(diào)用的是this對象的方法沒有走代理。那個場景是這樣的我在Service里寫了一個公開方法createLectureAndPublish它調(diào)用了同一個類里的createLecture方法該方法上有Transactional注解。結(jié)果createLecture里的操作沒被事務(wù)管理哪怕拋了異常前面插入的數(shù)據(jù)也不會回滾。解決辦法有兩個要么把需要事務(wù)的方法拆到另一個Service類里要么在調(diào)用時通過Spring注入的代理對象調(diào)用。我選擇了拆類的方案更清晰也更符合單一職責。另外還有一個容易踩的坑事務(wù)方法內(nèi)部catch了異常不往外拋。事務(wù)回滾的觸發(fā)條件是異常傳播超過了事務(wù)邊界如果你在方法內(nèi)部把異常吞掉了事務(wù)自然認為一切正常不會回滾。所以catch塊里至少要拋出RuntimeException或者用rollbackFor顯式指定回滾的異常類型。6.3 狀態(tài)不一致的現(xiàn)場還原還有一個數(shù)據(jù)一致性問題是簽到和預(yù)約統(tǒng)計對不上。有一次管理員反饋某場講座預(yù)約顯示了180人但實際簽到表只有120人差了整整60人。我第一反應(yīng)是簽到功能有bug但查了半天代碼邏輯沒問題。后來發(fā)現(xiàn)原因在業(yè)務(wù)規(guī)則上系統(tǒng)允許學(xué)生在講座開始前取消預(yù)約取消后reserved_count會減1但講座的“實際到場人數(shù)”統(tǒng)計的是簽到表中狀態(tài)為“已簽到”的記錄。所以預(yù)約人數(shù)180人包含了中途取消又新增的預(yù)約實際到場120人是最終的簽到人數(shù)兩者之間沒有直接關(guān)系。這不是bug是統(tǒng)計口徑的問題。解決方案是在統(tǒng)計報表里分別展示“累計預(yù)約人次”“當前有效預(yù)約人數(shù)”“實際簽到人數(shù)”“取消次數(shù)”“爽約次數(shù)”五個指標讓管理員根據(jù)自己的需要選擇使用哪個口徑。同時在報表頁面加了一個文字說明解釋每個指標的計算方式避免再被當成bug提過來。6.4 常見問題速查表問題現(xiàn)象可能原因解決方案預(yù)約人數(shù)超容量查詢和更新非原子操作改用UPDATE原子扣減SQL事務(wù)不起作用同類內(nèi)部方法調(diào)用拆分Service類或使用代理對象調(diào)用用戶能重復(fù)預(yù)約一場講座業(yè)務(wù)校驗遺漏加聯(lián)合唯一索引兜底學(xué)生端可以看到待審核講座查詢過濾條件缺失列表查詢條件限制status范圍簽到時間判斷不準確時區(qū)或DateFormat問題統(tǒng)一用服務(wù)器時區(qū)傳參用時間戳預(yù)約了但名單上沒有預(yù)約記錄被誤刪用狀態(tài)標記替代物理刪除同一個時間段預(yù)約了多場講座沖突檢測邏輯缺失加區(qū)間重疊檢測SQL管理員導(dǎo)出名單亂碼Excel工具類未設(shè)置編碼使用EasyExcel并指定UTF-8提示排查問題的時候不要一上來就去看代碼先復(fù)現(xiàn)問題、確認現(xiàn)象再根據(jù)現(xiàn)象反推代碼路徑。很多“bug”其實是使用方式和業(yè)務(wù)口徑的問題先和提出方對齊需求能省下大量無用功。我個人在實際操作中的體會是這個系統(tǒng)的技術(shù)難度其實不大真正的難點在于把業(yè)務(wù)規(guī)則想清楚然后把數(shù)據(jù)模型設(shè)計得足夠穩(wěn)。很多看起來很復(fù)雜的功能比如并發(fā)預(yù)約、時間沖突檢測、簽到統(tǒng)計本質(zhì)上都是幾個字段和幾條SQL的事。反而是那些不起眼的小細節(jié)——預(yù)約窗口的時間控制、狀態(tài)流轉(zhuǎn)的約束、統(tǒng)計口徑的統(tǒng)一——決定了整個系統(tǒng)好不好用。后面如果要擴展可以在這個基礎(chǔ)上加消息推送預(yù)約成功通知、講座開始前提醒、講座評價打分、線上直播鏈接集成甚至對接學(xué)校的統(tǒng)一身份認證那基本上就是一個貼近生產(chǎn)的完整平臺了。你可以先把核心流程跑通再根據(jù)實際反饋迭代這是做這類管理系統(tǒng)最務(wù)實的一條路。