做酒店管理系統(tǒng)這件事我前后完整做過(guò)兩遍第一遍是剛?cè)胄袝r(shí)拿它練手第二遍是幫一個(gè)朋友的門(mén)店做內(nèi)部工具。兩次踩的坑完全不一樣——第一遍坑在代碼第二遍坑在業(yè)務(wù)。后來(lái)跟不少同行聊過(guò)發(fā)現(xiàn)大家對(duì)這個(gè)題目的認(rèn)知普遍偏了覺(jué)得它就是個(gè)房間增刪改查 訂單增刪改查的入門(mén)項(xiàng)目網(wǎng)上模板一抓一大把照著抄一遍就能交差。真動(dòng)手之后才發(fā)現(xiàn)房間是有時(shí)間維度的資源訂單是有生命周期的契約這兩樣?xùn)|西一旦摻在一起CRUD 那套思路立刻就不夠用了。這篇內(nèi)容就把這套系統(tǒng)從業(yè)務(wù)動(dòng)線、表結(jié)構(gòu)切分、訂單狀態(tài)機(jī)、并發(fā)占房到權(quán)限攔截、部署交付完整地捋一遍重點(diǎn)放在那些模板代碼里永遠(yuǎn)不會(huì)寫(xiě)、但真正會(huì)把你卡住的地方。適合正在做課程設(shè)計(jì)、想拿它當(dāng)面試項(xiàng)目、或者要給小門(mén)店做一套能真正用起來(lái)的系統(tǒng)的朋友參考Java 基礎(chǔ)和 Servlet 那套東西不用很精但至少要能看懂 SQL 和接口調(diào)用。1. 老題目為什么還值得用 JavaWeb 重做一遍1.1 它真正的難點(diǎn)不在增刪改查在時(shí)間段占用大多數(shù)管理類系統(tǒng)的核心是記錄存不存在學(xué)生表里有沒(méi)有這個(gè)學(xué)號(hào)、圖書(shū)表里這本書(shū)在不在館判斷條件都是一個(gè)個(gè)離散的字段。酒店系統(tǒng)不一樣它要回答的問(wèn)題是這間房在 3 月 1 日到 3 月 3 日這段時(shí)間里有沒(méi)有被別人占著。這是一個(gè)典型的區(qū)間重疊判斷兩個(gè)訂單只要時(shí)間區(qū)間有交集就算沖突跟記錄本身是否存在沒(méi)有關(guān)系。舉個(gè)具體的例子。某位客人訂了 301 房入住日期 3 月 1 日離店日期 3 月 3 日。另一位客人想訂 301 房3 月 2 日入住、3 月 4 日離店。這兩條訂單在數(shù)據(jù)庫(kù)里完全是兩條獨(dú)立記錄主鍵不同、客人不同、訂單號(hào)不同任何常規(guī)的唯一約束都攔不住它們但它們確實(shí)是沖突的——3 月 2 日晚上那間房只能睡一個(gè)人。重疊判斷的標(biāo)準(zhǔn)寫(xiě)法是startA endB AND startB endA注意這里是嚴(yán)格小于因?yàn)?3 月 3 日離店的客人當(dāng)天中午就退房了同一天入住的客人下午才能進(jìn)房首尾相接不算沖突。這個(gè)細(xì)節(jié)很多模板代碼都寫(xiě)成了小于等于結(jié)果就是系統(tǒng)死活不讓人訂今天退房、今天入住的房間前臺(tái)天天抱怨。1.2 技術(shù)棧到底怎么選別被越新越好帶偏這個(gè)項(xiàng)目用什么框架做取決于你想從里面拿到什么。我把幾種常見(jiàn)組合的實(shí)際體感列出來(lái)你可以對(duì)照自己的目標(biāo)挑。技術(shù)組合上手成本請(qǐng)求鏈路可見(jiàn)度出效果速度適合的目標(biāo)Servlet JSP JDBC中極高能看到每一個(gè)請(qǐng)求參數(shù)怎么進(jìn)來(lái)慢想徹底搞懂 JavaWeb 底層SSMSpring SpringMVC MyBatis較高配置繁多中中學(xué)校課程要求、面試講框架整合Spring Boot MyBatis Thymeleaf低低很多細(xì)節(jié)被自動(dòng)配置藏起來(lái)了快快速交付、給門(mén)店真用Spring Boot Vue 前后端分離中高要寫(xiě)兩套代碼低但邊界清晰中想順便練前端、做簡(jiǎn)歷項(xiàng)目我的建議是如果你的目的是打基礎(chǔ)先用 Servlet JSP 把登錄、房態(tài)查詢、下單這三條鏈路手寫(xiě)一遍感受一下 HttpServletRequest 里取參數(shù)、Session 里存用戶、JSP 里循環(huán)渲染列表這套原始流程寫(xiě)完之后再換 Spring Boot你會(huì)對(duì)框架到底幫你做了什么有非常清晰的認(rèn)知。反過(guò)來(lái)如果目標(biāo)是盡快做出一個(gè)能演示、能給門(mén)店試用的東西直接 Spring Boot別在 XML 配置上浪費(fèi)生命。有一點(diǎn)要提醒網(wǎng)上流傳的很多酒店管理系統(tǒng)源碼用的是十年前的 JSP 內(nèi)嵌 Java 代碼寫(xiě)法% %里塞滿了業(yè)務(wù)邏輯這種代碼能跑但沒(méi)法維護(hù)也不適合當(dāng)自己的作品展示。哪怕用 JSP也請(qǐng)把業(yè)務(wù)邏輯放到 Service 層頁(yè)面只負(fù)責(zé)渲染。1.3 一個(gè)能演示和能用的系統(tǒng)差在哪些模塊先把模塊清單拉出來(lái)心里有個(gè)全景圖后面的表結(jié)構(gòu)和接口才好安排?；A(chǔ)數(shù)據(jù)房型管理大床房、標(biāo)間、套房、房間管理物理房號(hào)、所屬房型、樓層、價(jià)格策略基礎(chǔ)價(jià)、周末價(jià)、節(jié)假日價(jià)預(yù)訂散客預(yù)訂、團(tuán)隊(duì)預(yù)訂、預(yù)訂查詢、取消預(yù)訂、超時(shí)未到自動(dòng)釋放前臺(tái)作業(yè)排房、辦理入住、換房、續(xù)住、退房、掛賬賬務(wù)押金收取、消費(fèi)入賬、結(jié)賬、發(fā)票信息記錄會(huì)員會(huì)員等級(jí)、積分、協(xié)議價(jià)報(bào)表出租率、平均房?jī)r(jià)、營(yíng)收日?qǐng)?bào)系統(tǒng)管理用戶、角色、權(quán)限、操作日志能演示的系統(tǒng)通常只做前四個(gè)模塊的 CRUD能用的系統(tǒng)必須在換房續(xù)住拆賬超時(shí)釋放這些邊緣動(dòng)作上有完整處理。這四個(gè)動(dòng)作恰恰是最容易被忽略、也最容易在真實(shí)場(chǎng)景里出問(wèn)題的部分后面會(huì)專門(mén)講。2. 先把前臺(tái)的動(dòng)線走一遍業(yè)務(wù)模型比技術(shù)棧更先決定成敗2.1 一天里前臺(tái)到底會(huì)點(diǎn)哪些按鈕我在動(dòng)手寫(xiě)第一行代碼之前專門(mén)在一個(gè)門(mén)店的前臺(tái)后面站了大半天把他們的操作記錄下來(lái)。這份記錄比任何需求文檔都有用。早上八點(diǎn)接班第一件事是打開(kāi)房態(tài)圖看昨天夜審之后的在住房間、今日預(yù)抵、今日預(yù)離。有客人到店先問(wèn)姓名或訂單號(hào)查到預(yù)訂單核對(duì)證件選房系統(tǒng)推薦空閑房收押金點(diǎn)辦理入住房間狀態(tài)從已預(yù)訂變成在住。中午陸續(xù)有人退房點(diǎn)退房系統(tǒng)算出房費(fèi)加消費(fèi)減押金多退少補(bǔ)房間狀態(tài)變成待打掃。客房阿姨打掃完在系統(tǒng)里點(diǎn)已清潔房間才回到空閑可售。下午有客人打電話來(lái)問(wèn)今晚還有沒(méi)有房前臺(tái)要能快速看到每種房型剩余幾間。晚上可能有客人要換房從 301 換到 508房?jī)r(jià)不一樣還得補(bǔ)差價(jià)。把這條動(dòng)線畫(huà)清楚之后你會(huì)發(fā)現(xiàn)系統(tǒng)的核心不是房間表和訂單表兩張表而是房態(tài)這個(gè)每天都在變的東西以及房態(tài)變化的觸發(fā)點(diǎn)。任何一個(gè)操作沒(méi)把房態(tài)改對(duì)第二天前臺(tái)就得靠人工記憶干活。2.2 房態(tài)不是空閑/占用兩個(gè)值新手最容易犯的錯(cuò)是把房態(tài)設(shè)計(jì)成布爾值。真實(shí)場(chǎng)景里至少需要這幾個(gè)狀態(tài)VACANT空閑可售BOOKED已被預(yù)訂未到店OCCUPIED在住DIRTY待打掃客人已退房房間還沒(méi)清理CLEANING清潔中MAINTENANCE維修停用LOCKED鎖房?jī)?nèi)部留房、長(zhǎng)包房預(yù)留待打掃這個(gè)狀態(tài)是分水嶺。有它系統(tǒng)才算摸到了酒店業(yè)務(wù)的邊沒(méi)它退房之后房間立刻變空閑可售前臺(tái)把剛退的房間賣出去客人進(jìn)門(mén)看見(jiàn)床單還沒(méi)換投訴就來(lái)了。房態(tài)和訂單狀態(tài)是兩套東西千萬(wàn)別合并成一張表的同一個(gè)字段。訂單狀態(tài)描述的是這筆交易走到哪一步了房態(tài)描述的是這個(gè)物理空間現(xiàn)在能不能賣。一筆訂單可以對(duì)應(yīng)多次房態(tài)變化預(yù)訂→在住→待打掃一個(gè)房態(tài)也可能被多筆訂單先后占用?；煸谝黄鸬暮蠊悄闳∠还P訂單的時(shí)候不知道該不該把房間置為空閑——萬(wàn)一那間房同時(shí)還被另一筆訂單占著呢。2.3 房型和房間必須拆成兩張表房型是賣的品類房間是具體的庫(kù)存單位。大床房是房型301 是房間。價(jià)格、床型、面積、可住人數(shù)這些屬性掛在房型上房間只保留房號(hào)、樓層、所屬房型和當(dāng)前房態(tài)。拆開(kāi)的好處很直接調(diào)價(jià)的時(shí)候只改房型一行不用去改幾十個(gè)房間統(tǒng)計(jì)出租率的時(shí)候按房型聚合不用自己拼字符串換房的時(shí)候只改訂單關(guān)聯(lián)的房間 ID房型信息自動(dòng)跟著變。不拆的后果我在一個(gè)項(xiàng)目里真切見(jiàn)過(guò)——房型信息直接抄在房間表里同一個(gè)房型的可住人數(shù)在 20 個(gè)房間記錄里填了 3 種不同的值后來(lái)做超員校驗(yàn)的時(shí)候根本沒(méi)法統(tǒng)一。3. 數(shù)據(jù)表的三條邊界房間、訂單、入住記錄怎么切3.1 核心表清單與建表要點(diǎn)下面是我實(shí)際用的一套精簡(jiǎn)版結(jié)構(gòu)字段做過(guò)刪減保留了骨架。數(shù)據(jù)庫(kù)用 MySQL 8。-- 房型 CREATE TABLE room_type ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, -- 大床房 / 標(biāo)間 / 套房 base_price DECIMAL(10,2) NOT NULL, -- 基礎(chǔ)價(jià)元/晚 bed_type VARCHAR(20), -- 床型 max_occupancy TINYINT NOT NULL DEFAULT 2, -- 最大可住人數(shù) area DECIMAL(6,2), status TINYINT NOT NULL DEFAULT 1 -- 1 啟用 0 停用 ); -- 房間 CREATE TABLE room ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(20) NOT NULL, room_type_id BIGINT NOT NULL, floor_no INT, room_status VARCHAR(20) NOT NULL DEFAULT VACANT, remark VARCHAR(200), UNIQUE KEY uk_room_no (room_no), KEY idx_type_status (room_type_id, room_status) ); -- 訂單預(yù)訂主表 CREATE TABLE booking_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, guest_name VARCHAR(50) NOT NULL, guest_phone VARCHAR(20) NOT NULL, room_type_id BIGINT NOT NULL, room_id BIGINT, -- 排房后回填 check_in_date DATE NOT NULL, check_out_date DATE NOT NULL, room_count INT NOT NULL DEFAULT 1, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0, deposit DECIMAL(10,2) NOT NULL DEFAULT 0, order_status VARCHAR(20) NOT NULL, source VARCHAR(20), -- 門(mén)店/電話/線上 created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no), KEY idx_dates (check_in_date, check_out_date), KEY idx_status (order_status) ) ENGINEInnoDB;3.2 訂單和入住記錄為什么要拆開(kāi)訂單是契約入住記錄是事實(shí)。一位客人可能先訂 3 晚住到第二晚說(shuō)要換房第三晚?yè)Q到另一間也可能訂 2 晚實(shí)際住了 4 晚需要續(xù)住。如果只有訂單表這些變化只能靠改訂單字段實(shí)現(xiàn)改完之后歷史軌跡全丟了出了糾紛沒(méi)法查。拆開(kāi)之后booking_order保存預(yù)訂層面的信息誰(shuí)訂的、訂幾晚、總價(jià)多少、訂單狀態(tài)check_in_record保存實(shí)際入住的事實(shí)實(shí)際哪天進(jìn)的、住哪間房、哪天退的、實(shí)際房費(fèi)。一張訂單對(duì)應(yīng)一到多條入住記錄換一次房就多一條。拆表還有一個(gè)隱性好處結(jié)賬邏輯變清楚了。賬單掛在實(shí)際的入住記錄上而不是掛在訂單上拆賬、掛賬、補(bǔ)開(kāi)發(fā)票都有一個(gè)明確的載體。3.3 時(shí)間字段怎么存這是最容易埋雷的地方房費(fèi)是按夜算的不是按小時(shí)。所以入住日期和離店日期必須是DATE類型不能是DATETIME。一旦用了DATETIME你會(huì)在計(jì)算間夜數(shù)的時(shí)候遇到無(wú)窮無(wú)盡的問(wèn)題客人 3 月 1 日 14:30 入住、3 月 3 日 11:00 退房按差值算是 1.85 天房間到底算幾晚標(biāo)準(zhǔn)做法是日期歸日期實(shí)際進(jìn)出時(shí)間單獨(dú)記。訂單表用DATE入住記錄里用DATETIME記實(shí)際時(shí)間。間夜數(shù)算起來(lái)就一行l(wèi)ong nights ChronoUnit.DAYS.between(checkInDate, checkOutDate); if (nights 0) { throw new BizException(離店日期必須晚于入住日期); }3 月 1 日到 3 月 3 日between返回 2兩晚符合常識(shí)。還有一個(gè)坑是凌晨入住?？腿?3 月 2 日凌晨 2 點(diǎn)來(lái)開(kāi)房他心里的今天是 3 月 1 日那一天的延續(xù)行業(yè)里通常把凌晨 6 點(diǎn)前的入住算到前一個(gè)營(yíng)業(yè)日。如果你的系統(tǒng)直接取服務(wù)器當(dāng)前日期夜審就會(huì)出錯(cuò)報(bào)表也會(huì)錯(cuò)位。解決辦法是引入營(yíng)業(yè)日business date的概念用一個(gè)配置項(xiàng)存當(dāng)天營(yíng)業(yè)日每天凌晨固定時(shí)間比如 4 點(diǎn)跑一次夜審任務(wù)把它推進(jìn)一天所有今天的判斷都用營(yíng)業(yè)日不用LocalDate.now()。3.4 索引建在哪以及一個(gè)約束解決不了的問(wèn)題上面建表語(yǔ)句里booking_order上建了(check_in_date, check_out_date)的聯(lián)合索引因?yàn)椴槟扯螘r(shí)間內(nèi)的訂單是最高頻的查詢。room表上建了(room_type_id, room_status)因?yàn)榉繎B(tài)圖要按房型聚合。很多人第一反應(yīng)是給訂單表加一個(gè)唯一約束來(lái)防重復(fù)預(yù)訂比如把room_id check_in_date check_out_date設(shè)成唯一鍵。這個(gè)想法是錯(cuò)的而且錯(cuò)得很隱蔽。唯一約束只能保證完全相同的組合不重復(fù)但(301, 3-01, 3-03)和(301, 3-02, 3-04)是兩個(gè)不同的組合唯一約束完全放行。時(shí)間區(qū)間重疊這件事關(guān)系型數(shù)據(jù)庫(kù)的唯一索引管不了。真正能解決問(wèn)題的方案后面第 5 章會(huì)詳細(xì)講。4. 訂單狀態(tài)機(jī)從預(yù)訂到退房這條鏈路怎么用代碼鎖死4.1 狀態(tài)定義與合法遷移訂單狀態(tài)不能隨便改必須有一個(gè)明確的遷移圖。我用的這套定義經(jīng)過(guò)兩次項(xiàng)目驗(yàn)證基本夠用狀態(tài)含義可以遷往PENDING_PAY待支付線上預(yù)訂BOOKED、CANCELLEDBOOKED已確認(rèn)預(yù)訂CHECKED_IN、CANCELLED、NO_SHOWCHECKED_IN已入住CHECKED_OUTCHECKED_OUT已退房終態(tài)CANCELLED已取消終態(tài)NO_SHOW未到店終態(tài)終態(tài)的意思是不能再改回去。很多系統(tǒng)允許取消的訂單重新激活看起來(lái)方便實(shí)際上把庫(kù)存計(jì)算攪得一團(tuán)糟因?yàn)槿∠臅r(shí)候已經(jīng)釋放過(guò)房間了重新激活要不要再占一次建議直接禁止需要的話讓前臺(tái)重新下一單。4.2 用枚舉把非法遷移擋在入口不寫(xiě)校驗(yàn)的代碼長(zhǎng)這樣order.setOrderStatus(CHECKED_OUT)任何人都能把任何訂單改成任何狀態(tài)。這種代碼在演示時(shí)看不出問(wèn)題上線一周就會(huì)冒出已退房的訂單又被改成在住的臟數(shù)據(jù)。我用一個(gè)枚舉把這些規(guī)則固化下來(lái)public enum OrderStatus { PENDING_PAY, BOOKED, CHECKED_IN, CHECKED_OUT, CANCELLED, NO_SHOW; private static final MapOrderStatus, SetOrderStatus TRANSITIONS new HashMap(); static { TRANSITIONS.put(PENDING_PAY, EnumSet.of(BOOKED, CANCELLED)); TRANSITIONS.put(BOOKED, EnumSet.of(CHECKED_IN, CANCELLED, NO_SHOW)); TRANSITIONS.put(CHECKED_IN, EnumSet.of(CHECKED_OUT)); TRANSITIONS.put(CHECKED_OUT, EnumSet.noneOf(OrderStatus.class)); TRANSITIONS.put(CANCELLED, EnumSet.noneOf(OrderStatus.class)); TRANSITIONS.put(NO_SHOW, EnumSet.noneOf(OrderStatus.class)); } public boolean canTransitTo(OrderStatus target) { return TRANSITIONS.getOrDefault(this, Collections.emptySet()).contains(target); } }Service 層統(tǒng)一走一個(gè)入口方法任何狀態(tài)變更都必須經(jīng)過(guò)它順手把操作日志也記了Transactional(rollbackFor Exception.class) public void changeStatus(Long orderId, OrderStatus target, String operator) { BookingOrder order orderMapper.selectById(orderId); if (order null) { throw new BizException(訂單不存在); } OrderStatus current OrderStatus.valueOf(order.getOrderStatus()); if (!current.canTransitTo(target)) { throw new BizException(訂單當(dāng)前狀態(tài) current 不能變更為 target); } // 狀態(tài)變更時(shí)必須同步處理的副作用 if (target OrderStatus.CHECKED_IN) { occupyRoom(order); } else if (target OrderStatus.CANCELLED || target OrderStatus.NO_SHOW) { releaseRoom(order); } else if (target OrderStatus.CHECKED_OUT) { markRoomDirty(order.getRoomId()); } order.setOrderStatus(target.name()); orderMapper.updateById(order); opLogService.record(orderId, current.name(), target.name(), operator); }Transactional加在這里不是裝飾。狀態(tài)改了但房間沒(méi)釋放或者房間釋放了但狀態(tài)沒(méi)改都是要人命的臟數(shù)據(jù)必須放在同一個(gè)事務(wù)里。4.3 狀態(tài)遷移和房態(tài)聯(lián)動(dòng)事務(wù)邊界要?jiǎng)澢宄聞?wù)邊界劃多寬是個(gè)需要想清楚的問(wèn)題。我最初的寫(xiě)法是把整個(gè)入住流程包在一個(gè)事務(wù)里改狀態(tài)、改房態(tài)、寫(xiě)入住記錄、記日志。測(cè)的時(shí)候沒(méi)問(wèn)題壓測(cè)的時(shí)候發(fā)現(xiàn)鎖等待時(shí)間很長(zhǎng)因?yàn)槭聞?wù)里還夾了一個(gè)調(diào)用外部接口的動(dòng)作發(fā)短信通知這個(gè)網(wǎng)絡(luò)調(diào)用慢的時(shí)候整個(gè)事務(wù)就卡著不放。后來(lái)拆成了兩層核心數(shù)據(jù)變更放在事務(wù)里通知類的動(dòng)作放到事務(wù)提交之后用TransactionSynchronizationManager.registerSynchronization或者 Spring 的事件機(jī)制來(lái)做。這個(gè)經(jīng)驗(yàn)在任何業(yè)務(wù)系統(tǒng)里都通用——事務(wù)里不要做網(wǎng)絡(luò)調(diào)用。4.4 那些和日期相關(guān)的邊緣情況跨月、跨年、閏年的日期計(jì)算用LocalDate和ChronoUnit基本不會(huì)出錯(cuò)但有幾個(gè)業(yè)務(wù)上的坑需要提前處理。一是同一天入住同一天離店。有的客人凌晨入住、當(dāng)天上午就走按間夜算是 0 晚。系統(tǒng)里應(yīng)該直接拒絕或者強(qiáng)制按 1 晚計(jì)費(fèi)不能讓 0 元的訂單進(jìn)數(shù)據(jù)庫(kù)。二是超時(shí)未到自動(dòng)釋放。預(yù)訂單默認(rèn)保留到入住當(dāng)天的某個(gè)時(shí)間點(diǎn)行業(yè)慣例是 18:00 或 20:00超過(guò)這個(gè)時(shí)間沒(méi)到店就要自動(dòng)轉(zhuǎn)NO_SHOW并釋放房間。這個(gè)必須用定時(shí)任務(wù)做不能靠前臺(tái)手動(dòng)。定時(shí)任務(wù)的執(zhí)行時(shí)間要考慮時(shí)區(qū)服務(wù)器如果是 UTC 時(shí)間你寫(xiě)cron 0 0 18 * * ?實(shí)際跑的是北京時(shí)間凌晨 2 點(diǎn)。三是續(xù)住?？腿嗽谧∑陂g說(shuō)要再住一晚這時(shí)候房間后面可能已經(jīng)被別人訂了。正確的做法是先查該房間在原離店日到新離店日之間有沒(méi)有其他訂單有就拒絕或者建議換房沒(méi)有才允許延長(zhǎng)同時(shí)要同步占用新的一晚。這個(gè)邏輯如果用第 5 章的日期占位表來(lái)做就是簡(jiǎn)單地再插一行非常干凈。5. 同一間房被兩個(gè)人同時(shí)下單并發(fā)超賣的排查與解決5.1 現(xiàn)象長(zhǎng)什么樣這個(gè) bug 我在兩個(gè)項(xiàng)目里都復(fù)現(xiàn)過(guò)表現(xiàn)一模一樣兩個(gè)人同時(shí)打開(kāi)房態(tài)頁(yè)面都看到 301 空閑同時(shí)點(diǎn)擊下單兩個(gè)請(qǐng)求都返回成功數(shù)據(jù)庫(kù)里出現(xiàn)兩條互相沖突的訂單。單獨(dú)測(cè)永遠(yuǎn)測(cè)不出來(lái)一上真實(shí)環(huán)境就偶發(fā)。第一次遇到的時(shí)候我盯著代碼看了兩個(gè)小時(shí)沒(méi)找出來(lái)因?yàn)槊恳粭l SQL 單獨(dú)執(zhí)行都是對(duì)的。后來(lái)在 Service 方法入口和出口各打了一行帶毫秒時(shí)間戳的日志把兩個(gè)并發(fā)請(qǐng)求的日志交錯(cuò)著看才發(fā)現(xiàn)問(wèn)題出在先查后插這個(gè)動(dòng)作中間。5.2 完整排查鏈路別跳過(guò)任何一步遇到這類問(wèn)題我現(xiàn)在的排查順序是這樣的一步都不跳第一步確認(rèn)是不是真的并發(fā)。先看兩條沖突訂單的created_at如果相差幾毫秒基本可以確認(rèn)為并發(fā)相差幾分鐘那就是業(yè)務(wù)邏輯本身漏了校驗(yàn)。我第一次犯的錯(cuò)就是漏看了創(chuàng)建時(shí)間以為是業(yè)務(wù)校驗(yàn)沒(méi)寫(xiě)改了半天校驗(yàn)邏輯問(wèn)題依舊。第二步確認(rèn)代碼的查詢條件和插入條件用的是不是同一套。有的代碼查詢時(shí)按入住日期 離店日期 AND 離店日期 入住日期判斷沖突插入時(shí)卻忘了考慮房間數(shù)大于 1 的訂單條件不對(duì)等天然就有縫隙。第三步看事務(wù)隔離級(jí)別。MySQL 默認(rèn)是REPEATABLE READ普通SELECT是快照讀不加鎖。也就是說(shuō) A 事務(wù)查的時(shí)候看不到 B 事務(wù)還沒(méi)提交的插入B 事務(wù)也看不到 A 的兩個(gè)都認(rèn)為房間是空的。第四步定位間隙在哪。把SELECT和INSERT之間的時(shí)間窗口量出來(lái)只要這個(gè)窗口大于 0就存在競(jìng)態(tài)。5.3 三種解法以及我為什么最終選了第三種方案做法優(yōu)點(diǎn)缺點(diǎn)悲觀鎖SELECT ... FOR UPDATE鎖住房間行實(shí)現(xiàn)簡(jiǎn)單絕對(duì)安全粒度粗一間房一個(gè)事務(wù)排隊(duì)高峰期鎖等待明顯樂(lè)觀鎖房間表加 version 字段更新時(shí)校驗(yàn)無(wú)鎖等待吞吐高只適合改同一行的場(chǎng)景管不了區(qū)間重疊日期占位表一間房一晚一行唯一索引兜底語(yǔ)義清晰天然防重查詢快需要額外維護(hù)一張表悲觀鎖的問(wèn)題在于粒度。你要鎖的其實(shí)是301 房在 3 月 1 日到 3 月 3 日這一段SELECT ... FOR UPDATE只能鎖住整個(gè) 301 房這一行結(jié)果就是 3 月 10 日的訂單也要排隊(duì)等 3 月 1 日的訂單處理完。低峰期無(wú)所謂高峰期前臺(tái)會(huì)明顯感覺(jué)到卡。樂(lè)觀鎖更不對(duì)路因?yàn)閮晒P沖突的訂單操作的根本不是同一行數(shù)據(jù)一條是新增一條也是新增沒(méi)有版本號(hào)沖突這回事。日期占位表是我最終采用的方案思路是把房間 日期這個(gè)最小占用單位顯式存成一行CREATE TABLE room_date_stock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id BIGINT NOT NULL, biz_date DATE NOT NULL, order_id BIGINT NOT NULL, UNIQUE KEY uk_room_date (room_id, biz_date), KEY idx_order (order_id) ) ENGINEInnoDB;預(yù)訂 301 房 3 月 1 日入住、3 月 3 日離店就是插入兩行(301, 2024-03-01)和(301, 2024-03-02)。注意離店日那天不占因?yàn)榭腿酥形缇妥吡恕＿@兩個(gè)行插入時(shí)如果別人已經(jīng)占過(guò)其中任意一天唯一索引uk_room_date立刻拋DuplicateKeyException事務(wù)回滾第二個(gè)人收到該房型已訂滿的提示。這個(gè)方案最舒服的地方在于它把區(qū)間重疊這個(gè)抽象問(wèn)題轉(zhuǎn)化成了主鍵沖突這個(gè)數(shù)據(jù)庫(kù)最擅長(zhǎng)的問(wèn)題。不需要寫(xiě)復(fù)雜的重疊查詢不需要加鎖不需要擔(dān)心隔離級(jí)別數(shù)據(jù)庫(kù)的唯一索引天然就是并發(fā)安全的。代碼層面的封裝也不復(fù)雜Transactional(rollbackFor Exception.class) public Long createOrder(OrderCreateDTO dto) { // 1. 先查出可用房間這個(gè)查詢只是給用戶看不作為最終依據(jù) ListLong candidateRoomIds roomMapper.findAvailableRooms( dto.getRoomTypeId(), dto.getCheckInDate(), dto.getCheckOutDate(), dto.getRoomCount()); if (candidateRoomIds.isEmpty()) { throw new BizException(所選日期已無(wú)可用房間); } // 2. 逐個(gè)嘗試占位占不上就換下一間 Long lockedRoomId null; for (Long roomId : candidateRoomIds) { try { occupyAllNights(roomId, dto.getCheckInDate(), dto.getCheckOutDate()); lockedRoomId roomId; break; } catch (DuplicateKeyException e) { // 這間被別人搶了繼續(xù)試下一間 } } if (lockedRoomId null) { throw new BizException(房間剛剛被訂完請(qǐng)刷新后重試); } // 3. 落訂單 return saveOrder(dto, lockedRoomId); } private void occupyAllNights(Long roomId, LocalDate in, LocalDate out) { LocalDate cursor in; while (cursor.isBefore(out)) { roomDateStockMapper.insert(roomId, cursor, currentOrderId); cursor cursor.plusDays(1); } }有一個(gè)坑必須提前說(shuō)Spring 的聲明式事務(wù)默認(rèn)只對(duì)RuntimeException回滾DuplicateKeyException是DataAccessException的子類屬于RuntimeException會(huì)正常回滾這點(diǎn)沒(méi)問(wèn)題。但如果你在循環(huán)里catch了這個(gè)異常Spring 就認(rèn)為你處理過(guò)了不會(huì)把事務(wù)標(biāo)記為回滾前面插入的部分行可能殘留。所以catch之后要么手動(dòng)TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()要么把每次占位拆成獨(dú)立的小事務(wù)REQUIRES_NEW。我用的是后者雖然多幾個(gè)連接但邏輯最干凈。5.4 取消、退房、換房時(shí)的占位釋放占位表建起來(lái)容易維護(hù)起來(lái)需要細(xì)心。取消訂單的時(shí)候必須按order_id把對(duì)應(yīng)的占位行全刪掉一行都不能留否則那幾天就永遠(yuǎn)賣不出去了。換房的時(shí)候要先占新的、再放舊的順序反了會(huì)出現(xiàn)在極短的時(shí)間窗口內(nèi)兩邊都沒(méi)占住的情況雖然概率極低但真出問(wèn)題就是兩筆訂單搶同一間房。退房的時(shí)候占位行不能馬上刪因?yàn)榭腿颂崆巴朔勘热缬喠?3 晚住 1 晚就走第三晚的房間是空出來(lái)的理論上可以再賣。這時(shí)候刪掉剩余的占位行是合理的但要處理好退款——客人沒(méi)住的那晚要不要退錢(qián)、退多少屬于業(yè)務(wù)策略系統(tǒng)至少要留個(gè)記錄。每天夜審的時(shí)候順便跑一個(gè)清理任務(wù)把biz_date小于昨天的占位行歸檔到歷史表主表只留未來(lái)和當(dāng)天的數(shù)據(jù)查詢速度會(huì)一直保持在很高的水平。6. 登錄會(huì)話與角色權(quán)限前臺(tái)、收銀、店長(zhǎng)看到的界面不該一樣6.1 角色怎么劃別一上來(lái)就搞復(fù)雜權(quán)限設(shè)計(jì)最容易過(guò)度工程化。RBAC 那套用戶-角色-權(quán)限-資源-菜單五張表的模型很標(biāo)準(zhǔn)但放到一個(gè)門(mén)店內(nèi)部使用的小系統(tǒng)上純屬浪費(fèi)。我實(shí)際用的是三個(gè)層級(jí)角色固定三到五個(gè)前臺(tái)、收銀、客房、店長(zhǎng)、管理員權(quán)限點(diǎn)用字符串枚舉比如order:create、order:cancel、room:status:update、report:view角色和權(quán)限點(diǎn)的對(duì)應(yīng)關(guān)系寫(xiě)死在代碼或者配置表里不做動(dòng)態(tài)配置界面。門(mén)店規(guī)模小角色幾乎不會(huì)變動(dòng)態(tài)配置能力的收益遠(yuǎn)遠(yuǎn)抵不上維護(hù)成本。有一個(gè)業(yè)務(wù)上的權(quán)限細(xì)節(jié)值得單獨(dú)提收銀不能改房?jī)r(jià)店長(zhǎng)可以。這不是技術(shù)潔癖是真實(shí)的風(fēng)控需求。折扣權(quán)限必須有一個(gè)明確的審批鏈條否則前臺(tái)私下給客人打折的空間太大。系統(tǒng)里對(duì)應(yīng)的做法是改價(jià)接口單獨(dú)鑒權(quán)并且在操作日志里記錄原價(jià)、新價(jià)、操作人、時(shí)間事后能查。6.2 Session 還是 Token小系統(tǒng)別糾結(jié)傳統(tǒng) JavaWeb 用HttpSession存登錄用戶簡(jiǎn)單直接取當(dāng)前用戶就是request.getSession().getAttribute(loginUser)。問(wèn)題出在兩處一是服務(wù)端重啟 Session 就沒(méi)了前臺(tái)得重新登錄二是如果以后要部署兩臺(tái)機(jī)器做負(fù)載均衡Session 不共享用戶會(huì)在兩臺(tái)機(jī)器之間反復(fù)掉線。解決辦法也不復(fù)雜單機(jī)部署的話把 Session 超時(shí)時(shí)間調(diào)到 8 小時(shí)server.servlet.session.timeout8h跟前臺(tái)一個(gè)班次對(duì)齊重啟丟 Session 的問(wèn)題可以通過(guò)持久化 Session 或者直接接受讓前臺(tái)重登一次來(lái)解決。真要做多機(jī)再引入 Redis 存 Session。Token 方案JWT的好處是無(wú)狀態(tài)壞處是沒(méi)法主動(dòng)踢人下線用戶權(quán)限變了也得等 token 過(guò)期才生效。對(duì)一個(gè)門(mén)店內(nèi)部系統(tǒng)來(lái)說(shuō)能隨時(shí)踢掉離職員工的登錄狀態(tài)比無(wú)狀態(tài)重要得多所以我傾向于 Session。6.3 攔截器怎么寫(xiě)得既安全又不啰嗦登錄校驗(yàn)和權(quán)限校驗(yàn)應(yīng)該分成兩層。第一層是登錄攔截器沒(méi)登錄的一律跳登錄頁(yè)第二層是權(quán)限攔截器已登錄但沒(méi)權(quán)限的返回 403。權(quán)限映射我寫(xiě)在配置文件里比在方法上加注解更直觀一眼能看全auth: rules: - pattern: /order/** roles: [FRONT_DESK, MANAGER] - pattern: /report/** roles: [MANAGER] - pattern: /room/status roles: [FRONT_DESK, HOUSEKEEPING, MANAGER] - pattern: /admin/** roles: [ADMIN]攔截器里按順序匹配命中第一條就判斷匹配不到默認(rèn)放行靜態(tài)資源、登錄頁(yè)這些。這里要注意寫(xiě)匹配順序/order/**這種通配規(guī)則如果放在具體規(guī)則前面會(huì)把后面更細(xì)的規(guī)則全蓋住。6.4 越權(quán)比未登錄更危險(xiǎn)的那類問(wèn)題登錄攔截器擋得住沒(méi)登錄的人擋不住登錄了但不是這條數(shù)據(jù)主人的人。我在給別人做代碼 Review 的時(shí)候這類問(wèn)題出現(xiàn)頻率最高。典型場(chǎng)景前臺(tái) A 打開(kāi)訂單詳情頁(yè)URL 是/order/detail?id1001他手動(dòng)把 id 改成 1002看到了另一筆訂單的客人身份證號(hào)和手機(jī)號(hào)。這不是權(quán)限配置的漏洞是數(shù)據(jù)歸屬校驗(yàn)的缺失。修復(fù)方式有兩種。一種是每次查詢都帶上歸屬條件比如WHERE id ? AND (creator_id ? OR branch_id ?)另一種是在 Service 層拿到記錄后顯式判斷當(dāng)前用戶有沒(méi)有這行數(shù)據(jù)的訪問(wèn)權(quán)。前者性能好后者邏輯更集中。小店內(nèi)部系統(tǒng)用后者就夠了好維護(hù)。還有一類是狀態(tài)越權(quán)客人已經(jīng)退房了按理說(shuō)訂單不能再取消但代碼里只判斷了有沒(méi)有權(quán)限取消沒(méi)判斷當(dāng)前狀態(tài)能不能取消。這個(gè)用第 4 章的狀態(tài)機(jī)就能攔住前提是所有變更入口都統(tǒng)一走changeStatus不能有繞過(guò)它的野路子。7. 部署交付一個(gè)能演示的系統(tǒng)和一個(gè)能用的系統(tǒng)差在哪7.1 數(shù)據(jù)庫(kù)初始化腳本要當(dāng)成正經(jīng)產(chǎn)物維護(hù)我見(jiàn)過(guò)太多項(xiàng)目把建表語(yǔ)句散落在各個(gè) .sql 文件里有的叫test.sql有的叫新建文本文檔.sql交付的時(shí)候找半天。正確的做法是維護(hù)一份按順序編號(hào)的腳本db/ V1__schema.sql 建表 V2__init_data.sql 初始數(shù)據(jù)房型、房間、默認(rèn)管理員 V3__index.sql 補(bǔ)充索引初始管理員賬號(hào)的密碼要存加密后的值BCrypt 或者至少 MD5 加鹽不能明文。這個(gè)細(xì)節(jié)在答辯或者演示的時(shí)候經(jīng)常被問(wèn)到。演示數(shù)據(jù)也要認(rèn)真準(zhǔn)備。一個(gè)空空如也的系統(tǒng)沒(méi)法演示至少要塞進(jìn)去三五個(gè)房型、二十來(lái)間房、幾條不同狀態(tài)的訂單覆蓋今天預(yù)抵今天預(yù)離在住已取消這幾種情況房態(tài)圖看起來(lái)才像那么回事。7.2 打包和啟動(dòng)時(shí)最常見(jiàn)的幾個(gè)報(bào)錯(cuò)用 Spring Boot 的話mvn clean package之后直接java -jar坑通常在文件編碼和時(shí)區(qū)上。用 Servlet Tomcat 的老項(xiàng)目坑會(huì)多一些現(xiàn)象大概率原因處理方式中文亂碼請(qǐng)求編碼沒(méi)設(shè)或者 JSP 頁(yè)面沒(méi)寫(xiě)pageEncoding加CharacterEncodingFilterJSP 頭寫(xiě)% page contentTypetext/html;charsetUTF-8 %數(shù)據(jù)庫(kù)連接池啟動(dòng)就滿連接沒(méi)關(guān)或者配置文件里 maxActive 寫(xiě)太大用 try-with-resources檢查連接歸還時(shí)間差 8 小時(shí)服務(wù)器 JVM 時(shí)區(qū)是 UTC啟動(dòng)參數(shù)加-Duser.timezoneAsia/ShanghaiMySQL 連接串加serverTimezoneAsia/Shanghai頁(yè)面 404 但接口能通視圖解析器前綴后綴配錯(cuò)或者靜態(tài)資源被攔截器攔了檢查spring.mvc.view.prefix攔截器排除/static/**部署后上傳的圖片丟失文件存到了項(xiàng)目目錄里重新部署被覆蓋上傳目錄配成絕對(duì)路徑放到項(xiàng)目外時(shí)區(qū)那個(gè)問(wèn)題特別隱蔽因?yàn)樗陂_(kāi)發(fā)機(jī)上不出現(xiàn)本機(jī)時(shí)區(qū)通常是正確的一上服務(wù)器就冒出來(lái)而且表現(xiàn)是日期整體偏移一天很容易被誤判成日期計(jì)算寫(xiě)錯(cuò)了。7.3 交付時(shí)一定要寫(xiě)清楚的那幾頁(yè)紙技術(shù)上的東西都在代碼里運(yùn)營(yíng)上的東西只能靠文檔。我最少會(huì)準(zhǔn)備這幾份一份是操作手冊(cè)按角色寫(xiě)。前臺(tái)看的是怎么排房、怎么辦入住、怎么換房店長(zhǎng)看的是怎么看報(bào)表、怎么改房?jī)r(jià)。不要寫(xiě)成一個(gè)通用手冊(cè)沒(méi)人看。一份是房態(tài)圖例說(shuō)明把每種顏色的含義、每種狀態(tài)怎么流轉(zhuǎn)畫(huà)成一張表貼在墻上。前臺(tái)流動(dòng)性大新人來(lái)了照著圖就能上手。一份是常見(jiàn)問(wèn)題清單比如客人提前退房怎么處理押金多收了怎么退訂單下錯(cuò)了能不能改。這些問(wèn)題我是在試運(yùn)行第一周從門(mén)店微信群里攢下來(lái)的比任何需求文檔都真實(shí)。7.4 上線之后必然會(huì)遇到的三個(gè)需求第一個(gè)是導(dǎo)報(bào)表。不管你把報(bào)表做得多漂亮店長(zhǎng)最后一定會(huì)要 Excel。提前把導(dǎo)出接口寫(xiě)好用 EasyExcel 之類的庫(kù)別自己拼 CSV 拼出亂碼。第二個(gè)是打印。入住登記單、押金單、賬單都要打。瀏覽器直接window.print()打出來(lái)的格式通常很難看要做固定的打印模板把紙張尺寸常見(jiàn)是小票 80mm 或者 A5定死。第三個(gè)是手機(jī)端。老板一定會(huì)在手機(jī)上問(wèn)今天住了幾間。與其做一個(gè)完整的移動(dòng)端不如做一個(gè)只讀的看板頁(yè)面兩三個(gè)數(shù)字手機(jī)打開(kāi)就能看成本極低但滿意度極高。我自己的體會(huì)是這套系統(tǒng)真正的價(jià)值不在于用了什么框架而在于你有沒(méi)有把房態(tài)和訂單狀態(tài)這兩條線徹底分開(kāi)、有沒(méi)有用日期占位把并發(fā)問(wèn)題從根上摁住、有沒(méi)有在交付的時(shí)候多花半天把操作手冊(cè)寫(xiě)清楚。前兩件事決定了系統(tǒng)會(huì)不會(huì)出臟數(shù)據(jù)第三件事決定了門(mén)店愿不愿意繼續(xù)用。我第二次做的時(shí)候代碼量比第一次還少一些但因?yàn)檫@幾處想明白了試運(yùn)行兩周只改過(guò)三個(gè)小問(wèn)題跟第一次每天被追著改完全不是一個(gè)體驗(yàn)。