寫后端代碼這些年“事務(wù)”這兩個字我聽了不下幾百遍但真正把它從概念變成肌肉記憶是從一次線上資損事故開始的。那次問題非常簡單兩個賬戶之間做金額劃撥更新余額的 SQL 執(zhí)行到一半數(shù)據(jù)庫連接斷了結(jié)果一方金額已經(jīng)扣減、另一方還沒加上。整個團隊排查了一整晚最后的修復(fù)方案不過是給這段邏輯套上一個數(shù)據(jù)庫事務(wù)——但這也讓我徹底看清楚了數(shù)據(jù)庫事務(wù)解決的是并發(fā)和異常場景下的數(shù)據(jù)一致性它不是一個“錦上添花”的功能而是很多業(yè)務(wù)系統(tǒng)的底線。這篇內(nèi)容我打算從最樸素的問題講起把事務(wù)的原理、隔離級別、底層日志機制以及業(yè)務(wù)代碼里最常見的事務(wù)坑一次說清楚。適合剛?cè)胄械拈_發(fā)也適合那些“知道事務(wù)但沒系統(tǒng)梳理過”的同事?？赐曛竽銜l(fā)現(xiàn)事務(wù)并不只是BEGIN和COMMIT兩行關(guān)鍵字它背后是一整套關(guān)于“怎么安全地改變數(shù)據(jù)”的設(shè)計。1. 先搞清楚事務(wù)到底在防什么1.1 沒有事務(wù)時一個轉(zhuǎn)賬都做不對假設(shè)你要給另一個賬戶轉(zhuǎn) 100 元日常操作會被拆成兩條 SQLUPDATE account SET balance balance - 100 WHERE id 1; UPDATE account SET balance balance 100 WHERE id 2;第一條 SQL 把賬戶 A 的余額減掉 100第二條把賬戶 B 的余額加上 100。在一個理想世界里兩條 SQL 按順序執(zhí)行數(shù)據(jù)庫永遠(yuǎn)不出錯連接永遠(yuǎn)不中斷那事務(wù)確實沒多大存在感。但現(xiàn)實是SQL 可能執(zhí)行失敗應(yīng)用正在發(fā)布重啟網(wǎng)絡(luò)抖動讓連接超時磁盤滿導(dǎo)致寫入報錯…… 只要第一條成功、第二條沒成功資金就憑空消失了。這就是事務(wù)最核心的存在價值把一組操作綁定成一個不可分割的整體要么全部成功要么全部失敗。用事務(wù)包住上面兩條更新之后如果第二條失敗數(shù)據(jù)庫會自動把第一條的回滾掉賬戶 A 的錢不會少START TRANSACTION; UPDATE account SET balance balance - 100 WHERE id 1; UPDATE account SET balance balance 100 WHERE id 2; COMMIT;你可能會想單條 SQL 本身不就是要么成功要么失敗嗎是的但業(yè)務(wù)從來不只是單條 SQL。一個下單動作可能要寫訂單表、扣庫存表、寫流水表一個審批動作可能要更新審批單、記錄日志、通知下一節(jié)點。只要是多步寫操作就有“寫到一半出事”的可能就需要事務(wù)。1.2 ACID 四個屬性一個一個拆教科書里喜歡把事務(wù)的特性總結(jié)成 ACID也就是原子性、一致性、隔離性、持久性。這四個詞看著抽象其實對應(yīng)到真實場景非常具體。原子性Atomicity指的是事務(wù)里的操作像一個原子一樣不可再分。要么全做要么全不做。剛才轉(zhuǎn)賬例子里的兩條 UPDATE在事務(wù)里就屬于一個原子操作。原子性在底層主要靠 undo log 實現(xiàn)事務(wù)執(zhí)行過程中如果出錯或者主動回滾數(shù)據(jù)庫通過 undo log 把已經(jīng)修改的數(shù)據(jù)恢復(fù)原樣。一致性Consistency說的是事務(wù)執(zhí)行前后數(shù)據(jù)都必須滿足業(yè)務(wù)規(guī)則。比如賬戶余額不能為負(fù)數(shù)、訂單狀態(tài)不能從“已支付”跳回“待支付”。這里要注意一致性其實有一部分是業(yè)務(wù)自己保證的數(shù)據(jù)庫只能保證約束層面的“一致”像唯一索引、外鍵、非空約束等。至于“轉(zhuǎn)賬不能轉(zhuǎn)出負(fù)數(shù)”這種邏輯如果你代碼里沒判斷事務(wù)并不會替你糾正。很多新手容易把一致性和原子性混在一起實際上原子性保證“操作不中斷”一致性保證“數(shù)據(jù)不失真”。隔離性Isolation針對的是并發(fā)場景多個事務(wù)同時在跑彼此之間不能互相干擾。但“不能干擾”到什么程度數(shù)據(jù)庫提供了不同選項這就是后面要說的隔離級別。如果完全沒有隔離性兩個事務(wù)同時改一行數(shù)據(jù)最后結(jié)果取決于誰后提交另一個人的更新就丟了這在賬務(wù)系統(tǒng)里是不可接受的。持久性Durability承諾事務(wù)一旦提交數(shù)據(jù)就不會丟哪怕數(shù)據(jù)庫立刻宕機。持久性主要靠 redo log 來保證崩潰后數(shù)據(jù)庫重啟時會重放日志把已提交但還沒來得及落盤的數(shù)據(jù)恢復(fù)出來。注意原子性的回滾只針對事務(wù)內(nèi)已經(jīng)執(zhí)行的 SQL。如果你在事務(wù)里發(fā)了 HTTP 請求、寫了 Redis、調(diào)了消息隊列這些動作都不受數(shù)據(jù)庫事務(wù)保護。事務(wù)回滾了外呼請求已經(jīng)發(fā)出去了這種“跨系統(tǒng)一致性”問題事務(wù)解決不了需要引入別的方案。1.3 什么場景值得開事務(wù)不是所有代碼都需要事務(wù)。如果你只是查一條數(shù)據(jù)、做一次簡單的單行更新事務(wù)意義不大。但下面這些場景我建議你務(wù)必用事務(wù)包住多表更新比如訂單主表和訂單明細(xì)表必須同時寫入。賬戶類操作余額變動、積分變動先查后改再記錄流水。庫存預(yù)占下單時扣減庫存同時生成訂單記錄。狀態(tài)機流轉(zhuǎn)一個狀態(tài)要經(jīng)過多步驟更新任何一步失敗都要回退。一句話總結(jié)判斷標(biāo)準(zhǔn)如果這組操作只成功了一半數(shù)據(jù)還能見人嗎不能見人就開事務(wù)。2. 隔離級別并發(fā)下的事務(wù)“視力”差異2.1 三個并發(fā)問題怎么理解先看一個最常見的場景兩個事務(wù)同時操作同一行數(shù)據(jù)或者同一個范圍的數(shù)據(jù)。這時如果隔離做得不夠就會出現(xiàn)三類經(jīng)典問題。臟讀事務(wù) A 修改了一行數(shù)據(jù)還沒提交事務(wù) B 讀到了這個未提交的修改。然后 A 回滾了那 B 剛才讀到的數(shù)據(jù)就是“臟數(shù)據(jù)”是根本不存在過的數(shù)據(jù)。比如你把訂單狀態(tài)改成“已支付”事務(wù)還沒提交同事的報表任務(wù)已經(jīng)把“已支付”統(tǒng)計進去了下一秒你回滾了報表數(shù)據(jù)就錯了。不可重復(fù)讀事務(wù) A 先讀一次某行數(shù)據(jù)得到值 X事務(wù) B 在這期間修改了這行并提交事務(wù) A 再讀一次得到值 Y。同一個事務(wù)里兩次讀同一行結(jié)果不同。這在報表、統(tǒng)計類場景里非常致命——你按時間段統(tǒng)計金額第一次統(tǒng)計和第二統(tǒng)計結(jié)果不同報表就對不上賬?；米x事務(wù) A 查詢某個范圍的數(shù)據(jù)比如“查詢狀態(tài)為待支付的訂單”第一次查出 10 條事務(wù) B 插入了一條新的待支付訂單并提交事務(wù) A 再查一次查出 11 條。多出來的那條就像“幻覺”一樣憑空出現(xiàn)。幻讀和不可重復(fù)讀的區(qū)別在于不可重復(fù)讀是同一行內(nèi)容變了幻讀是整個集合的行數(shù)變了。這三個問題可以放在一張表里對比問題本質(zhì)是否讀到未提交數(shù)據(jù)同一行內(nèi)容變化查詢行數(shù)變化臟讀讀到未提交數(shù)據(jù)是可能可能不可重復(fù)讀已提交數(shù)據(jù)被其他事務(wù)修改否是否幻讀其他事務(wù)插入新行否否是2.2 四種隔離級別選哪個SQL 標(biāo)準(zhǔn)給出了四個隔離級別隔離強度從低到高Read Uncommitted讀未提交允許讀未提交數(shù)據(jù)基本等于不隔離臟讀、不可重復(fù)讀、幻讀都可能發(fā)生。實際生產(chǎn)環(huán)境幾乎沒人用除非你對數(shù)據(jù)準(zhǔn)確性完全不在乎。Read Committed讀已提交只能讀到已提交的數(shù)據(jù)解決了臟讀。但事務(wù) A 兩次讀同一行時如果事務(wù) B 在中間修改并提交了A 第二次讀到的值會變所以不可重復(fù)讀依然存在。這是很多數(shù)據(jù)庫的默認(rèn)級別比如 PostgreSQL、Oracle。Repeatable Read可重復(fù)讀保證了同一個事務(wù)內(nèi)多次讀取同一行結(jié)果一致。它解決了不可重復(fù)讀但沒有徹底解決幻讀。MySQL 的 InnoDB 默認(rèn)就是這個級別并且通過 next-key lock 在多數(shù)場景下連幻讀也一起解決了。Serializable串行化最強隔離級別事務(wù)之間完全串行執(zhí)行讀寫都要加鎖并發(fā)能力極低。除非是銀行對賬、極度敏感的數(shù)據(jù)批處理否則不建議線上使用。實際項目里Read Committed 和 Repeatable Read 是兩個最常見的選項。選哪個不只看“哪個更安全”還要看你愿不愿意為隔離付出鎖和性能代價。級別越高通常意味著并發(fā)度越低接口延遲越容易飆上去。2.3 隔離級別不是靠鎖硬扛出來的MVCC 才是主角很多人以為事務(wù)隔離是靠全程加鎖實現(xiàn)的讀數(shù)據(jù)之前鎖住讀完之后解鎖。如果真這樣并發(fā)性能會慘不忍睹。現(xiàn)代數(shù)據(jù)庫普遍采用MVCC多版本并發(fā)控制來優(yōu)化讀性能。MVCC 的思路是同一行數(shù)據(jù)在數(shù)據(jù)庫里不只有一個版本每次更新都會生成一個新版本舊版本保留一段時間。事務(wù)讀數(shù)據(jù)時根據(jù)自己開啟事務(wù)的時間快照選擇一個“應(yīng)該看到”的版本。所以讀操作不會阻塞寫操作寫操作也不會阻塞讀操作。舉個例子事務(wù) A 開啟后它讀某行時看到的是一份快照版本之后事務(wù) B 修改了這行并提交A 再次讀這行時根據(jù)隔離級別的規(guī)則A 可能仍然讀快照里的舊版本這就是“可重復(fù)讀”能重復(fù)的原因。底層實現(xiàn)涉及隱藏列、版本鏈和 Read View 機制這里先不展開后文講 undo log 時會再提到。你只需要記住一句話MVCC 讓“讀”和“寫”盡量并行隔離級別只是決定了一個事務(wù)能看到歷史上哪些版本。3. 底層“記日志”機制事務(wù)是怎么做到能回滾又能恢復(fù)的3.1 redo log 與寫入順序事務(wù)提交時數(shù)據(jù)不可能立刻刷進磁盤。原因很簡單磁盤隨機寫入太慢如果把每一行修改都實時刷盤數(shù)據(jù)庫性能會低到?jīng)]法用。所以數(shù)據(jù)庫采用了一個經(jīng)典策略先寫日志再寫數(shù)據(jù)。這個策略叫 WAL也就是 Write-Ahead Logging。事務(wù)執(zhí)行過程中針對每一行修改數(shù)據(jù)庫會先寫一條 redo log記錄“哪個頁、哪個偏移量、改成了什么”。redo log 是順序?qū)懭氲男阅苓h(yuǎn)高于隨機寫盤。事務(wù)提交時只要 redo log 成功落盤事務(wù)就算提交成功了即使數(shù)據(jù)頁還沒寫回磁盤也問題不大。萬一數(shù)據(jù)庫崩潰重啟時會通過 redo log 把已提交的數(shù)據(jù)恢復(fù)出來保證持久性。你可以把 redo log 理解為快遞的“運單記錄”包裹數(shù)據(jù)還沒送到但運單已經(jīng)登記了。只要運單在哪怕中途車壞了總能按運單把包裹補送。如果沒有運單丟哪件都查不出來。3.2 undo log 與回滾redo log 負(fù)責(zé)“向前恢復(fù)”undo log 則負(fù)責(zé)“向后回滾”。事務(wù)執(zhí)行過程中每次修改數(shù)據(jù)前數(shù)據(jù)庫會把修改前的值記錄到 undo log 里。如果事務(wù)回滾數(shù)據(jù)庫就根據(jù) undo log 把數(shù)據(jù)倒回原來的樣子。undo log 還有一個重要用途它保存了每一行的歷史版本MVCC 正是通過 undo log 構(gòu)成的版本鏈讓讀操作能找到符合快照條件的舊版本?？梢哉f沒有 undo log隔離級別里的“可重復(fù)讀”就只能靠加鎖硬實現(xiàn)性能會完全不同?；貪L不是萬能的。如果一個事務(wù)里執(zhí)行了DROP TABLE這類 DDL 操作很多數(shù)據(jù)庫會隱式提交當(dāng)前事務(wù)之前的修改就無法撤銷了。所以你在代碼里要特別注意不要把 DDL 和 DML 混在同一個事務(wù)里還指望回滾救你。3.3 一條 UPDATE 語句的完整旅程把上面兩塊拼起來看一條 UPDATE 在事務(wù)里的生命周期大致是這樣的事務(wù)開啟拿到一個事務(wù) ID。執(zhí)行 UPDATE數(shù)據(jù)庫先加載目標(biāo)行到內(nèi)存緩沖池。寫 undo log記錄修改前的值。修改內(nèi)存中的數(shù)據(jù)頁。寫 redo log記錄修改后的值和對應(yīng)頁信息此時日志處于 prepare 狀態(tài)。事務(wù)繼續(xù)執(zhí)行其他 SQL重復(fù)上述過程。執(zhí)行 COMMITredo log 進入 commit 狀態(tài)并落盤。事務(wù)結(jié)束后續(xù)數(shù)據(jù)頁會在合適的時機由后臺線程刷入磁盤。如果第 7 步之前任何環(huán)節(jié)出錯數(shù)據(jù)庫會利用 undo log 回滾如果第 7 步之后數(shù)據(jù)庫崩潰redo log 能保證已提交事務(wù)不丟。這套機制就是事務(wù)可靠性的地基。理解它之后很多面試題里的“為什么事務(wù)提交這么快”“為什么數(shù)據(jù)庫宕機后數(shù)據(jù)不丟”就都有了答案。4. 業(yè)務(wù)代碼里的實用事務(wù)操作與邊界設(shè)計4.1 三種常見開啟方式事務(wù)在代碼里最常見的三種落地方式我一個個說。第一種是 SQL 層手動控制START TRANSACTION; -- 業(yè)務(wù) SQL UPDATE account SET balance balance - 100 WHERE id 1; UPDATE account SET balance balance 100 WHERE id 2; COMMIT; -- 出錯時執(zhí)行 ROLLBACK;這種方式適合寫存儲過程、腳本或者需要精細(xì)控制提交時機的場景。但要注意START TRANSACTION之后如果忘記COMMIT事務(wù)會一直掛著連接也不釋放這在連接池場景里會快速耗盡數(shù)據(jù)庫連接。第二種是應(yīng)用框架注解比如 Java 里常見的TransactionalTransactional public void transfer(Long fromId, Long toId, BigDecimal amount) { accountMapper.decrease(fromId, amount); accountMapper.increase(toId, amount); }注解方式讓代碼看著干凈但它隱藏了大量細(xì)節(jié)。默認(rèn)情況下只有運行時異常觸發(fā)回滾受檢異常不會回滾。也就是說如果你的方法里拋出的是業(yè)務(wù)檢查異常事務(wù)可能照樣提交了。很多線上數(shù)據(jù)不一致的 bug 就是這么來的。第三種是編程式事務(wù)手動在代碼里開啟、提交、回滾TransactionStatus status transactionManager.getTransaction(); try { // 業(yè)務(wù)邏輯 transactionManager.commit(status); } catch (Exception e) { transactionManager.rollback(status); throw e; }這種方式最靈活但代碼侵入性也最強。簡單業(yè)務(wù)用注解足夠事務(wù)邊界復(fù)雜的再考慮編程式。4.2 事務(wù)越短越好的邊界原則我在實際 code review 里見過最多的問題不是不寫事務(wù)而是“把太多東西塞進事務(wù)”。記住幾條邊界原則第一事務(wù)里不要做遠(yuǎn)程調(diào)用。HTTP 請求、RPC 調(diào)用、外部接口訪問這些操作的耗時不可控。事務(wù)內(nèi)請求時間越長持有的鎖就越久其他事務(wù)等待的時間就越長。假設(shè)一個事務(wù)里調(diào)了外部接口接口超時 30 秒這 30 秒內(nèi)相關(guān)數(shù)據(jù)行全部被鎖住線上接口可能直接雪崩。正確做法是先本地落庫提交事務(wù)再異步發(fā)消息或調(diào)外部接口。第二事務(wù)里不要做大批量循環(huán)寫入。比如循環(huán) 5000 次執(zhí)行 UPDATE每次都涉及鎖和日志事務(wù)整體耗時可能好幾秒。更合理的做法是拆分批次或者先預(yù)處理再批量寫入讓單個事務(wù)的持鎖時間盡量短。第三事務(wù)里不要有太重的查詢。雖然 MVCC 讓普通查詢不加鎖但如果你在事務(wù)里用了SELECT ... FOR UPDATE這種加鎖讀或者查詢本身特別慢鎖的持有時間同樣會被拖長。事務(wù)不是不能查詢而是不要做與分析業(yè)務(wù)無關(guān)的重查詢。4.3 事務(wù)傳播行為與嵌套問題框架類事務(wù)通常還提供“傳播行為”簡單說就是當(dāng)多個事務(wù)方法嵌套調(diào)用時是共用同一個事務(wù)還是各開各的事務(wù)。常見的有 REQUIRED、REQUIRES_NEW、NESTED 等。REQUIRED 是默認(rèn)行為如果外層已經(jīng)有事務(wù)內(nèi)層方法直接加入外層事務(wù)內(nèi)層拋異常會導(dǎo)致整個外層事務(wù)回滾。REQUIRES_NEW 則是內(nèi)層方法強制新開一個獨立事務(wù)外層事務(wù)跟它互不干擾適合“日志記錄”這種不管主流程成敗都要落庫的場景。NESTED 是嵌套事務(wù)內(nèi)層可以部分回滾但外層整體狀態(tài)仍然參與全局提交或回滾。一個非常經(jīng)典的坑是自調(diào)用失效。同一個類里的方法 A 調(diào)方法 BB 上有事務(wù)注解但 A 沒有此時 B 的事務(wù)可能根本不生效。原因很簡單事務(wù)是通過代理對象攔截的類內(nèi)部this調(diào)用不會走代理。很多同事排查半天最后發(fā)現(xiàn)是自調(diào)用問題。解決辦法是把 B 拆到另一個類或者注入自身代理調(diào)用再或者用編程式事務(wù)兜底。5. 線上問題排查實錄與常見坑5.1 死鎖兩個事務(wù)互相等鎖死鎖是事務(wù)并發(fā)里最典型的“交通事故”。舉一個最簡單的例子事務(wù) A 更新了 id1 的行事務(wù) B 更新了 id2 的行接著 A 想更新 id2B 想更新 id1。兩邊都在等對方釋放鎖誰都不肯放手?jǐn)?shù)據(jù)庫只能靠死鎖檢測機制選擇犧牲一個事務(wù)讓它回滾并報錯。排查死鎖時我一般先看數(shù)據(jù)庫的鎖等待日志。以 MySQL 為例執(zhí)行SHOW ENGINE INNODB STATUS可以看到最近一次死鎖涉及的事務(wù)、執(zhí)行的 SQL、等待的鎖對象?？吹饺罩竞髢?yōu)化思路通常是讓所有事務(wù)按相同順序訪問資源比如更新多行時先按主鍵排序?？s小事務(wù)范圍減少持有鎖的時間。避免事務(wù)里做太多無關(guān)操作。合理使用索引讓鎖落在盡量少的行上。如果你發(fā)現(xiàn)某個接口頻繁報死鎖先不要急著加鎖或換隔離級別先看 SQL 的執(zhí)行計劃很多時候是沒走索引導(dǎo)致鎖了全表。5.2 長事務(wù)連接池耗盡和 undo 膨脹長事務(wù)是指“長時間不提交也不回滾”的事務(wù)。它的危害有兩層一是長期持有鎖阻塞其他事務(wù)二是不停產(chǎn)生 undo log導(dǎo)致歷史版本堆積數(shù)據(jù)庫文件膨脹查詢性能下降。有一次排查線上接口變慢我查了information_schema.innodb_trx發(fā)現(xiàn)有事務(wù)跑了將近 40 分鐘還沒提交。順著線索找到代碼發(fā)現(xiàn)是一位同事在事務(wù)里調(diào)了外部接口外部接口超時 30 分鐘事務(wù)就一直掛著。處理辦法很簡單把外部調(diào)用移出事務(wù)事務(wù)體只保留純數(shù)據(jù)庫操作。監(jiān)控長事務(wù)時可以定期執(zhí)行類似下面的查詢找出長時間未提交的事務(wù)SELECT trx_id, trx_state, trx_started, trx_rows_locked FROM information_schema.innodb_trx WHERE trx_state RUNNING;看到trx_started距離當(dāng)前時間超過閾值就該告警了。另外連接池耗盡很多時候也是長事務(wù)引起的連接被事務(wù)占住不放新的請求拿不到連接接口全部排隊。5.3 快照讀與當(dāng)前讀不一致這是 Repeatable Read 級別下一個非常隱蔽的問題。同一個事務(wù)里普通SELECT是快照讀讀到的是事務(wù)開啟那一刻的快照而UPDATE、DELETE、SELECT ... FOR UPDATE是當(dāng)前讀讀取的是最新已提交數(shù)據(jù)。兩者混用時可能出現(xiàn)“先查詢到舊數(shù)據(jù)再更新時卻基于新數(shù)據(jù)計算”的詭異現(xiàn)象。舉個實際例子事務(wù)里先SELECT balance拿到 100然后執(zhí)行UPDATE ... SET balance balance - 50。這個 UPDATE 內(nèi)部讀到的 balance 可能是別人已經(jīng)改過的 200最終算出 150和你期望的 50 完全不同。這類問題很難靠直覺發(fā)現(xiàn)建議在設(shè)計事務(wù)邏輯時明確自己用的是快照讀還是當(dāng)前讀需要嚴(yán)格基于最新值計算時就直接用SELECT ... FOR UPDATE加鎖讀不要依賴“查一次再改一次”的默認(rèn)行為。5.4 事務(wù)問題速查表癥狀可能原因排查方法處理建議數(shù)據(jù)更新丟失事務(wù)隔離級別過低或沒有加鎖檢查隔離級別和 SQL 加鎖情況提高隔離級別或使用SELECT ... FOR UPDATE接口報死鎖多個事務(wù)鎖順序不一致SHOW ENGINE INNODB STATUS查看死鎖日志統(tǒng)一資源訪問順序縮小事務(wù)范圍連接池被占滿長事務(wù)未提交查詢information_schema.innodb_trx找到長事務(wù)對應(yīng)的代碼移除外呼操作事務(wù)回滾沒生效異常類型不被事務(wù)管理器捕獲確認(rèn)異常是否為運行時異常檢查Transactional配置顯式指定回滾異常類型數(shù)據(jù)變了但日志沒記錄事務(wù)提交后外呼失敗查看應(yīng)用日志中提交順序?qū)⑼夂舾臑槭聞?wù)后異步發(fā)送6. 我最后想說的幾句實在話帶過這么多項目也幫同事處理過不少事務(wù)問題我最大的體會是事務(wù)本身不難難的是控制事務(wù)的邊界。很多人寫代碼時只想著“這里要加事務(wù)”卻很少想“這個事務(wù)應(yīng)該多短、該不該包住這段外呼、回滾發(fā)生時旁邊那些狀態(tài)怎么辦”。數(shù)據(jù)庫事務(wù)是個好工具但它不是萬能的更不是業(yè)務(wù)一致性的唯一保障。我還想多說一句事務(wù)的隔離級別、鎖機制這些內(nèi)容看起來像是 DBA 才需要研究的但作為開發(fā)只要你的代碼里有并發(fā)寫操作這些知識遲早會找上你。與其等線上出了資損、死鎖、丟數(shù)據(jù)再回頭補課不如趁早把事務(wù)的底層邏輯吃透。最后分享一個小習(xí)慣每寫一段涉及事務(wù)的代碼我都會問自己三個問題——這個事務(wù)最短能縮到多短如果它回滾了哪些數(shù)據(jù)會受影響如果它成功了但旁邊系統(tǒng)失敗數(shù)據(jù)還能不能對得上把這三個問題想清楚你就已經(jīng)超過大多數(shù)“只會寫 BEGIN”的同事了。