1. 從一個真實場景說起為什么并發(fā)會讓數(shù)據(jù)對不上但凡做過后端開發(fā)的人大概率都遇到過這樣的場景系統(tǒng)上線初期一切正常用戶量一上來財務對賬就開始出問題——賬戶余額莫名其妙多了一筆或者少了一筆庫存扣成了負數(shù)優(yōu)惠券被同一個人領了兩次。排查日志的時候發(fā)現(xiàn)每條SQL單獨執(zhí)行都沒毛病但組合在一起在高并發(fā)下就亂了套。這就是典型的并發(fā)場景下的數(shù)據(jù)一致性問題。MySQL作為最主流的關系型數(shù)據(jù)庫本身提供了完整的事務機制和鎖機制來應對這類問題但很多人只是知道有事務這回事真正到了業(yè)務里卻不知道怎么用、用哪種隔離級別、鎖該加在哪里。我見過不少項目代碼里寫滿了Transactional注解結果該出問題還是出問題因為事務的粒度和鎖的范圍根本沒搞對。這篇內(nèi)容我打算用一個賬戶轉(zhuǎn)賬庫存扣減的模擬實例把MySQL在并發(fā)場景下保證數(shù)據(jù)一致性的核心機制從頭到尾拆一遍。涉及的知識點包括事務的ACID特性、四種隔離級別的實際表現(xiàn)、行鎖與間隙鎖的行為差異、樂觀鎖與悲觀鎖的選型對比以及在實際業(yè)務中怎么組合使用這些手段。適合有一定SQL基礎、正在做交易類或庫存類業(yè)務的后端開發(fā)者參考也適合想系統(tǒng)梳理MySQL并發(fā)知識的朋友。我不會只講概念每個機制都會配上可復現(xiàn)的SQL示例和實測結果你可以直接在自己的測試庫上跑一遍驗證。文章里提到的參數(shù)配置和代碼寫法都是我在實際項目里驗證過的方案踩過的坑也會一并說清楚。2. 先把底層邏輯理清楚事務與隔離級別到底在解決什么2.1 ACID里真正難保證的是哪幾個事務的四個特性——原子性Atomicity、一致性Consistency、隔離性Isolation、持久性Durability——教科書上背得滾瓜爛熟但實際開發(fā)中最容易出問題的其實是隔離性。原子性靠undo log回滾就能保證持久性靠redo log刷盤也能保證一致性是最終目的而隔離性才是并發(fā)場景下所有麻煩的根源。為什么這么說因為多個事務同時操作同一批數(shù)據(jù)時如果沒有隔離機制就會出現(xiàn)四類問題臟讀讀到別的事務還沒提交的數(shù)據(jù)、不可重復讀同一個事務內(nèi)兩次讀同一行結果不一樣、幻讀同一個事務內(nèi)兩次范圍查詢結果集行數(shù)不一樣、丟失更新兩個事務同時改一行后提交的覆蓋了先提交的。這四類問題里丟失更新是業(yè)務層面最致命的因為它直接導致數(shù)據(jù)算錯而且往往悄無聲息。注意很多人把不可重復讀和幻讀搞混。簡單區(qū)分——不可重復讀針對的是同一行數(shù)據(jù)的值變了幻讀針對的是結果集的行數(shù)變了。前者用行鎖能解決后者需要間隙鎖或表鎖。2.2 四種隔離級別的實際表現(xiàn)差異MySQL的InnoDB引擎支持四種隔離級別默認是可重復讀REPEATABLE READ。這個默認值很關鍵因為很多其他數(shù)據(jù)庫默認是讀已提交READ COMMITTED行為差異很大。隔離級別臟讀不可重復讀幻讀實現(xiàn)機制讀未提交READ UNCOMMITTED可能可能可能幾乎不加鎖讀已提交READ COMMITTED不可能可能可能MVCC快照讀可重復讀REPEATABLE READ不可能不可能InnoDB基本避免MVCC間隙鎖串行化SERIALIZABLE不可能不可能不可能全部加鎖這里有個容易踩的坑在讀已提交級別下每次SELECT都會生成一個新的ReadView所以同一事務內(nèi)兩次查詢可能看到不同的數(shù)據(jù)。而在可重復讀級別下ReadView是在第一次SELECT時生成的后續(xù)查詢復用這個快照所以能看到一致的數(shù)據(jù)。這個差異在長事務里特別明顯如果你的事務執(zhí)行時間很長可重復讀級別下讀到的可能是過期數(shù)據(jù)。2.3 MVCC讀操作不加鎖的底氣從哪來InnoDB實現(xiàn)隔離級別的核心武器是MVCC多版本并發(fā)控制。它的思路很樸素每次修改數(shù)據(jù)時不直接覆蓋而是生成一個新版本舊版本保留在undo log里。讀操作根據(jù)事務的ReadView判斷應該讀哪個版本從而實現(xiàn)讀不加鎖、讀寫不沖突。每行數(shù)據(jù)實際上有兩個隱藏字段DB_TRX_ID最后修改該行的事務ID和DB_ROLL_PTR指向undo log中舊版本的指針。當你執(zhí)行SELECT時InnoDB會沿著版本鏈找到對當前事務可見的那個版本。判斷可見性的規(guī)則大致是如果行的DB_TRX_ID小于當前事務ID且不在活躍事務列表中說明這個版本是已提交的可見否則沿著DB_ROLL_PTR往前找。這套機制讓讀操作完全不用加鎖極大提升了并發(fā)讀的性能。但要注意MVCC只對快照讀普通SELECT生效如果你用的是SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE那就是當前讀會加鎖不走MVCC。3. 實例拆解賬戶轉(zhuǎn)賬場景下的并發(fā)問題復現(xiàn)3.1 建表和初始化數(shù)據(jù)先建一張最簡單的賬戶表模擬兩個用戶之間的轉(zhuǎn)賬CREATE TABLE account ( id BIGINT NOT NULL AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT 用戶ID, balance DECIMAL(15,2) NOT NULL DEFAULT 0.00 COMMENT 余額, version INT NOT NULL DEFAULT 0 COMMENT 版本號, PRIMARY KEY (id), UNIQUE KEY uk_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT賬戶表; INSERT INTO account (user_id, balance, version) VALUES (1001, 1000.00, 0); INSERT INTO account (user_id, balance, version) VALUES (1002, 500.00, 0);初始狀態(tài)用戶1001有1000元用戶1002有500元?，F(xiàn)在要做一個轉(zhuǎn)賬操作從1001轉(zhuǎn)200元給1002正確結果應該是1001剩800元1002有700元。3.2 不加任何控制的并發(fā)轉(zhuǎn)賬會怎樣假設有兩個線程同時執(zhí)行轉(zhuǎn)賬代碼邏輯是先查余額再判斷夠不夠再更新。用偽代碼表示-- 線程A和線程B同時執(zhí)行 SELECT balance FROM account WHERE user_id 1001; -- 都讀到1000 -- 判斷1000 200都通過 UPDATE account SET balance balance - 200 WHERE user_id 1001; UPDATE account SET balance balance 200 WHERE user_id 1002;如果兩個線程幾乎同時執(zhí)行可能出現(xiàn)兩種情況。第一種是丟失更新兩個線程都讀到1000都執(zhí)行減200最終1001的余額變成800而不是600相當于只扣了一次。第二種更隱蔽如果UPDATE語句寫的是SET balance 800在應用層算好再寫回那后執(zhí)行的會覆蓋先執(zhí)行的同樣只扣一次。實操心得很多團隊出問題就出在應用層計算再寫回這種寫法上。只要你的UPDATE語句里出現(xiàn)了具體的數(shù)值而不是balance - 200這樣的表達式就一定要警惕并發(fā)覆蓋問題。3.3 用事務包起來就萬事大吉了嗎有人會說加個事務不就行了把兩條UPDATE放在一個事務里要么都成功要么都失敗。事務確實能保證原子性但它保證不了隔離性帶來的并發(fā)覆蓋問題。因為默認的可重復讀級別下兩個事務各自讀到的快照可能是一樣的UPDATE時雖然會加行鎖但如果事務提交順序不當仍然可能出現(xiàn)邏輯錯誤。更關鍵的是事務的隔離級別和鎖的范圍決定了并發(fā)行為。如果只是簡單地把操作包在START TRANSACTION ... COMMIT里而不考慮鎖的粒度和獲取順序在高并發(fā)下依然會出問題甚至可能引發(fā)死鎖。所以事務只是基礎真正要解決問題還得靠鎖策略和版本控制。4. 三種主流方案實測對比悲觀鎖、樂觀鎖、原子操作4.1 悲觀鎖方案SELECT FOR UPDATE悲觀鎖的思路是先鎖住再操作在查詢余額的時候就加上排他鎖START TRANSACTION; SELECT balance FROM account WHERE user_id 1001 FOR UPDATE; -- 此時其他事務對user_id1001的FOR UPDATE查詢會阻塞 UPDATE account SET balance balance - 200 WHERE user_id 1001; UPDATE account SET balance balance 200 WHERE user_id 1002; COMMIT;FOR UPDATE會對滿足條件的行加排他鎖X鎖其他事務想對這行加鎖就得等。這樣就保證了同一時刻只有一個事務能操作這行數(shù)據(jù)徹底避免了并發(fā)覆蓋。實測下來這種方案在并發(fā)量不高、事務執(zhí)行時間短的場景下非常穩(wěn)。但有兩個明顯的代價一是鎖等待會降低吞吐量二是如果事務里還有其他耗時操作比如調(diào)用外部接口鎖持有時間會很長容易拖垮整個系統(tǒng)。注意FOR UPDATE在沒有索引的列上使用會鎖全表這是新手最容易踩的坑。一定要確保WHERE條件走了索引否則并發(fā)一上來就是災難。4.2 樂觀鎖方案版本號控制樂觀鎖的思路是先操作提交時檢查有沒有被別人改過。在表里加一個version字段每次更新時帶上版本號-- 第一步查詢當前余額和版本號 SELECT balance, version FROM account WHERE user_id 1001; -- 假設讀到 balance1000, version0 -- 第二步更新時校驗版本號 UPDATE account SET balance balance - 200, version version 1 WHERE user_id 1001 AND version 0; -- 第三步檢查影響行數(shù)如果為0說明被改過重試或報錯如果兩個線程同時讀到version0只有一個能更新成功因為更新后version變成1另一個的UPDATE影響行數(shù)為0應用層捕獲后可以重試。樂觀鎖的優(yōu)勢是不加鎖、吞吐量高特別適合讀多寫少的場景。缺點是沖突多的時候重試成本高如果并發(fā)寫非常頻繁大量請求都在重試反而比悲觀鎖更慢。另外重試邏輯需要應用層自己實現(xiàn)增加了代碼復雜度。4.3 原子操作方案直接利用SQL的原子性還有一種更輕量的方案把判斷和更新合并到一條SQL里利用數(shù)據(jù)庫自身的原子性UPDATE account SET balance balance - 200 WHERE user_id 1001 AND balance 200;這條語句在InnoDB里是原子的balance 200的判斷和balance - 200的更新在同一個語句內(nèi)完成不會被打斷。如果影響行數(shù)為0說明余額不足轉(zhuǎn)賬失敗。這種方案性能最好、代碼最簡單但適用場景有限——它只能處理扣減這類單向操作如果業(yè)務邏輯復雜比如需要先查再算再更新就不好用一條SQL搞定。而且它無法處理需要讀取中間值的場景。4.4 三種方案的選型對照表方案加鎖方式適用場景吞吐量實現(xiàn)復雜度主要風險悲觀鎖行級排他鎖寫多讀少、事務短中低鎖等待、死鎖樂觀鎖無鎖版本校驗讀多寫少、沖突少高中重試風暴原子操作語句級原子簡單扣減/累加最高最低場景受限實際項目里我通常會組合使用核心扣減用原子操作復雜業(yè)務邏輯用悲觀鎖查詢密集的配置類數(shù)據(jù)用樂觀鎖。沒有銀彈關鍵看業(yè)務特征。5. 深入鎖機制行鎖、間隙鎖與死鎖排查5.1 行鎖到底鎖的是什么InnoDB的行鎖是加在索引上的不是加在數(shù)據(jù)行上的。這一點極其重要因為它決定了鎖的范圍。如果你的WHERE條件命中了唯一索引那鎖的就是那一行如果命中的是普通索引可能會鎖多行如果沒走索引那就退化成表鎖。舉個例子account表的user_id上有唯一索引執(zhí)行SELECT * FROM account WHERE user_id 1001 FOR UPDATE鎖的就是user_id1001這一行對應的索引記錄。但如果user_id上沒有索引這條語句會鎖住整張表的所有行并發(fā)直接歸零。5.2 間隙鎖幻讀的克星也是死鎖的溫床在可重復讀級別下InnoDB為了防止幻讀引入了間隙鎖Gap Lock。它不僅鎖住存在的記錄還鎖住記錄之間的間隙。比如表里有user_id為1001和1005兩行執(zhí)行范圍查詢WHERE user_id BETWEEN 1001 AND 1005 FOR UPDATE會鎖住1001到1005之間的所有間隙其他事務無法在這個范圍內(nèi)插入新記錄。間隙鎖解決了幻讀問題但也帶來了新的麻煩——它顯著增加了死鎖的概率。因為間隙鎖之間不沖突但間隙鎖和插入意向鎖會沖突兩個事務如果以不同順序獲取間隙鎖就很容易互相等待。實操心得如果你的業(yè)務不需要嚴格防止幻讀可以考慮把隔離級別降到讀已提交這樣就沒有間隙鎖了死鎖概率大幅降低。很多互聯(lián)網(wǎng)公司就是這么做的用業(yè)務邏輯來兜底幻讀問題。5.3 死鎖的定位與處理死鎖發(fā)生時MySQL會自動檢測并回滾其中一個事務報錯信息是Deadlock found when trying to get lock。排查死鎖最直接的方式是查看SHOW ENGINE INNODB STATUS的輸出里面會顯示最近一次死鎖的詳細信息包括兩個事務分別持有什么鎖、等待什么鎖。處理死鎖的核心原則是統(tǒng)一加鎖順序。如果所有事務都按相同的順序訪問資源比如先鎖賬戶A再鎖賬戶B就不會出現(xiàn)循環(huán)等待。另外盡量縮短事務長度、減少鎖的持有時間也能有效降低死鎖概率。-- 查看當前鎖等待情況 SELECT * FROM performance_schema.data_lock_waits; -- 查看當前事務 SELECT * FROM information_schema.innodb_trx;6. 實戰(zhàn)中的參數(shù)配置與避坑清單6.1 幾個關鍵參數(shù)的調(diào)整建議MySQL有幾個和并發(fā)、事務相關的參數(shù)默認值不一定適合高并發(fā)場景參數(shù)默認值建議值說明innodb_lock_wait_timeout50秒5-10秒鎖等待超時太長會拖垮連接池transaction_isolationREPEATABLE-READ按業(yè)務定讀已提交可減少間隙鎖innodb_autoinc_lock_mode12高并發(fā)插入時用交錯模式max_connections151按需調(diào)連接數(shù)不夠會導致請求排隊innodb_lock_wait_timeout這個參數(shù)特別值得說。默認50秒太長了一旦出現(xiàn)鎖等待請求會一直掛著連接池很快被占滿整個服務雪崩。我一般會調(diào)到5到10秒超時后快速失敗讓應用層決定是重試還是報錯。6.2 事務粒度控制的三個原則第一事務里不要做RPC調(diào)用。調(diào)用外部接口的耗時不可控可能幾百毫秒甚至幾秒鎖一直不釋放并發(fā)直接崩。正確做法是先做本地事務提交后再發(fā)消息或調(diào)接口。第二事務里不要做大批量操作。比如一次更新幾萬行鎖持有時間會很長?？梢圆鸪尚∨蚊颗鷰装傩蟹峙峤弧５谌聞绽锊灰杏脩艚换?。有些老系統(tǒng)會在事務里等用戶輸入這是大忌鎖會一直不釋放。6.3 常見問題速查表問題現(xiàn)象可能原因排查方向解決方案余額扣成負數(shù)丟失更新檢查UPDATE是否用了表達式改用原子操作或加鎖大量鎖等待超時事務太長或鎖范圍大看innodb_trx和鎖等待表縮短事務、檢查索引偶發(fā)死鎖加鎖順序不一致看死鎖日志統(tǒng)一加鎖順序幻讀導致數(shù)據(jù)錯亂隔離級別不夠確認隔離級別升級到可重復讀或用間隙鎖樂觀鎖重試過多并發(fā)沖突高統(tǒng)計重試率改用悲觀鎖或原子操作6.4 我踩過的幾個坑第一個坑是在可重復讀級別下用SELECT做判斷。有次寫了個先查庫存夠不夠再扣減的邏輯測試環(huán)境沒問題上線后大促直接超賣。原因是兩個事務都讀到了相同的快照都判斷庫存夠然后都扣減。后來改成UPDATE ... WHERE stock num的原子寫法才解決。第二個坑是FOR UPDATE沒走索引。有張表在WHERE條件里用了函數(shù)導致索引失效FOR UPDATE直接鎖全表并發(fā)一上來全部阻塞。后來把函數(shù)去掉改成范圍查詢才恢復。第三個坑是長事務導致的連接池耗盡。有個接口在事務里調(diào)了一個第三方服務那個服務偶爾會超時幾十秒結果鎖一直不釋放連接池被占滿整個服務不可用。后來把第三方調(diào)用移到事務外面問題消失。這些坑說到底都是對鎖的范圍和事務的邊界理解不到位。MySQL的并發(fā)控制機制本身很完善問題往往出在使用方式上。把事務寫短、把鎖的范圍控制到最小、優(yōu)先用原子操作這三條原則能避開絕大多數(shù)并發(fā)問題。