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