誰還沒經(jīng)歷過死鎖呢
本文轉(zhuǎn)載自微信公眾號「小林coding」，作者小林coding。轉(zhuǎn)載本文請聯(lián)系小林coding公眾號。
大家好，我是小林。
說個很早之前自己遇到過數(shù)據(jù)庫死鎖問題。
有個業(yè)務(wù)主要邏輯就是新增訂單、修改訂單、查詢訂單等操作。然后因為訂單是不能重復(fù)的，所以當(dāng)時在新增訂單的時候做了冪等性校驗，做法就是在新增訂單記錄之前，先通過 select ... for update 語句查詢訂單是否存在，如果不存在才插入訂單記錄。
而正是因為這樣的操作，當(dāng)業(yè)務(wù)量很大的時候，就可能會出現(xiàn)死鎖。
接下來跟大家聊下為什么會發(fā)生死鎖，以及怎么避免死鎖。
死鎖的發(fā)生
本次案例使用存儲引擎 Innodb，隔離級別不可重復(fù)讀(RR)。
接下來，我用實戰(zhàn)的方式來帶大家看看死鎖是怎么發(fā)生的。
我建了一張訂單表，其中 id 字段為主鍵索引，order_no 字段普通索引，也就是非唯一索引：
- CREATE TABLE `t_order` (
- `id` int NOT NULL AUTO_INCREMENT,
- `order_no` int DEFAULT NULL,
- `create_date` datetime DEFAULT NULL,
- PRIMARY KEY (`id`),
- KEY `index_order` (`order_no`) USING BTREE
- ) ENGINE=InnoDB ;
然后，先 t_order 表里現(xiàn)在已經(jīng)有了 6 條記錄：
假設(shè)這時有兩事務(wù)，一個事務(wù)要插入訂單 1007 ，另外一個事務(wù)要插入訂單 1008，因為需要對訂單做冪等性校驗，所以兩個事務(wù)先要查詢該訂單是否存在，不存在才插入記錄，過程如下：
可以看到，兩個事務(wù)都陷入了等待狀態(tài)(前提沒有打開死鎖檢測)，也就是發(fā)生了死鎖，因為都在相互等待對方釋放鎖。
這里在查詢記錄是否存在的時候，使用了 select ... for update 語句，目的為了防止事務(wù)執(zhí)行的過程中，有其他事務(wù)插入了記錄，而出現(xiàn)幻讀的問題。
如果沒有使用 select ... for update 語句，而使用了單純的 select 語句，如果是兩個訂單號一樣的請求同時進(jìn)來，就會出現(xiàn)兩個重復(fù)的訂單，有可能出現(xiàn)幻讀，如下圖：
為什么會產(chǎn)生死鎖?
可重復(fù)讀隔離級別下，是存在幻讀的問題。
Innodb 引擎為了解決「可重復(fù)讀」隔離級別下的幻讀問題，就引出了 next-key 鎖，它是記錄鎖和間隙鎖的組合。
- Record Loc，記錄鎖，鎖的是記錄本身;
- Gap Lock，間隙鎖，鎖的就是兩個值之間的空隙，以防止其他事務(wù)在這個空隙間插入新的數(shù)據(jù)，從而避免幻讀現(xiàn)象。
普通的 select 語句是不會對記錄加鎖的，因為它是通過 MVCC 的機(jī)制實現(xiàn)的快照讀，如果要在查詢時對記錄加行鎖，可以使用下面這兩個方式：
- begin;
- //對讀取的記錄加共享鎖
- select ... lock in share mode;
- commit; //鎖釋放
- begin;
- //對讀取的記錄加排他鎖
- select ... for update;
- commit; //鎖釋放
行鎖的釋放時機(jī)是在事務(wù)提交(commit)后，鎖就會被釋放，并不是一條語句執(zhí)行完就釋放行鎖。
比如，下面事務(wù) A 查詢語句會鎖住(2, +∞]范圍的記錄，然后期間如果有其他事務(wù)在這個鎖住的范圍插入數(shù)據(jù)就會被阻塞。
next-key 鎖的加鎖規(guī)則其實挺復(fù)雜的，在一些場景下會退化成記錄鎖或間隙鎖，我之前也寫一篇加鎖規(guī)則，詳細(xì)可以看這篇「我做了一天的實驗!」
需要注意的是，next-key lock 鎖的是索引，而不是數(shù)據(jù)本身，所以如果 update 語句的 where 條件沒有用到索引列，那么就會全表掃描，在一行行掃描的過程中，不僅給行加上了行鎖，還給行兩邊的空隙也加上了間隙鎖，相當(dāng)于鎖住整個表，然后直到事務(wù)結(jié)束才會釋放鎖。
所以在線上千萬不要執(zhí)行沒有帶索引條件的 update 語句，不然會造成業(yè)務(wù)停滯，我有個讀者就因為干了這個事情，然后被老板教育了一波，詳細(xì)可以看這篇「完蛋，公司被一條 update 語句干趴了!」
回到前面死鎖的例子，在執(zhí)行下面這條語句的時候：
- select id from t_order where order_no = 1008 for update;
因為 order_no 不是唯一索引，所以行鎖的類型是間隙鎖，于是間隙鎖的范圍是(1006, +∞)。那么，當(dāng)事務(wù) B 往間隙鎖里插入 id = 1008 的記錄就會被鎖住。
因為當(dāng)我們執(zhí)行以下插入語句時，會在插入間隙上再次獲取插入意向鎖。
- insert into t_order (order_no, create_date) values (1008, now());
插入意向鎖與間隙鎖是沖突的，所以當(dāng)其它事務(wù)持有該間隙的間隙鎖時，需要等待其它事務(wù)釋放間隙鎖之后，才能獲取到插入意向鎖。而間隙鎖與間隙鎖之間是兼容的，所以所以兩個事務(wù)中 select ... for update 語句并不會相互影響。
案例中的事務(wù) A 和事務(wù) B 在執(zhí)行完后 select ... for update 語句后都持有范圍為(1006,+∞)的間隙鎖，而接下來的插入操作為了獲取到插入意向鎖，都在等待對方事務(wù)的間隙鎖釋放，于是就造成了循環(huán)等待，導(dǎo)致死鎖。
如何避免死鎖?
死鎖的四個必要條件：互斥、占有且等待、不可強(qiáng)占用、循環(huán)等待。只要系統(tǒng)發(fā)生死鎖，這些條件必然成立，但是只要破壞任意一個條件就死鎖就不會成立。
在數(shù)據(jù)庫層面，有兩種策略通過「打破循環(huán)等待條件」來解除死鎖狀態(tài)：
- 設(shè)置事務(wù)等待鎖的超時時間。當(dāng)一個事務(wù)的等待時間超過該值后，就對這個事務(wù)進(jìn)行回滾，于是鎖就釋放了，另一個事務(wù)就可以繼續(xù)執(zhí)行了。在 InnoDB 中，參數(shù) innodb_lock_wait_timeout 是用來設(shè)置超時時間的，默認(rèn)值時 50 秒。
當(dāng)發(fā)生超時后，就出現(xiàn)下面這個提示：
- 開啟主動死鎖檢測。主動死鎖檢測在發(fā)現(xiàn)死鎖后，主動回滾死鎖鏈條中的某一個事務(wù)，讓其他事務(wù)得以繼續(xù)執(zhí)行。將參數(shù) innodb_deadlock_detect 設(shè)置為 on，表示開啟這個邏輯，默認(rèn)就開啟。
當(dāng)檢測到死鎖后，就會出現(xiàn)下面這個提示：
上面這個兩種策略是「當(dāng)有死鎖發(fā)生時」的避免方式。
我們可以回歸業(yè)務(wù)的角度來預(yù)防死鎖，對訂單做冪等性校驗的目的是為了保證不會出現(xiàn)重復(fù)的訂單，那我們可以直接將 order_no 字段設(shè)置為唯一索引列，利用它的唯一下來保證訂單表不會出現(xiàn)重復(fù)的訂單，不過有一點不好的地方就是在我們插入一個已經(jīng)存在的訂單記錄時就會拋出異常。
