簡(jiǎn)介面向 Java 初學(xué)者的銀行賬戶(hù)轉(zhuǎn)賬模擬系統(tǒng)以圖形界面與多線(xiàn)程機(jī)制實(shí)現(xiàn)適合正在學(xué)習(xí) Swing 界面編程和線(xiàn)程并發(fā)的讀者幫助理解多線(xiàn)程共享賬戶(hù)余額時(shí)的讀寫(xiě)與同步問(wèn)題。程序設(shè)定 A、B 兩個(gè)初始余額均為 1000 元的賬戶(hù)由線(xiàn)程隨機(jī)向?qū)Ψ睫D(zhuǎn)賬轉(zhuǎn)賬金額不得大于當(dāng)前余額余額為零即無(wú)法繼續(xù)交易界面下方設(shè)有「交易開(kāi)始」「清屏」按鈕點(diǎn)擊開(kāi)始后按鈕切換為「結(jié)束交易」結(jié)束時(shí)將全部記錄寫(xiě)入 ab.txt。壓縮包共 2 個(gè) java 源文件分別承載窗口界面的構(gòu)建與轉(zhuǎn)賬線(xiàn)程邏輯整體僅約 2KB結(jié)構(gòu)緊湊便于導(dǎo)入 IDE 直接運(yùn)行和二次改造。已有 4171 人學(xué)習(xí)下載可作為課程實(shí)驗(yàn)、并發(fā)練習(xí)或課程設(shè)計(jì)的參考范例幫助讀者掌握界面事件響應(yīng)、線(xiàn)程調(diào)度與交易記錄持久化的完整實(shí)現(xiàn)思路。1. 銀行賬戶(hù)轉(zhuǎn)賬幾乎是每個(gè)做后端課程設(shè)計(jì)的人都寫(xiě)過(guò)的題目?jī)蓚€(gè)賬戶(hù)一扣一加包進(jìn)事務(wù)跑通就算完事。可并發(fā)一開(kāi)到 50余額對(duì)不上、偶發(fā)死鎖、超時(shí)重試后錢(qián)被扣兩次問(wèn)題會(huì)一起冒出來(lái)。這份模擬銀行賬戶(hù)轉(zhuǎn)賬系統(tǒng)的源碼包價(jià)值不在“能轉(zhuǎn)”而在它把賬戶(hù)表、流水表、事務(wù)邊界、冪等占位和對(duì)賬 SQL 都攤開(kāi)擺在明面上能順著一條鏈路看清錢(qián)從 A 到 B 的每一步也能看清哪一步最容易漏。適合正在做課程設(shè)計(jì)的學(xué)生、要給業(yè)務(wù)系統(tǒng)補(bǔ)一段結(jié)算邏輯的后端以及想把“事務(wù)到底加在哪一層”弄明白的開(kāi)發(fā)者。下面按拆包順序走數(shù)據(jù)模型、調(diào)用鏈路、冪等與對(duì)賬、踩坑現(xiàn)場(chǎng)最后是一套能自己跑的驗(yàn)證方法。2. 數(shù)據(jù)模型先立住賬戶(hù)表、流水表、單據(jù)表怎么擺拿到包先別急著跑main把建表腳本翻出來(lái)看一遍基本能判斷這套代碼是“能演示”還是“能改”。模擬轉(zhuǎn)賬系統(tǒng)里最常見(jiàn)的偷懶做法是只建一張account表扣款balance balance - x入賬balance balance x跑通了日志也漂亮。問(wèn)題是這套結(jié)構(gòu)沒(méi)有任何回溯能力賬一旦對(duì)不上你只能看著兩個(gè)數(shù)字發(fā)呆不知道是哪一筆、哪個(gè)時(shí)刻、哪個(gè)方向出的錯(cuò)。所以合格的做法一定是三張表起步——賬戶(hù)、單據(jù)、流水各管一件事。2.1 快照與事實(shí)分離為什么流水表不能省賬戶(hù)表存的是快照回答“現(xiàn)在有多少錢(qián)”流水表存的是事實(shí)回答“錢(qián)是怎么變成現(xiàn)在這樣的”。兩者的關(guān)系類(lèi)似庫(kù)存與出入庫(kù)單快照可以重算事實(shí)不能重寫(xiě)。只留快照的系統(tǒng)等于把賬本燒了只記住余額出了問(wèn)題連后悔藥都沒(méi)得吃。一筆轉(zhuǎn)賬在流水表里應(yīng)該落兩條記錄一條出賬DEBIT一條入賬CREDIT金額相等、方向相反。這樣就得到一個(gè)恒等式所有流水的出賬金額之和永遠(yuǎn)等于入賬金額之和誤差為零。這條恒等式是對(duì)賬時(shí)最強(qiáng)的斷言比任何“我核對(duì)了一遍余額”都可靠。很多課程設(shè)計(jì)只落一條“轉(zhuǎn)賬流水”把 from/to 塞進(jìn)同一行看著省事真出問(wèn)題時(shí)你沒(méi)法用 SQL 直接驗(yàn)證平衡性只能寫(xiě)代碼繞。單據(jù)表則是另一層一次轉(zhuǎn)賬請(qǐng)求對(duì)應(yīng)一行帶唯一單號(hào)它既是業(yè)務(wù)憑證也是冪等鍵。有了它“這筆請(qǐng)求到底成功沒(méi)有”這個(gè)問(wèn)題才有地方回答。三張表的分工可以記成一句話(huà)單據(jù)管請(qǐng)求流水管變化賬戶(hù)管現(xiàn)狀。2.2 建表 SQL三個(gè)約束把臟數(shù)據(jù)擋在數(shù)據(jù)庫(kù)門(mén)外下面是我在這個(gè)包里看到的表結(jié)構(gòu)我做了一點(diǎn)整理注釋補(bǔ)全了可以直接拿去跑。注意引擎必須是 InnoDBMyISAM 沒(méi)有事務(wù)也沒(méi)有行鎖這個(gè)場(chǎng)景下等于殘廢。-- 賬戶(hù)表只存當(dāng)前狀態(tài)balance 是快照 CREATE TABLE account ( id BIGINT NOT NULL AUTO_INCREMENT, account_no VARCHAR(32) NOT NULL COMMENT 賬號(hào)業(yè)務(wù)唯一鍵, owner_name VARCHAR(64) NOT NULL COMMENT 戶(hù)名演示用不存任何真實(shí)信息, balance DECIMAL(18,2) NOT NULL DEFAULT 0.00 COMMENT 可用余額單位元, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 0凍結(jié), created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_account_no (account_no), CONSTRAINT ck_balance_nonneg CHECK (balance 0) -- 最后一道防線(xiàn) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;-- 單據(jù)表一次轉(zhuǎn)賬請(qǐng)求一行order_no 同時(shí)是冪等鍵 CREATE TABLE transfer_order ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(40) NOT NULL COMMENT 冪等鍵客戶(hù)端生成或服務(wù)端雪花號(hào), from_account VARCHAR(32) NOT NULL, to_account VARCHAR(32) NOT NULL, amount DECIMAL(18,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0處理中 1成功 2失敗, fail_reason VARCHAR(255) DEFAULT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), -- 冪等靠它不靠先查后插 KEY idx_from_created (from_account, created_at) -- 查某賬戶(hù)最近轉(zhuǎn)出用 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;-- 流水表只追加不更新一筆轉(zhuǎn)賬兩條 CREATE TABLE account_flow ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(40) NOT NULL, account_no VARCHAR(32) NOT NULL, direction TINYINT NOT NULL COMMENT 1出賬 2入賬, amount DECIMAL(18,2) NOT NULL, balance_after DECIMAL(18,2) NOT NULL COMMENT 記賬后余額回溯時(shí)不用重算, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_acc_dir (order_no, account_no, direction), -- 防同一筆重復(fù)記賬 KEY idx_acc_id (account_no, id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;三個(gè)約束是這套表結(jié)構(gòu)的核心。uk_order_no讓并發(fā)下只有一條單據(jù)能插進(jìn)去重復(fù)請(qǐng)求在數(shù)據(jù)庫(kù)層面就被擋住uk_order_acc_dir保證同一筆單據(jù)對(duì)同一賬戶(hù)同一方向只能記一次賬重試邏輯寫(xiě)錯(cuò)了也不會(huì)雙記ck_balance_nonneg是余額的兜底任何繞過(guò)業(yè)務(wù)校驗(yàn)的路徑都會(huì)被數(shù)據(jù)庫(kù)拒絕。提示MySQL 5.7 及更早版本會(huì)解析CHECK但不執(zhí)行寫(xiě)上去只是注釋。上線(xiàn)前用SELECT VERSION();確認(rèn)8.0.16 以上才真正生效。如果只能跑 5.7這個(gè)斷言必須由應(yīng)用層和定時(shí)巡檢補(bǔ)上。索引也在為后面的查詢(xún)鋪路。idx_acc_id (account_no, id)是給“查某賬戶(hù)流水按時(shí)間倒序翻頁(yè)”準(zhǔn)備的用自增 id 代替 created_at 排序可以避免同一秒內(nèi)多條流水順序不穩(wěn)。idx_from_created用來(lái)做“某賬戶(hù)當(dāng)日轉(zhuǎn)出總額”這類(lèi)風(fēng)控口徑的統(tǒng)計(jì)。2.3 余額存字段還是實(shí)時(shí)匯總?cè)N方案的成本賬新手最容易糾結(jié)的一點(diǎn)既然有流水表為什么還要在賬戶(hù)表冗余一個(gè)balance直接SUM不行嗎能行但要看規(guī)模。三種常見(jiàn)方案的實(shí)際差別如下。方案余額怎么得到讀性能寫(xiě)性能一致性風(fēng)險(xiǎn)適用場(chǎng)景只存流水SUM(CASE WHEN direction2 THEN amount ELSE -amount END)差隨流水行數(shù)線(xiàn)性劣化好純追加低賬戶(hù)少、流水少的課堂演示余額字段 流水直接讀account.balance好主鍵或唯一索引命中中需行鎖保護(hù)中字段與流水可能不一致絕大多數(shù)業(yè)務(wù)系統(tǒng)余額字段 日終校準(zhǔn)讀字段定時(shí)任務(wù)用流水重算比對(duì)好中低有對(duì)賬任務(wù)的正式系統(tǒng)這個(gè)包用的是第二種也是我一般會(huì)選的讀多寫(xiě)少的場(chǎng)景下把計(jì)算成本壓到寫(xiě)入時(shí)一次性付掉。代價(jià)是必須在轉(zhuǎn)賬鏈路里保證“改余額”和“寫(xiě)流水”在同一個(gè)事務(wù)里否則就會(huì)出現(xiàn)賬戶(hù)扣了錢(qián)、流水沒(méi)落下的單邊賬。第三種是在第二種基礎(chǔ)上加定時(shí)校準(zhǔn)屬于線(xiàn)上系統(tǒng)的標(biāo)配課程設(shè)計(jì)里加一個(gè)每天凌晨跑的比對(duì)任務(wù)成本很低答辯時(shí)也是個(gè)加分項(xiàng)。有一點(diǎn)要提前說(shuō)清余額字段是冗余冗余就意味著可能不一致。所以系統(tǒng)里必須存在一條能從流水重算出余額的路徑哪怕它平時(shí)不跑。這條路徑就是你的后悔藥沒(méi)有它任何“余額好像不對(duì)”的反饋你都只能靠猜。3. 轉(zhuǎn)賬鏈路拆解一次請(qǐng)求里的鎖、事務(wù)和回滾表建好了接下來(lái)看錢(qián)的路徑。一次轉(zhuǎn)賬從 HTTP 進(jìn)來(lái)經(jīng)過(guò)參數(shù)校驗(yàn)、冪等占位、加鎖、校驗(yàn)、扣款、入賬、記流水、改單據(jù)狀態(tài)最后提交事務(wù)。這條鏈路上任何一步的位置放錯(cuò)都會(huì)在并發(fā)下暴露出來(lái)。這一章拆三段事務(wù)邊界畫(huà)在哪、鎖按什么順序拿、隔離級(jí)別和超時(shí)怎么配。3.1 事務(wù)邊界為什么Transactional只能貼在 Service 的公有方法上事務(wù)邊界的原則很簡(jiǎn)單一個(gè)事務(wù)只包住必須原子的一段數(shù)據(jù)庫(kù)操作越短越好。放在 Controller 上是錯(cuò)的把參數(shù)解析、序列化都包進(jìn)去了放在 Mapper 上也不對(duì)一次轉(zhuǎn)賬要?jiǎng)铀膹埍砜?Mapper正確位置是 Service 的公有方法而且這個(gè)方法必須是通過(guò) Spring 代理調(diào)用的。下面這幾件事千萬(wàn)別塞進(jìn)事務(wù)里調(diào)用外部接口、發(fā)消息、寫(xiě)文件日志、睡幾毫秒做“防重”。事務(wù)持有數(shù)據(jù)庫(kù)連接和行鎖任何耗時(shí)操作都在放大鎖沖突窗口。我見(jiàn)過(guò)把一次 HTTP 回調(diào)寫(xiě)在事務(wù)里的實(shí)現(xiàn)壓測(cè)時(shí)鎖等待直接打滿(mǎn)innodb_lock_wait_timeout一個(gè)接一個(gè)超時(shí)。常見(jiàn)做法是把外部調(diào)用挪到事務(wù)提交之后用事務(wù)同步回調(diào)或者本地消息表來(lái)保證最終一致。另一個(gè)容易忽略的點(diǎn)是rollbackFor。Spring 默認(rèn)只在遇到RuntimeException和Error時(shí)回滾受檢異常直接提交。也就是說(shuō)你throw new IOException()之后扣款已經(jīng)落庫(kù)了。// 錯(cuò)誤寫(xiě)法受檢異常不回滾扣款會(huì)留在庫(kù)里 Transactional public void transfer(TransferCmd cmd) throws Exception { ... } // 正確寫(xiě)法顯式聲明回滾異常類(lèi)型 Transactional(rollbackFor Exception.class) public void transfer(TransferCmd cmd) { ... }參數(shù)說(shuō)明rollbackFor Exception.class覆蓋所有異常如果業(yè)務(wù)上確實(shí)有“部分失敗也要提交”的場(chǎng)景用noRollbackFor單獨(dú)排除別靠吞異常來(lái)實(shí)現(xiàn)吞異常是后面第 5 章要重點(diǎn)說(shuō)的坑。3.2 加鎖順序與核心轉(zhuǎn)賬代碼并發(fā)轉(zhuǎn)賬出死鎖八成是鎖順序不一致。A 轉(zhuǎn) B 時(shí)先鎖 A 再鎖 BB 轉(zhuǎn) A 時(shí)先鎖 B 再鎖 A兩個(gè)事務(wù)各持一把等對(duì)方InnoDB 檢測(cè)到環(huán)路就干掉其中一個(gè)報(bào)Deadlock found when trying to get lock。解決辦法不復(fù)雜所有涉及雙賬戶(hù)的操作統(tǒng)一按賬號(hào)字典序升序加鎖。賬號(hào)是字符串用compareTo排排完再依次SELECT ... FOR UPDATE。Service public class TransferService { private final AccountMapper accountMapper; private final TransferOrderMapper orderMapper; private final AccountFlowMapper flowMapper; Transactional(rollbackFor Exception.class, isolation Isolation.READ_COMMITTED) public TransferResult transfer(TransferCmd cmd) { String orderNo cmd.getOrderNo(); // 1. 搶占冪等鍵并發(fā)下只有一個(gè)線(xiàn)程能插進(jìn) uk_order_no try { orderMapper.insertProcessing(orderNo, cmd.getFrom(), cmd.getTo(), cmd.getAmount()); } catch (DuplicateKeyException e) { // 重復(fù)請(qǐng)求不再轉(zhuǎn)賬直接返回上一次的結(jié)果 return orderMapper.queryResult(orderNo); } // 2. 統(tǒng)一加鎖順序賬號(hào)字典序小的先鎖 String first cmd.getFrom().compareTo(cmd.getTo()) 0 ? cmd.getFrom() : cmd.getTo(); String second first.equals(cmd.getFrom()) ? cmd.getTo() : cmd.getFrom(); Account a accountMapper.lockByNo(first); // SELECT ... FOR UPDATE Account b accountMapper.lockByNo(second); if (a null || b null) { throw new BizException(賬戶(hù)不存在); } if (a.getStatus() ! 1 || b.getStatus() ! 1) { throw new BizException(賬戶(hù)狀態(tài)異常); } // 3. 金額比較用 compareToBigDecimal 的 equals 會(huì)比較 scale if (a.getBalance().compareTo(cmd.getAmount()) 0) { throw new BizException(余額不足); } // 4. 帶條件的扣款即便上面的判斷失效這里也扣不成負(fù)數(shù) int updated accountMapper.debit(cmd.getFrom(), cmd.getAmount()); if (updated ! 1) { throw new BizException(扣款失敗余額不足); } accountMapper.credit(cmd.getTo(), cmd.getAmount()); // 5. 兩條流水出賬一條、入賬一條各帶記賬后余額 flowMapper.insert(orderNo, cmd.getFrom(), 1, cmd.getAmount(), accountMapper.selectBalance(cmd.getFrom())); flowMapper.insert(orderNo, cmd.getTo(), 2, cmd.getAmount(), accountMapper.selectBalance(cmd.getTo())); orderMapper.markSuccess(orderNo); return TransferResult.success(orderNo); } }對(duì)應(yīng)的 Mapper 里扣款語(yǔ)句必須帶條件這是余額不為負(fù)的最終保障!-- 扣款把判斷和更新合成一條語(yǔ)句消除檢查與執(zhí)行之間的窗口 -- update iddebit UPDATE account SET balance balance - #{amount}, updated_at NOW() WHERE account_no #{accountNo} AND balance gt; #{amount} /update !-- 入賬不需要條件加錢(qián)永遠(yuǎn)安全 -- update idcredit UPDATE account SET balance balance #{amount}, updated_at NOW() WHERE account_no #{accountNo} /update邏輯說(shuō)明第 1 步的冪等占位放在事務(wù)內(nèi)、業(yè)務(wù)操作之前讓重復(fù)請(qǐng)求在最早的地方被擋掉第 2 步的排序是關(guān)鍵它把“兩個(gè)事務(wù)互相等”這件事從根上消除第 4 步的updated ! 1判斷不能省它是把數(shù)據(jù)庫(kù)返回的影響行數(shù)當(dāng)作業(yè)務(wù)信號(hào)用——影響 0 行說(shuō)明條件不成立直接拋異?；貪L別硬著頭皮往下走。參數(shù)說(shuō)明isolation Isolation.READ_COMMITTED是可選項(xiàng)MySQL 默認(rèn)的可重復(fù)讀在這個(gè)場(chǎng)景下也能工作因?yàn)镕OR UPDATE是當(dāng)前讀。但讀已提交能讓鎖的持有范圍更小一些配合短事務(wù)更穩(wěn)。如果你的包用的是默認(rèn)隔離級(jí)別別為了這一行去改先跑通再說(shuō)。注意SELECT ... FOR UPDATE必須命中索引否則會(huì)退化成鎖全表。確認(rèn)account_no上有唯一索引且執(zhí)行計(jì)劃是typeeq_ref或ref。3.3 隔離級(jí)別、鎖等待和連接池的三個(gè)參數(shù)代碼寫(xiě)對(duì)了參數(shù)配錯(cuò)一樣出事。這個(gè)包里我調(diào)整過(guò)三個(gè)值都比較關(guān)鍵。第一個(gè)是innodb_lock_wait_timeout默認(rèn) 50 秒。轉(zhuǎn)賬這種短事務(wù)等 50 秒毫無(wú)意義只會(huì)把 Tomcat 線(xiàn)程和連接池一起拖死。改成 3 到 5 秒超時(shí)立刻失敗讓上游重試比干等強(qiáng)。-- 會(huì)話(huà)級(jí)先驗(yàn)證確認(rèn)無(wú)副作用后再寫(xiě)進(jìn)配置文件 SET SESSION innodb_lock_wait_timeout 5; SHOW VARIABLES LIKE innodb_lock_wait_timeout;第二個(gè)是 Spring 事務(wù)的timeout屬性單位秒。它和數(shù)據(jù)庫(kù)側(cè)的鎖等待超時(shí)是兩個(gè)層次的東西前者管整個(gè)事務(wù)方法的執(zhí)行時(shí)長(zhǎng)后者只管等鎖。兩個(gè)都要設(shè)Transactional(timeout 10)配合數(shù)據(jù)庫(kù) 5 秒能保證事務(wù)不會(huì)因?yàn)槟硹l慢 SQL 無(wú)限掛起。第三個(gè)是連接池大小。轉(zhuǎn)賬事務(wù)在高峰期同時(shí)占用連接數(shù)的上限就是池子的上限。池子太小會(huì)排隊(duì)太大會(huì)把數(shù)據(jù)庫(kù)打滿(mǎn)。經(jīng)驗(yàn)值是從 10 到 20 起壓測(cè)時(shí)看HikariPool的activeConnections和pendingThreads后者長(zhǎng)期大于 0 就說(shuō)明該加但別超過(guò)數(shù)據(jù)庫(kù)max_connections的七成。還有一個(gè)參數(shù)常被忽略spring.datasource.hikari.connection-timeout默認(rèn) 30 秒。轉(zhuǎn)賬接口的 RT 通常是幾十毫秒連接等待 30 秒沒(méi)有意義調(diào)到 3 秒左右讓過(guò)載快速失敗比雪崩好。4. 冪等與對(duì)賬重復(fù)提交、超時(shí)重試之后賬還對(duì)得上嗎真實(shí)場(chǎng)景里轉(zhuǎn)賬請(qǐng)求不會(huì)只來(lái)一次。用戶(hù)手抖點(diǎn)兩下、網(wǎng)關(guān)超時(shí)自動(dòng)重試、上游消息重復(fù)投遞都會(huì)讓你的接口收到同一個(gè)業(yè)務(wù)請(qǐng)求的多份副本。冪等不是加分項(xiàng)是底線(xiàn)。而對(duì)賬是冪等失效時(shí)的兜底兩者一套組合才能說(shuō)這個(gè)系統(tǒng)“賬是對(duì)的”。4.1 冪等占位用唯一索引搶鎖別用先查后插先查后插在并發(fā)下必然翻車(chē)因?yàn)椴樵?xún)和插入之間存在窗口兩個(gè)線(xiàn)程可以同時(shí)查到“不存在”。正確做法是把判斷交給數(shù)據(jù)庫(kù)order_no上加唯一索引插入成功的那一個(gè)線(xiàn)程繼續(xù)執(zhí)行失敗的直接走重復(fù)請(qǐng)求分支。這就是常說(shuō)的“用唯一約束做分布式鎖”。但這里有個(gè) Spring 層面的坑要提前避開(kāi)。如果冪等占位和業(yè)務(wù)操作在同一個(gè)事務(wù)里插入拋出的DuplicateKeyException被catch住了事務(wù)本身可能已經(jīng)被標(biāo)記為 rollback-only后續(xù)任何操作都會(huì)在提交時(shí)炸掉報(bào)Transaction rolled back because it has been marked as rollback-only。不同版本的代理行為有差異穩(wěn)妥的做法是把占位插入放到獨(dú)立事務(wù)里。// 獨(dú)立事務(wù)占位失敗不影響外層捕獲異常后事務(wù)仍是干凈的 Transactional(propagation Propagation.REQUIRES_NEW, rollbackFor Exception.class) public boolean tryOccupy(String orderNo, TransferCmd cmd) { try { orderMapper.insertProcessing(orderNo, cmd.getFrom(), cmd.getTo(), cmd.getAmount()); return true; // 搶到了繼續(xù)轉(zhuǎn)賬 } catch (DuplicateKeyException e) { return false; // 沒(méi)搶到說(shuō)明是重復(fù)請(qǐng)求 } }邏輯說(shuō)明REQUIRES_NEW會(huì)掛起外層事務(wù)、新開(kāi)一個(gè)插入失敗只影響這個(gè)內(nèi)層事務(wù)外層不受污染。返回false時(shí)外層直接查單據(jù)狀態(tài)返回結(jié)果不再執(zhí)行扣款。代價(jià)是多占一個(gè)連接所以這個(gè)方法必須極短不能在里面做任何查詢(xún)以外的事。參數(shù)說(shuō)明propagation選REQUIRES_NEW而不是NESTED因?yàn)镹ESTED依賴(lài)保存點(diǎn)某些連接池和驅(qū)動(dòng)下行為不一致。業(yè)務(wù)上還有個(gè)細(xì)節(jié)如果占位成功了但后面的轉(zhuǎn)賬失敗了單據(jù)狀態(tài)會(huì)停在 0處理中。這時(shí)不能簡(jiǎn)單刪掉重來(lái)得靠后面的狀態(tài)機(jī)和對(duì)賬處理。4.2 狀態(tài)機(jī)與失敗補(bǔ)償0/1/2 三個(gè)狀態(tài)夠不夠單據(jù)表里我用了三個(gè)狀態(tài)0 處理中、1 成功、2 失敗。夠用但有前提——必須有一套任務(wù)去清理長(zhǎng)期停在 0 的單據(jù)。處理中的單據(jù)意味著“占位成功但結(jié)果未知”?？赡艿脑虬ㄟM(jìn)程被 kill、數(shù)據(jù)庫(kù)連接斷開(kāi)、事務(wù)超時(shí)。這類(lèi)單據(jù)不能直接判成功也不能直接判失敗正確姿勢(shì)是查流水如果account_flow里已經(jīng)有這筆order_no的兩條記錄說(shuō)明錢(qián)動(dòng)過(guò)了把狀態(tài)補(bǔ)成 1如果沒(méi)有說(shuō)明事務(wù)回滾了補(bǔ)成 2。這個(gè)判斷依據(jù)流水而不是依據(jù)余額因?yàn)榱魉侵蛔芳拥氖聦?shí)。-- 清理僵尸單據(jù)30 分鐘前還是處理中且沒(méi)有任何流水 SELECT o.order_no FROM transfer_order o LEFT JOIN account_flow f ON f.order_no o.order_no WHERE o.status 0 AND o.created_at NOW() - INTERVAL 30 MINUTE GROUP BY o.order_no HAVING COUNT(f.id) 0;查到之后統(tǒng)一置為失敗并記錄原因。注意這條 SQL 要跑在只讀副本或者低峰期LEFT JOIN GROUP BY在單據(jù)量大時(shí)并不便宜加個(gè)時(shí)間范圍限定比如只掃最近三天。補(bǔ)償邏輯一定要做成可重復(fù)執(zhí)行的。定時(shí)任務(wù)重復(fù)跑、人工手動(dòng)觸發(fā)、服務(wù)重啟補(bǔ)跑都可能發(fā)生。判斷依據(jù)永遠(yuǎn)是“當(dāng)前狀態(tài) 流水是否存在”而不是“上次跑到哪了”。4.3 對(duì)賬 SQL三條查詢(xún)把不平的賬撈出來(lái)對(duì)賬不需要寫(xiě)代碼三條 SQL 基本能覆蓋課程設(shè)計(jì)和中小系統(tǒng)。第一條查單邊賬——單據(jù)成功但流水條數(shù)不對(duì)。-- 成功的單據(jù)流水必須正好兩條不等于 2 的就是單邊賬 SELECT o.order_no, o.amount, COUNT(f.id) AS flow_cnt FROM transfer_order o LEFT JOIN account_flow f ON f.order_no o.order_no WHERE o.status 1 GROUP BY o.order_no, o.amount HAVING COUNT(f.id) 2;第二條查金額不平——出賬和入賬金額必須相等差值不為零就是臟數(shù)據(jù)。-- 同一單據(jù)內(nèi)出賬金額 - 入賬金額 必須為 0 SELECT order_no, SUM(CASE WHEN direction 1 THEN amount ELSE -amount END) AS diff FROM account_flow GROUP BY order_no HAVING diff 0;第三條查余額斷裂——每條流水的balance_after應(yīng)該等于上一筆的balance_after加減本筆金額賬戶(hù)表當(dāng)前余額應(yīng)等于最后一筆流水的balance_after。第三條 SQL 稍長(zhǎng)思路是用窗口函數(shù)取上一行。-- 8.0 以上用 LAG 取上一筆余額驗(yàn)證流水鏈?zhǔn)欠襁B續(xù) WITH f AS ( SELECT account_no, id, direction, amount, balance_after, LAG(balance_after) OVER (PARTITION BY account_no ORDER BY id) AS prev_balance FROM account_flow ) SELECT * FROM f WHERE prev_balance IS NOT NULL AND balance_after prev_balance (CASE WHEN direction 2 THEN amount ELSE -amount END);三條查詢(xún)都返回空集才算這批數(shù)據(jù)是干凈的。前兩條可以隨時(shí)跑第三條在流水量大時(shí)要限賬戶(hù)否則窗口函數(shù)會(huì)掃全表。5. 避坑排查死鎖、負(fù)余額和“事務(wù)沒(méi)回滾”的五個(gè)現(xiàn)場(chǎng)這一章是我自己在跑這套代碼時(shí)踩到的五個(gè)現(xiàn)場(chǎng)按出現(xiàn)頻率排。每條都按“現(xiàn)象 → 原因 → 解決”寫(xiě)癥狀描述盡量貼近你會(huì)在日志里看到的那行字。5.1 現(xiàn)象并發(fā)壓測(cè)幾分鐘后開(kāi)始報(bào) Deadlock found現(xiàn)象50 并發(fā)雙向轉(zhuǎn)賬前 30 秒正常之后日志里零星出現(xiàn)Deadlock found when trying to get lock; try restarting transaction接口返回 500重試后又能成功。原因兩個(gè)方向的事務(wù)加鎖順序相反。A→B 先鎖 AB→A 先鎖 B交叉等待形成環(huán)路。InnoDB 檢測(cè)到環(huán)路會(huì)主動(dòng)殺掉代價(jià)小的那個(gè)事務(wù)被殺的拋出這個(gè)異常。另一個(gè)可能來(lái)源是SELECT ... FOR UPDATE沒(méi)走到account_no索引退化成鎖一批記錄甚至全表鎖范圍一大任何交叉都可能死鎖。解決按賬號(hào)字典序統(tǒng)一加鎖這是根本解。同時(shí)確認(rèn)執(zhí)行計(jì)劃EXPLAIN SELECT * FROM account WHERE account_no ? FOR UPDATE;應(yīng)該顯示typeconst或eq_ref。如果業(yè)務(wù)層無(wú)法保證順序比如批量代發(fā)把批量拆成單筆或者用SELECT ... FOR UPDATE時(shí)一次性按IN排序取回讓數(shù)據(jù)庫(kù)按索引順序加鎖而不是按IN列表順序。5.2 現(xiàn)象A 賬戶(hù)扣了錢(qián)B 賬戶(hù)沒(méi)收到單據(jù)狀態(tài)是成功現(xiàn)象對(duì)賬 SQL 查出單邊賬transfer_order狀態(tài)為 1但account_flow只有一條出賬記錄B 的余額沒(méi)變。原因入賬和出賬被拆到了兩個(gè)事務(wù)里。常見(jiàn)寫(xiě)法是扣款方法加Transactional入賬方法也加然后 Service 里順序調(diào)用。兩個(gè)方法各自提交中間任何失敗都會(huì)留下半成品。另一種是同一種病在try-catch里把入賬的異常吞了只打了日志事務(wù)照常提交。解決一筆轉(zhuǎn)賬的所有數(shù)據(jù)庫(kù)寫(xiě)操作必須在同一個(gè)事務(wù)邊界內(nèi)debit、credit、兩條流水、單據(jù)狀態(tài)更新全部由最外層的Transactional覆蓋。捕獲異常的地方只允許兩種處理要么原樣拋出觸發(fā)回滾要么記錄后拋出。任何“catch 了只打日志”的代碼都是定時(shí)炸彈。5.3 現(xiàn)象余額出現(xiàn)負(fù)數(shù)但業(yè)務(wù)校驗(yàn)沒(méi)報(bào)錯(cuò)現(xiàn)象定時(shí)對(duì)賬發(fā)現(xiàn)某賬戶(hù)balance -0.01查流水最后幾筆扣款都成功但當(dāng)時(shí)余額已經(jīng)不夠了。原因先SELECT查余額判斷夠不夠再UPDATE扣款。兩個(gè)動(dòng)作之間有窗口另一個(gè)事務(wù)插進(jìn)來(lái)把余額花掉了你的判斷基于舊值扣款照常執(zhí)行。這是最經(jīng)典的檢查與使用分離問(wèn)題TOCTOU。還有一種情況是CHECK (balance 0)在 5.7 上不生效應(yīng)用層又沒(méi)做條件更新直接扣穿。解決把判斷寫(xiě)進(jìn)UPDATE的WHERE里也就是AND balance #{amount}靠影響行數(shù)判斷成敗。這比任何鎖都輕。再加數(shù)據(jù)庫(kù)CHECK兜底確認(rèn)版本 8.0.16以及一條每日巡檢 SQL查balance 0的賬戶(hù)哪怕理論上不可能也要讓它報(bào)警。5.4 現(xiàn)象Transactional明明加了拋異常后數(shù)據(jù)還是落庫(kù)了現(xiàn)象故意在轉(zhuǎn)賬后拋RuntimeException期望回滾結(jié)果余額被改了單據(jù)也變成成功了。原因五種常見(jiàn)失效場(chǎng)景——方法不是publicSpring 代理攔不到同一個(gè)類(lèi)里this.method()自調(diào)用走不到代理異常被catch后沒(méi)重新拋拋的是受檢異常而沒(méi)配rollbackFor類(lèi)沒(méi)有被 Spring 管理自己new出來(lái)的對(duì)象。這五種現(xiàn)象一樣、原因各異排查時(shí)按這個(gè)順序?qū)?。解決自調(diào)用場(chǎng)景把方法拆到另一個(gè) Bean受檢異常統(tǒng)一配rollbackFor Exception.class類(lèi)上加Service且確保包掃描覆蓋最省事的驗(yàn)證方式是在事務(wù)方法里手動(dòng)拋一次異常看數(shù)據(jù)庫(kù)有沒(méi)有變化兩分鐘能排掉大部分疑慮。提示調(diào)試事務(wù)是否生效把日志級(jí)別開(kāi)到logging.level.org.springframework.transactionDEBUG能看到Creating new transaction/Rolling back這類(lèi)關(guān)鍵行比讀代碼快。5.5 現(xiàn)象對(duì)賬差一分錢(qián)反復(fù)對(duì)數(shù)都對(duì)不上現(xiàn)象總額守恒的校驗(yàn)差 0.01逐個(gè)賬戶(hù)查又都能對(duì)上只有某些涉及手續(xù)費(fèi)的記錄不平。原因double參與金額計(jì)算。0.1 0.2在二進(jìn)制浮點(diǎn)里不等于0.3這個(gè)誤差會(huì)在多次累加后變成一分錢(qián)。另一種原因是在中間步驟就setScale四舍五入每步都舍一次誤差累積。還有一種BigDecimal.equals()比較時(shí)把scale也比了1.0和1.00判不相等導(dǎo)致校驗(yàn)邏輯誤判。解決金額全程BigDecimal且只用字符串構(gòu)造new BigDecimal(0.01)絕不用new BigDecimal(0.01)。比較用compareTo() 0。舍入只在最終落庫(kù)那一刻做一次setScale(2, RoundingMode.HALF_UP)。手續(xù)費(fèi)在什么環(huán)節(jié)扣、按什么基數(shù)算寫(xiě)進(jìn)注釋別靠人記。6. 壓測(cè)驗(yàn)證用 200 并發(fā)和三條斷言驗(yàn)收賬平不平跑通單筆轉(zhuǎn)賬只能說(shuō)明代碼能編譯驗(yàn)證賬對(duì)不對(duì)還得靠并發(fā)。我一般會(huì)寫(xiě)個(gè)最土的壓測(cè)腳本先制造混亂再用斷言收口比看一堆日志有說(shuō)服力。#!/usr/bin/env bash # 200 個(gè)并發(fā)請(qǐng)求每個(gè)請(qǐng)求單號(hào)唯一同時(shí)故意發(fā) 50 個(gè)重復(fù)單號(hào)試冪等 BASEhttp://localhost:8080/api/transfer seq 1 200 | xargs -P 50 -I{} curl -s -o /dev/null -w %{http_code}\n \ -X POST $BASE \ -H Content-Type: application/json \ -d {\orderNo\:\T20240{}\,\from\:\ACC0001\,\to\:\ACC0002\,\amount\:\1.00\} # 冪等驗(yàn)證同一個(gè)單號(hào)打 50 次最終只應(yīng)有一條單據(jù)、兩條流水 seq 1 50 | xargs -P 50 -I{} curl -s -o /dev/null \ -X POST $BASE \ -H Content-Type: application/json \ -d {orderNo:IDEMPOTENT-001,from:ACC0003,to:ACC0004,amount:2.00}腳本里-P 50是并發(fā)度-w %{http_code}把狀態(tài)碼打出來(lái)方便統(tǒng)計(jì)失敗率。跑完先看接口層200 個(gè)請(qǐng)求里成功多少、超時(shí)多少、5xx 多少。低于 95% 成功率就先去查鎖等待和連接池別急著分析數(shù)據(jù)。數(shù)據(jù)層的驗(yàn)收是三條斷言全過(guò)才算這套實(shí)現(xiàn)站得住。-- 斷言一總額守恒轉(zhuǎn)賬不創(chuàng)造也不銷(xiāo)毀錢(qián) SELECT SUM(balance) AS total_after FROM account; -- 應(yīng)等于壓測(cè)前記錄的初始總額 -- 斷言二成功單據(jù)的流水凈額必須為 0 SELECT order_no, SUM(CASE WHEN direction 1 THEN amount ELSE -amount END) AS diff FROM account_flow GROUP BY order_no HAVING diff 0; -- 斷言三冪等單號(hào)只被真正執(zhí)行一次 SELECT COUNT(*) AS flow_cnt FROM account_flow WHERE order_no IDEMPOTENT-001; -- 應(yīng)為 2斷言一是最硬的那條。壓測(cè)前后各跑一次兩個(gè)數(shù)字必須完全相等差一分都說(shuō)明有事務(wù)沒(méi)回滾干凈或者有寫(xiě)入繞過(guò)了流水。斷言二驗(yàn)證每筆單據(jù)內(nèi)部平衡斷言三驗(yàn)證冪等占位是否真的擋住了 49 次重復(fù)請(qǐng)求。觀測(cè)指標(biāo)建議同時(shí)盯住四個(gè)用一張表記下來(lái)比憑感覺(jué)判斷靠譜。指標(biāo)從哪看健康區(qū)間異常時(shí)先查T(mén)PS壓測(cè)工具匯總穩(wěn)定不抖連接池、慢 SQLP99 響應(yīng)時(shí)間壓測(cè)工具匯總小于鎖等待超時(shí)的一半innodb_lock_wait_timeout死鎖次數(shù)SHOW ENGINE INNODB STATUS\G的 LATEST DETECTED DEADLOCK0加鎖順序、索引命中活躍連接數(shù)Hikari 的activeConnections小于池上限的 80%事務(wù)是否過(guò)長(zhǎng)這套流程我現(xiàn)在每次改完轉(zhuǎn)賬相關(guān)代碼都會(huì)完整走一遍哪怕只是把一個(gè)SELECT改成UPDATE。因?yàn)椤翱雌饋?lái)等價(jià)”的改動(dòng)在并發(fā)下經(jīng)常不等價(jià)而賬目類(lèi)的 bug 一旦上線(xiàn)損失的不是性能而是可信度。上面這些建表語(yǔ)句、Service 骨架和對(duì)賬 SQL 都來(lái)自這份模擬銀行賬戶(hù)轉(zhuǎn)賬系統(tǒng)的源碼包改一改就能塞進(jìn)自己的課程設(shè)計(jì)或者業(yè)務(wù)模塊里跑起來(lái)先從單筆跑通再上并發(fā)腳本別跳步。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取