1. 選課系統(tǒng)為什么值得認(rèn)真做一遍學(xué)生選課系統(tǒng)這個(gè)題目幾乎每個(gè)計(jì)算機(jī)專業(yè)的學(xué)生都碰過(guò)招聘面試?yán)镆渤１荒脕?lái)當(dāng)場(chǎng)景題。但真正把它當(dāng)回事、按生產(chǎn)標(biāo)準(zhǔn)做一遍的人并不多。大多數(shù)人寫(xiě)出來(lái)的版本是一張學(xué)生表、一張課程表、一張選課記錄表Controller 里調(diào)一下 ServiceService 里查一下有沒(méi)有余量有就插入一條記錄完事。本地跑起來(lái)沒(méi)問(wèn)題一放到幾百人同時(shí)點(diǎn)選課的場(chǎng)面立刻出現(xiàn)超賣、重復(fù)選課、數(shù)據(jù)庫(kù)連接打滿。我前后做過(guò)三版選課系統(tǒng)第一版是課程設(shè)計(jì)交作業(yè)的水平第二版給一個(gè)學(xué)院內(nèi)部試用第三版才真正把并發(fā)問(wèn)題處理干凈。這篇文章就把這三版踩過(guò)的坑、改過(guò)的方案完整講一遍從數(shù)據(jù)建模講到高并發(fā)防超賣。技術(shù)棧用的是Spring Boot MySQL JPA這套組合上手快、生態(tài)成熟適合作為練手項(xiàng)目也足夠撐起一個(gè)真實(shí)可用的系統(tǒng)。文章適合三類人看正在做課程設(shè)計(jì)、想拿一個(gè)能寫(xiě)進(jìn)簡(jiǎn)歷的項(xiàng)目練手的同學(xué)準(zhǔn)備面試、需要把“高并發(fā)”從八股文變成能講清楚實(shí)戰(zhàn)細(xì)節(jié)的人以及已經(jīng)寫(xiě)過(guò)選課系統(tǒng)、但被超賣問(wèn)題卡住的開(kāi)發(fā)者。我會(huì)把每一步為什么這么做講透參數(shù)怎么算、鎖怎么加、索引怎么建都給出可以直接抄的代碼和配置?？赐曛竽銘?yīng)該能獨(dú)立復(fù)現(xiàn)一個(gè)扛得住并發(fā)選課的系統(tǒng)并且能說(shuō)清楚每個(gè)設(shè)計(jì)決策背后的理由。2. 整體架構(gòu)與數(shù)據(jù)建模思路2.1 為什么先定架構(gòu)再寫(xiě)代碼很多人一上來(lái)就打開(kāi) IDE 建 Spring Boot 工程邊寫(xiě)邊想表結(jié)構(gòu)結(jié)果寫(xiě)到一半發(fā)現(xiàn)字段不夠用回頭改表、改實(shí)體、改接口返工成本極高。選課系統(tǒng)雖然不大但它涉及的核心矛盾很典型讀多寫(xiě)少、寫(xiě)操作有強(qiáng)一致性要求、并發(fā)集中在少數(shù)熱門(mén)課程上。這三個(gè)特點(diǎn)決定了架構(gòu)和數(shù)據(jù)模型必須先想清楚。我的做法是先畫(huà)一張業(yè)務(wù)流轉(zhuǎn)圖在紙上畫(huà)就行不用工具學(xué)生登錄 → 瀏覽課程列表 → 點(diǎn)擊選課 → 系統(tǒng)校驗(yàn)資格與余量 → 扣減余量并生成選課記錄 → 返回結(jié)果。這條鏈路里真正需要保護(hù)的是“校驗(yàn)余量”和“扣減余量”這兩步它們必須是一個(gè)原子操作否則并發(fā)下必然超賣。想清楚這一點(diǎn)后面的技術(shù)選型就順了。分層上我采用經(jīng)典的 Controller → Service → Repository 三層但額外加了一層Domain Service專門(mén)處理選課這種跨實(shí)體的業(yè)務(wù)邏輯。這樣做的原因是選課邏輯既不屬于學(xué)生實(shí)體也不屬于課程實(shí)體硬塞進(jìn)任何一個(gè)實(shí)體里都會(huì)讓代碼變味。分層清晰之后單元測(cè)試也好寫(xiě)后面加緩存、加鎖都有明確的落點(diǎn)。2.2 數(shù)據(jù)表設(shè)計(jì)三張核心表加兩張輔助表選課系統(tǒng)的表不多但每張表的字段和索引都有講究。核心是三張學(xué)生表、課程表、選課記錄表。另外兩張輔助表是學(xué)期表和教師表看需求決定要不要。先看課程表這是并發(fā)爭(zhēng)搶的焦點(diǎn)CREATE TABLE course ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_code VARCHAR(32) NOT NULL COMMENT 課程編號(hào), course_name VARCHAR(128) NOT NULL COMMENT 課程名稱, teacher_id BIGINT NOT NULL COMMENT 授課教師, semester VARCHAR(32) NOT NULL COMMENT 學(xué)期, capacity INT NOT NULL DEFAULT 0 COMMENT 總?cè)萘? selected_count INT NOT NULL DEFAULT 0 COMMENT 已選人數(shù), version INT NOT NULL DEFAULT 0 COMMENT 樂(lè)觀鎖版本號(hào), status TINYINT NOT NULL DEFAULT 1 COMMENT 1開(kāi)放 0關(guān)閉, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_code_semester (course_code, semester), KEY idx_semester_status (semester, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;這里有幾個(gè)關(guān)鍵決策。第一容量和已選人數(shù)放在課程表里而不是每次去 count 選課記錄表。count 操作在并發(fā)下既慢又容易讀到不一致的數(shù)據(jù)用一個(gè)冗余字段selected_count直接維護(hù)配合事務(wù)保證一致性性能好得多。第二加了version字段用于樂(lè)觀鎖這是防超賣的核心手段之一。第三uk_code_semester唯一索引保證同一學(xué)期同一課程編號(hào)不重復(fù)idx_semester_status支撐按學(xué)期查開(kāi)放課程的常見(jiàn)查詢。選課記錄表的設(shè)計(jì)要點(diǎn)在于唯一約束CREATE TABLE course_selection ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, course_id BIGINT NOT NULL, select_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, status TINYINT NOT NULL DEFAULT 1 COMMENT 1有效 0已退選, UNIQUE KEY uk_student_course (student_id, course_id), KEY idx_course_status (course_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;uk_student_course這個(gè)唯一索引非常重要它是防止同一學(xué)生重復(fù)選同一門(mén)課的最后一道防線。即使應(yīng)用層的校驗(yàn)因?yàn)椴l(fā)出現(xiàn)漏洞數(shù)據(jù)庫(kù)這一層也會(huì)直接拒絕重復(fù)插入。我第一版就是漏了這個(gè)約束測(cè)試時(shí)用腳本并發(fā)提交同一個(gè)學(xué)生的選課請(qǐng)求結(jié)果插進(jìn)去好幾條重復(fù)記錄排查了半天才發(fā)現(xiàn)是應(yīng)用層校驗(yàn)有競(jìng)態(tài)。學(xué)生表相對(duì)簡(jiǎn)單但要注意密碼字段的存儲(chǔ)和學(xué)號(hào)的唯一性CREATE TABLE student ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(32) NOT NULL COMMENT 學(xué)號(hào), name VARCHAR(64) NOT NULL, password VARCHAR(128) NOT NULL COMMENT 加密存儲(chǔ), major VARCHAR(64), grade INT, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_student_no (student_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;2.3 JPA 實(shí)體映射與幾個(gè)容易踩的坑用 JPA 做 ORM 映射代碼量比手寫(xiě) SQL 少很多但有幾個(gè)坑必須提前知道。第一個(gè)是關(guān)聯(lián)關(guān)系的加載策略。選課記錄關(guān)聯(lián)學(xué)生和課程如果默認(rèn)用 EAGER 加載查一次選課記錄會(huì)連帶把學(xué)生和課程全查出來(lái)N1 問(wèn)題立刻出現(xiàn)。我的做法是全部用FetchType.LAZY需要的時(shí)候再用JOIN FETCH顯式加載。Entity Table(name course) public class Course { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; Column(name course_code, nullable false) private String courseCode; Column(name course_name, nullable false) private String courseName; Column(nullable false) private Integer capacity; Column(name selected_count, nullable false) private Integer selectedCount; Version private Integer version; // getter/setter 省略 }注意Version注解這是 JPA 樂(lè)觀鎖的開(kāi)關(guān)。加上它之后每次更新這條記錄JPA 會(huì)自動(dòng)在 where 條件里帶上 version并且把 version 加一。如果兩個(gè)事務(wù)同時(shí)讀到 version5一個(gè)先提交把 version 改成 6另一個(gè)提交時(shí)發(fā)現(xiàn) version 已經(jīng)不是 5 了就會(huì)拋OptimisticLockException。這就是樂(lè)觀鎖防超賣的底層機(jī)制。第二個(gè)坑是批量操作的性能。選課高峰期可能有大量查詢?nèi)绻織l都單獨(dú)發(fā) SQL數(shù)據(jù)庫(kù)壓力很大。JPA 提供了BatchSize和hibernate.jdbc.batch_size配置來(lái)優(yōu)化但對(duì)于選課這種單條寫(xiě)入為主的場(chǎng)景更重要的是把查詢緩存和連接池配好。2.4 技術(shù)選型為什么是 JPA 而不是 MyBatis-Plus網(wǎng)上關(guān)于 Spring Data JPA 和 MyBatis-Plus 的對(duì)比文章很多我的實(shí)際體會(huì)是選課系統(tǒng)這種領(lǐng)域模型清晰、以實(shí)體為中心的 CRUD 場(chǎng)景JPA 更合適。JPA 的實(shí)體映射和樂(lè)觀鎖支持是開(kāi)箱即用的Version一個(gè)注解就搞定MyBatis-Plus 雖然也有樂(lè)觀鎖插件但配置起來(lái)多幾步。而且 JPA 的方法名派生查詢比如findBySemesterAndStatus寫(xiě)起來(lái)非?？焓〉舸罅亢?jiǎn)單 SQL。但 JPA 也有短板復(fù)雜查詢和批量更新不如 MyBatis 靈活。所以我的方案是混合使用常規(guī) CRUD 走 JPA防超賣的核心扣減操作用原生 SQL 或者M(jìn)odifying的 JPQL把控制權(quán)拿回來(lái)。這樣既享受了 JPA 的開(kāi)發(fā)效率又在關(guān)鍵路徑上保留了精細(xì)控制的能力。3. 防超賣的核心機(jī)制拆解3.1 超賣到底是怎么發(fā)生的先把問(wèn)題講清楚。假設(shè)一門(mén)課容量 50當(dāng)前已選 49。兩個(gè)學(xué)生 A 和 B 幾乎同時(shí)點(diǎn)選課。系統(tǒng)處理 A 的請(qǐng)求時(shí)讀到 selected_count49判斷 49 50通過(guò)準(zhǔn)備寫(xiě)入。就在 A 還沒(méi)提交事務(wù)的瞬間B 的請(qǐng)求也讀到了 selected_count49因?yàn)?A 還沒(méi)提交B 讀的是舊值同樣判斷通過(guò)。然后兩個(gè)事務(wù)先后提交selected_count 變成 51超賣發(fā)生。這個(gè)問(wèn)題的本質(zhì)是**“讀-判斷-寫(xiě)”這三步不是原子的**。解決思路無(wú)非幾種把這三步變成原子操作數(shù)據(jù)庫(kù)行鎖或原子更新或者讓并發(fā)的一方失敗重試樂(lè)觀鎖或者把并發(fā)擋在數(shù)據(jù)庫(kù)之外分布式鎖、消息隊(duì)列。選課系統(tǒng)的并發(fā)量通常在幾百到幾千用數(shù)據(jù)庫(kù)層面的方案就夠了不必上分布式鎖那么重。3.2 方案一悲觀鎖簡(jiǎn)單但要注意鎖粒度悲觀鎖的思路是“先鎖住再操作”。在 JPA 里可以用Lock(LockModeType.PESSIMISTIC_WRITE)實(shí)現(xiàn)對(duì)應(yīng)數(shù)據(jù)庫(kù)的SELECT ... FOR UPDATE。public interface CourseRepository extends JpaRepositoryCourse, Long { Lock(LockModeType.PESSIMISTIC_WRITE) Query(select c from Course c where c.id :id) OptionalCourse findByIdForUpdate(Param(id) Long id); }在選課服務(wù)里這樣用Transactional public void selectCourse(Long studentId, Long courseId) { Course course courseRepository.findByIdForUpdate(courseId) .orElseThrow(() - new BizException(課程不存在)); if (course.getSelectedCount() course.getCapacity()) { throw new BizException(課程已滿); } // 校驗(yàn)是否已選 if (selectionRepository.existsByStudentIdAndCourseId(studentId, courseId)) { throw new BizException(已選過(guò)該課程); } course.setSelectedCount(course.getSelectedCount() 1); courseRepository.save(course); CourseSelection selection new CourseSelection(); selection.setStudentId(studentId); selection.setCourseId(courseId); selectionRepository.save(selection); }悲觀鎖的優(yōu)點(diǎn)是邏輯直觀一定能防住超賣。但缺點(diǎn)也明顯鎖的粒度是整行而且持有鎖的時(shí)間覆蓋了整個(gè)事務(wù)。如果事務(wù)里還有其他耗時(shí)操作比如遠(yuǎn)程調(diào)用、發(fā)消息鎖會(huì)被長(zhǎng)時(shí)間占用其他學(xué)生選同一門(mén)課全部阻塞。所以用悲觀鎖的鐵律是事務(wù)里只做必要的數(shù)據(jù)庫(kù)操作越快越好。還有一個(gè)隱蔽的坑SELECT ... FOR UPDATE在沒(méi)有命中索引時(shí)會(huì)鎖表而不是鎖行。所以findByIdForUpdate必須走主鍵索引這一點(diǎn)要確認(rèn)執(zhí)行計(jì)劃。我第二版就遇到過(guò)因?yàn)椴樵儣l件沒(méi)走索引導(dǎo)致鎖范圍擴(kuò)大到全表整個(gè)選課接口響應(yīng)時(shí)間從幾十毫秒飆到幾秒。3.3 方案二樂(lè)觀鎖高并發(fā)下的更優(yōu)解樂(lè)觀鎖的思路是“先操作提交時(shí)檢查有沒(méi)有沖突”。JPA 的Version已經(jīng)幫我們實(shí)現(xiàn)了這套機(jī)制代碼寫(xiě)起來(lái)更自然Transactional public void selectCourseOptimistic(Long studentId, Long courseId) { Course course courseRepository.findById(courseId) .orElseThrow(() - new BizException(課程不存在)); if (course.getSelectedCount() course.getCapacity()) { throw new BizException(課程已滿); } if (selectionRepository.existsByStudentIdAndCourseId(studentId, courseId)) { throw new BizException(已選過(guò)該課程); } course.setSelectedCount(course.getSelectedCount() 1); courseRepository.save(course); // 提交時(shí)檢查 version CourseSelection selection new CourseSelection(); selection.setStudentId(studentId); selection.setCourseId(courseId); selectionRepository.save(selection); }當(dāng)并發(fā)沖突發(fā)生時(shí)save會(huì)拋OptimisticLockException。這時(shí)候不能直接把異常拋給用戶而是應(yīng)該捕獲異常并重試。重試次數(shù)一般設(shè) 3 次超過(guò)就返回“系統(tǒng)繁忙請(qǐng)重試”。public void selectWithRetry(Long studentId, Long courseId) { int maxRetry 3; for (int i 0; i maxRetry; i) { try { selectCourseOptimistic(studentId, courseId); return; } catch (OptimisticLockException e) { if (i maxRetry - 1) { throw new BizException(選課人數(shù)過(guò)多請(qǐng)稍后重試); } // 短暫退避后重試 try { Thread.sleep(50L * (i 1)); } catch (InterruptedException ignored) {} } } }樂(lè)觀鎖相比悲觀鎖的優(yōu)勢(shì)在于不阻塞讀、鎖持有時(shí)間短在沖突不激烈的場(chǎng)景下吞吐量更高。選課系統(tǒng)的沖突集中在少數(shù)熱門(mén)課程大部分課程沖突很少樂(lè)觀鎖整體表現(xiàn)更好。但要注意如果某門(mén)課被幾千人同時(shí)搶樂(lè)觀鎖的重試次數(shù)會(huì)急劇上升反而拖慢系統(tǒng)。這時(shí)候需要配合限流或者排隊(duì)機(jī)制。3.4 方案三原子更新 SQL把判斷和扣減合成一步前面兩種方案都是在應(yīng)用層做判斷還有一種更徹底的做法把判斷條件寫(xiě)進(jìn) SQL 的 where 里讓數(shù)據(jù)庫(kù)來(lái)保證原子性。public interface CourseRepository extends JpaRepositoryCourse, Long { Modifying Query(update Course c set c.selectedCount c.selectedCount 1 where c.id :id and c.selectedCount c.capacity) int incrementSelectedCount(Param(id) Long id); }調(diào)用時(shí)判斷返回值Transactional public void selectCourseAtomic(Long studentId, Long courseId) { if (selectionRepository.existsByStudentIdAndCourseId(studentId, courseId)) { throw new BizException(已選過(guò)該課程); } int updated courseRepository.incrementSelectedCount(courseId); if (updated 0) { throw new BizException(課程已滿); } CourseSelection selection new CourseSelection(); selection.setStudentId(studentId); selection.setCourseId(courseId); selectionRepository.save(selection); }這條 update 語(yǔ)句在數(shù)據(jù)庫(kù)層面是原子的selectedCount capacity這個(gè)條件在更新時(shí)求值天然避免了超賣。它的性能最好因?yàn)椴恍枰渔i也不需要重試。但有個(gè)前提必須保證選課記錄的唯一性校驗(yàn)也在同一個(gè)事務(wù)里并且唯一索引兜底。因?yàn)閑xistsByStudentIdAndCourseId這個(gè)檢查本身有競(jìng)態(tài)兩個(gè)并發(fā)請(qǐng)求可能都通過(guò)檢查然后都執(zhí)行 update最后靠唯一索引攔住其中一個(gè)。3.5 三種方案的對(duì)比與選型建議方案原理優(yōu)點(diǎn)缺點(diǎn)適用場(chǎng)景悲觀鎖SELECT FOR UPDATE邏輯直觀一定防住阻塞嚴(yán)重鎖粒度大并發(fā)低、事務(wù)短樂(lè)觀鎖Version 版本號(hào)不阻塞讀吞吐高沖突多時(shí)重試多沖突分散的場(chǎng)景原子更新UPDATE 帶條件性能最好無(wú)鎖邏輯分散需唯一索引兜底高并發(fā)搶課我的最終方案是原子更新為主唯一索引兜底配合限流。這是三版迭代下來(lái)最穩(wěn)的組合。原子更新解決了超賣唯一索引解決了重復(fù)選課限流解決了突發(fā)流量把數(shù)據(jù)庫(kù)打垮的問(wèn)題。4. 完整實(shí)操?gòu)牧愦罱ㄟx課系統(tǒng)4.1 環(huán)境準(zhǔn)備與工程初始化先把環(huán)境搭好。JDK 用 17 或 21MySQL 用 8.0Maven 3.8 以上。Spring Boot 版本選 3.2.x這個(gè)版本對(duì) Java 21 的虛擬線程支持比較好后面可以順手體驗(yàn)一下。用 Spring Initializr 建工程依賴勾選Spring Web、Spring Data JPA、MySQL Driver、Validation、Lombok。建好之后先改application.ymlspring: datasource: url: jdbc:mysql://localhost:3306/course_selection?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghairewriteBatchedStatementstrue username: root password: your_password hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 3000 max-lifetime: 1800000 jpa: hibernate: ddl-auto: validate show-sql: false properties: hibernate: format_sql: true jdbc: batch_size: 50 order_inserts: true連接池參數(shù)不是隨便填的。maximum-pool-size設(shè) 20 是基于這樣的估算假設(shè)單次選課事務(wù)耗時(shí) 20ms那么一個(gè)連接每秒能處理 50 個(gè)請(qǐng)求20 個(gè)連接就是 1000 QPS足夠應(yīng)對(duì)大部分校園場(chǎng)景。設(shè)太大反而會(huì)因?yàn)榫€程上下文切換和數(shù)據(jù)庫(kù)連接開(kāi)銷拖慢系統(tǒng)。connection-timeout設(shè) 3000ms意思是拿不到連接最多等 3 秒超過(guò)就快速失敗避免請(qǐng)求堆積。ddl-auto用validate而不是update這是生產(chǎn)環(huán)境的習(xí)慣。update會(huì)自動(dòng)改表結(jié)構(gòu)看著方便但線上環(huán)境自動(dòng)改表是災(zāi)難。表結(jié)構(gòu)用 SQL 腳本手動(dòng)管理啟動(dòng)時(shí)只校驗(yàn)實(shí)體和表是否匹配。4.2 核心選課接口的實(shí)現(xiàn)Controller 層保持輕薄只做參數(shù)校驗(yàn)和結(jié)果包裝RestController RequestMapping(/api/selection) public class SelectionController { private final SelectionService selectionService; public SelectionController(SelectionService selectionService) { this.selectionService selectionService; } PostMapping(/select) public ResultVoid select(RequestBody Valid SelectRequest request) { selectionService.selectCourse(request.getStudentId(), request.getCourseId()); return Result.success(); } }Service 層是核心把前面講的原子更新方案落地Service public class SelectionService { private final CourseRepository courseRepository; private final CourseSelectionRepository selectionRepository; public SelectionService(CourseRepository courseRepository, CourseSelectionRepository selectionRepository) { this.courseRepository courseRepository; this.selectionRepository selectionRepository; } Transactional(rollbackFor Exception.class) public void selectCourse(Long studentId, Long courseId) { // 1. 快速失敗已選過(guò)直接返回 if (selectionRepository.existsByStudentIdAndCourseId(studentId, courseId)) { throw new BizException(您已選過(guò)該課程); } // 2. 原子扣減條件不滿足返回 0 int updated courseRepository.incrementSelectedCount(courseId); if (updated 0) { throw new BizException(課程已滿或不存在); } // 3. 寫(xiě)入選課記錄唯一索引兜底 try { CourseSelection selection new CourseSelection(); selection.setStudentId(studentId); selection.setCourseId(courseId); selection.setStatus(1); selectionRepository.save(selection); } catch (DataIntegrityViolationException e) { // 唯一索引沖突說(shuō)明并發(fā)下重復(fù)選課回滾扣減 throw new BizException(請(qǐng)勿重復(fù)選課); } } }這段代碼有幾個(gè)細(xì)節(jié)值得說(shuō)。第一existsByStudentIdAndCourseId這個(gè)前置檢查是為了減少無(wú)謂的數(shù)據(jù)庫(kù)寫(xiě)操作它本身不能保證唯一性真正的保證是唯一索引。第二incrementSelectedCount返回 0 有兩種可能課程不存在或者已滿。為了給用戶更準(zhǔn)確的提示可以先查一次課程是否存在但那樣又多一次查詢。我的做法是統(tǒng)一提示“課程已滿或不存在”用戶體驗(yàn)上可以接受。第三捕獲DataIntegrityViolationException后拋業(yè)務(wù)異常事務(wù)會(huì)回滾扣減的 selected_count 也會(huì)恢復(fù)不會(huì)出現(xiàn)“扣了名額但沒(méi)選上”的情況。4.3 退選邏輯與名額回補(bǔ)退選比選課簡(jiǎn)單但也要注意并發(fā)。退選時(shí)把選課記錄狀態(tài)改成 0同時(shí)把課程已選人數(shù)減一Transactional(rollbackFor Exception.class) public void dropCourse(Long studentId, Long courseId) { int updated selectionRepository.updateStatus(studentId, courseId, 0); if (updated 0) { throw new BizException(未找到有效的選課記錄); } courseRepository.decrementSelectedCount(courseId); }decrementSelectedCount的 SQL 要加個(gè)保護(hù)避免減成負(fù)數(shù)Modifying Query(update Course c set c.selectedCount c.selectedCount - 1 where c.id :id and c.selectedCount 0) int decrementSelectedCount(Param(id) Long id);退選和選課如果同時(shí)發(fā)生可能出現(xiàn)“退了又選”的競(jìng)態(tài)但因?yàn)槎际窃痈伦罱K一致性是能保證的。這里有個(gè)經(jīng)驗(yàn)退選接口一定要做冪等用戶連點(diǎn)兩次退選第二次應(yīng)該返回“未找到有效記錄”而不是報(bào)錯(cuò)前端體驗(yàn)更好。4.4 用虛擬線程提升并發(fā)處理能力Java 21 的虛擬線程是個(gè)好東西Spring Boot 3.2 開(kāi)始支持。選課接口是 IO 密集型等數(shù)據(jù)庫(kù)用虛擬線程能顯著提升吞吐。開(kāi)啟方式很簡(jiǎn)單spring: threads: virtual: enabled: true開(kāi)啟后Tomcat 的請(qǐng)求處理會(huì)使用虛擬線程每個(gè)請(qǐng)求一個(gè)虛擬線程阻塞在數(shù)據(jù)庫(kù) IO 時(shí)不會(huì)占用平臺(tái)線程。實(shí)測(cè)在同樣的硬件上選課接口的 QPS 能提升 30% 到 50%。但要注意虛擬線程不是銀彈如果數(shù)據(jù)庫(kù)連接池只有 20 個(gè)連接虛擬線程再多也得排隊(duì)等連接。所以虛擬線程要和連接池大小配合調(diào)優(yōu)不能盲目開(kāi)大。4.5 壓測(cè)驗(yàn)證用 JMeter 模擬搶課寫(xiě)完代碼不壓測(cè)等于沒(méi)寫(xiě)。我用 JMeter 模擬 500 個(gè)并發(fā)用戶同時(shí)搶一門(mén)容量 50 的課驗(yàn)證防超賣是否生效。測(cè)試計(jì)劃這樣配線程數(shù) 500Ramp-up 時(shí)間 1 秒循環(huán) 1 次。HTTP 請(qǐng)求指向/api/selection/select參數(shù)用 CSV 數(shù)據(jù)文件提供不同的 studentId。跑完之后查數(shù)據(jù)庫(kù)SELECT selected_count, capacity FROM course WHERE id 1; SELECT COUNT(*) FROM course_selection WHERE course_id 1 AND status 1;正確的結(jié)果應(yīng)該是selected_count 50選課記錄數(shù)也是 50一條不多一條不少。如果 selected_count 大于 50說(shuō)明防超賣失效如果記錄數(shù)大于 50說(shuō)明唯一索引沒(méi)生效。我第一版壓測(cè)時(shí) selected_count 跑到了 63就是沒(méi)用原子更新導(dǎo)致的。壓測(cè)還要關(guān)注響應(yīng)時(shí)間。正常情況下選課接口的 P99 應(yīng)該在 200ms 以內(nèi)。如果超過(guò) 1 秒說(shuō)明有鎖競(jìng)爭(zhēng)或者連接池不夠需要排查。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 超賣問(wèn)題的排查思路超賣是最常見(jiàn)也最要命的問(wèn)題。排查時(shí)按這個(gè)順序來(lái)先確認(rèn)扣減操作是不是原子的如果用的是“先查再改”的寫(xiě)法基本可以確定是競(jìng)態(tài)再看事務(wù)邊界對(duì)不對(duì)Transactional有沒(méi)有加在 public 方法上加在 private 方法上不生效這是新手常犯的錯(cuò)最后看數(shù)據(jù)庫(kù)隔離級(jí)別MySQL 默認(rèn)的 REPEATABLE READ 在并發(fā)下可能出現(xiàn)快照讀導(dǎo)致判斷用的是舊數(shù)據(jù)。一個(gè)實(shí)用的排查技巧是在扣減前后打日志記錄當(dāng)前 selected_count 和線程 ID壓測(cè)后分析日志能清楚看到哪些請(qǐng)求讀到了相同的值。我當(dāng)初就是靠這個(gè)定位到問(wèn)題的。5.2 重復(fù)選課的三種成因重復(fù)選課通常有三個(gè)原因。第一是唯一索引沒(méi)建這是最基礎(chǔ)的檢查SHOW INDEX FROM course_selection確認(rèn)。第二是唯一索引建了但沒(méi)生效可能是字段類型不一致或者字符集問(wèn)題比如 student_id 在兩張表里一個(gè)是 BIGINT 一個(gè)是 VARCHAR索引匹配不上。第三是應(yīng)用層用了saveOrUpdate之類的邏輯把已存在的記錄又更新了一遍這種情況要改成先查后插或者直接用 insert ignore。5.3 數(shù)據(jù)庫(kù)連接池打滿的處理壓測(cè)時(shí)如果看到HikariPool-1 - Connection is not available, request timed out說(shuō)明連接池打滿了。先別急著調(diào)大maximum-pool-size要分析連接被誰(shuí)占著。常見(jiàn)原因是事務(wù)里有慢查詢或者遠(yuǎn)程調(diào)用導(dǎo)致連接長(zhǎng)時(shí)間不釋放。用SHOW PROCESSLIST看數(shù)據(jù)庫(kù)端的連接狀態(tài)用 Arthas 的trace命令看哪個(gè)方法耗時(shí)最長(zhǎng)。如果確實(shí)是并發(fā)量太大可以調(diào)大連接池但要同步調(diào)大數(shù)據(jù)庫(kù)的max_connections否則應(yīng)用端連接多了數(shù)據(jù)庫(kù)端反而拒絕。我的經(jīng)驗(yàn)是應(yīng)用連接池總數(shù)不要超過(guò)數(shù)據(jù)庫(kù)max_connections的 70%留點(diǎn)余量給運(yùn)維和其他應(yīng)用。5.4 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方法解決方案超賣扣減非原子壓測(cè)后查 selected_count改用原子更新 SQL重復(fù)選課缺唯一索引SHOW INDEX加 uk_student_course連接超時(shí)連接池打滿SHOW PROCESSLIST優(yōu)化慢查詢或調(diào)大池接口變慢鎖競(jìng)爭(zhēng)看 P99 響應(yīng)時(shí)間縮短事務(wù)或改樂(lè)觀鎖事務(wù)不回滾異常被吞檢查 catch 塊拋 RuntimeException樂(lè)觀鎖重試多熱點(diǎn)課程看異常日志頻率改原子更新或限流5.5 幾個(gè)我踩過(guò)的坑第一個(gè)坑是在事務(wù)里做遠(yuǎn)程調(diào)用。我第二版在選課成功后調(diào)用了一個(gè)消息服務(wù)發(fā)通知結(jié)果消息服務(wù)偶爾超時(shí)導(dǎo)致選課事務(wù)被拖長(zhǎng)鎖一直不釋放其他學(xué)生全卡住。后來(lái)改成用事務(wù)同步回調(diào)事務(wù)提交后再發(fā)消息問(wèn)題解決。第二個(gè)坑是**Transactional和synchronized混用**。有同學(xué)想用 synchronized 保證并發(fā)安全但 synchronized 鎖的是 JVM 內(nèi)的對(duì)象多實(shí)例部署時(shí)完全失效而且和事務(wù)的提交時(shí)機(jī)配合不好容易出現(xiàn)“鎖釋放了但事務(wù)還沒(méi)提交”的情況。正確做法是把并發(fā)控制交給數(shù)據(jù)庫(kù)。第三個(gè)坑是索引失效導(dǎo)致鎖表。前面提過(guò)SELECT FOR UPDATE沒(méi)走索引會(huì)鎖全表。用EXPLAIN確認(rèn)執(zhí)行計(jì)劃確保 type 是const或eq_ref不要出現(xiàn)ALL。第四個(gè)坑是壓測(cè)數(shù)據(jù)不真實(shí)。一開(kāi)始我用 100 個(gè)學(xué)生壓測(cè)怎么都測(cè)不出問(wèn)題后來(lái)加到 500 個(gè)才復(fù)現(xiàn)超賣。壓測(cè)的并發(fā)數(shù)要接近真實(shí)峰值否則測(cè)了個(gè)寂寞。6. 性能優(yōu)化與擴(kuò)展方向6.1 緩存課程列表減輕數(shù)據(jù)庫(kù)壓力選課高峰期學(xué)生反復(fù)刷新課程列表這個(gè)讀操作量很大。用 Redis 緩存課程列表能顯著減輕數(shù)據(jù)庫(kù)壓力。緩存策略是課程列表緩存 30 秒選課成功后主動(dòng)刪除對(duì)應(yīng)課程的緩存。30 秒這個(gè)值是個(gè)權(quán)衡太短緩存沒(méi)意義太長(zhǎng)學(xué)生看到的名額不準(zhǔn)。Cacheable(value courseList, key #semester) public ListCourseVO listCourses(String semester) { return courseRepository.findBySemesterAndStatus(semester, 1) .stream().map(this::toVO).collect(Collectors.toList()); } CacheEvict(value courseList, allEntries true) public void selectCourse(Long studentId, Long courseId) { // 選課邏輯 }注意緩存和數(shù)據(jù)庫(kù)的一致性。選課成功后清緩存下次查詢會(huì)重新加載。這個(gè)方案在選課場(chǎng)景下夠用因?yàn)槊~的實(shí)時(shí)性要求沒(méi)那么高學(xué)生看到緩存里的名額稍微舊一點(diǎn)可以接受真正扣減時(shí)以數(shù)據(jù)庫(kù)為準(zhǔn)。6.2 限流保護(hù)數(shù)據(jù)庫(kù)突發(fā)流量是選課系統(tǒng)的常態(tài)開(kāi)放選課的那一秒可能有幾千人同時(shí)點(diǎn)。限流是保護(hù)數(shù)據(jù)庫(kù)的最后一道防線。用 Guava 的 RateLimiter 或者 Sentinel 都行我用的簡(jiǎn)單方案是基于 Redis 的令牌桶public boolean tryAcquire(String key, int limit, int windowSeconds) { String script local current redis.call(incr, KEYS[1]) if current 1 then redis.call(expire, KEYS[1], ARGV[1]) end if current tonumber(ARGV[2]) then return 0 else return 1 end; Long result redisTemplate.execute( new DefaultRedisScript(script, Long.class), Collections.singletonList(key), String.valueOf(windowSeconds), String.valueOf(limit)); return result ! null result 1; }限流的粒度可以按學(xué)生維度防止單個(gè)學(xué)生刷接口也可以按課程維度防止熱門(mén)課程被打爆。我兩個(gè)都做了學(xué)生維度限制每秒 5 次課程維度限制每秒 500 次。6.3 后續(xù)可以擴(kuò)展的方向這個(gè)系統(tǒng)做完之后還有幾個(gè)方向可以繼續(xù)深挖。一是選課排隊(duì)熱門(mén)課程用消息隊(duì)列削峰請(qǐng)求先入隊(duì)后臺(tái)按順序處理前端輪詢結(jié)果。二是分庫(kù)分表如果學(xué)生規(guī)模到幾十萬(wàn)選課記錄表可以按學(xué)期分表。三是多級(jí)緩存本地緩存加 Redis進(jìn)一步降低數(shù)據(jù)庫(kù)壓力。四是監(jiān)控告警用 Micrometer 加 Prometheus 監(jiān)控選課接口的 QPS、響應(yīng)時(shí)間、錯(cuò)誤率出問(wèn)題能第一時(shí)間發(fā)現(xiàn)。我個(gè)人在實(shí)際操作中的體會(huì)是選課系統(tǒng)這個(gè)項(xiàng)目最大的價(jià)值不在于功能多復(fù)雜而在于它把并發(fā)、事務(wù)、索引、緩存這些后端核心知識(shí)點(diǎn)串成了一條線。把這一條線走通比看十篇八股文都管用。最后再分享一個(gè)小技巧壓測(cè)的時(shí)候把數(shù)據(jù)庫(kù)的慢查詢?nèi)罩敬蜷_(kāi)long_query_time設(shè)成 0.1 秒跑完壓測(cè)分析慢查詢?nèi)罩就馨l(fā)現(xiàn)一些平時(shí)注意不到的索引問(wèn)題。