本文介紹了一個 MySQL 數(shù)據(jù)庫死鎖的案例和解決方案。
場景
生產(chǎn)環(huán)境出了一個偶現(xiàn)的數(shù)據(jù)庫死鎖問題,導致少部分業(yè)務處理失敗。
分析特征之后,發(fā)現(xiàn)是多個線程并發(fā)執(zhí)行同一個方法,更新關聯(lián)的數(shù)據(jù)時可能會出現(xiàn),把場景簡化概括一下:
-
有一個數(shù)據(jù)表 tb1,主鍵名 id,有兩條 id 分別為 A1 和 A2 的記錄,對應的外鍵 fk_biz_no 相同;
-
方法 myFunc,整體是一個事務;
-
方法 myFunc 里的邏輯是先更新 tb1 里的一條記錄,執(zhí)行一些邏輯后,再更新該記錄的外鍵對應的所有記錄;
這樣 線程1 和 線程2 并發(fā)執(zhí)行 myFunc 方法時,示意如下:
線程1 先更新 A1,此時會對 A1 所在行加寫鎖,再更新 A1 和 A2,此時會同時給 A1 和 A2 所在行都加上寫鎖;
線程2 先更新 A2,此時會對 A2 所在行加寫鎖,再更新 A1 和 A2,此時會同時給 A1 和 A2 所在行都加上寫鎖。
如此一來,如果出現(xiàn)類似以下的執(zhí)行時序,則會形成死鎖:
帶著一點偽裝的 ABBA 死鎖。
解決方案
按照消除死鎖條件的思路,一般會想到將兩個線程里的加鎖順序改為一致,但是此場景并不完全適用。以下是幾種可行的方案:
方案一、對 myFunc 方法加分布式鎖,可以用需要更新的記錄的 fk_biz_no 作為鎖的 key,這樣同一個 fk_biz_no 的更新操作就會串行執(zhí)行;
方案二、在方法/事務的最開始,就提前把 A1A2 的寫鎖申請到(比如 SELECT ... FOR UPDATE
),然后再執(zhí)行后續(xù)邏輯;
方案三、優(yōu)化 myFunc 方法里的邏輯,先將 A1 和 A2 的數(shù)據(jù)都處理好了,然后一次性更新 A1A2,即將方法里的兩次更新合并成一次更新;
方案一 和 方案二 效果類似,都是使同一 fk_biz_no 的更新操作串行了;而方法三則是消除了 ABBA 的情況(實際場景中有可能需要考慮并發(fā)執(zhí)行下的數(shù)據(jù)混亂、數(shù)據(jù)覆蓋的問題,那是另外的話題了,在此不展開)。
小結
來一起復習下死鎖的四個必要條件:
-
互斥條件:一個資源每次只能被一個進程使用;
-
請求與保持條件:一個進程因請求資源而阻塞時,對已獲得的資源保持不放;
-
不剝奪條件:進程已獲得的資源,在末使用完之前,不能強行剝奪;
-
循環(huán)等待條件:若干進程之間形成一種頭尾相接的循環(huán)等待資源關系。
預防和消除死鎖的思路,則無非是消除上述四個條件中的一個或多個。