一次神奇的MySQL死鎖排查記錄

背景

說(shuō)起Mysql死鎖，之前寫(xiě)過(guò)一次有關(guān)Mysql加鎖的基本介紹，對(duì)于一些基本的Mysql鎖或者死鎖都有一個(gè)簡(jiǎn)單的認(rèn)識(shí)，可以看下這篇文章為什么開(kāi)發(fā)人員需要了解數(shù)據(jù)庫(kù)鎖。有了上面的經(jīng)驗(yàn)之后，本以為對(duì)于死鎖都能手到擒來(lái)，沒(méi)想到再一個(gè)陽(yáng)光明媚的下午報(bào)出了一個(gè)死鎖，但是這一次卻沒(méi)想象的那么簡(jiǎn)單。

問(wèn)題初現(xiàn)

在某天下午，突然系統(tǒng)報(bào)警，拋出個(gè)異常：

仔細(xì)一看好像是事務(wù)回滾異常，寫(xiě)著的是因?yàn)樗梨i回滾，原來(lái)是個(gè)死鎖問(wèn)題，由于我對(duì)Mysql鎖還是有一定了解的，于是開(kāi)始主動(dòng)排查這個(gè)問(wèn)題。

首先在數(shù)據(jù)庫(kù)中查找Innodb Status，在Innodb Status中會(huì)記錄上一次死鎖的信息,輸入下面命令：

SHOW ENGINE INNODB STATUS 

死鎖信息如下,sql信息進(jìn)行了簡(jiǎn)單處理：

------------------------ 
LATEST DETECTED DEADLOCK 
------------------------ 
2019-02-22 15:10:56 0x7eec2f468700 
*** (1) TRANSACTION: 
TRANSACTION 2660206487, ACTIVE 0 sec starting index read 
mysql tables in use 1, locked 1 
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s) 
MySQL thread id 31261312, OS thread handle 139554322093824, query id 11624975750 10.23.134.92 erp_crm__6f73 updating 
/*id:3637ba36*/UPDATE tenant_config SET 
 open_card_point = 0 
 where tenant_id = 123 
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 1322 page no 534 n bits 960 index uidx_tenant of table `erp_crm_member_plan`.`tenant_config` trx id 2660206487 lock_mode X locks rec but not gap waiting 
 *** (2) TRANSACTION: 
TRANSACTION 2660206486, ACTIVE 0 sec starting index read 
mysql tables in use 1, locked 1 
3 lock struct(s), heap size 1136, 2 row lock(s) 
MySQL thread id 31261311, OS thread handle 139552870532864, query id 11624975758 10.23.134.92 erp_crm__6f73 updating 
/*id:3637ba36*/UPDATE tenant_config SET 
 open_card_point = 0 
 where tenant_id = 123 
*** (2) HOLDS THE LOCK(S): 
RECORD LOCKS space id 1322 page no 534 n bits 960 index uidx_tenant of table `erp_crm_member_plan`.`tenant_config` trx id 2660206486 lock mode S 
*** (2) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 1322 page no 534 n bits 960 index uidx_tenant of table `erp_crm_member_plan`.`tenant_config` trx id 2660206486 lock_mode X locks rec but not gap waiting 
 *** WE ROLL BACK TRANSACTION (1) 
------------ 

給大家簡(jiǎn)單的分析解釋一下這段死鎖日志，事務(wù)1執(zhí)行Update語(yǔ)句的時(shí)候需要獲取uidx_tenant這個(gè)索引再where條件上的X鎖(行鎖)，事務(wù)2執(zhí)行同樣的Update語(yǔ)句，也在uidx_tenant上面想要獲取X鎖(行鎖)，然后就出現(xiàn)了死鎖，回滾了事務(wù)1。當(dāng)時(shí)我就很懵逼，回想了一下死鎖產(chǎn)生的必要條件:

1、互斥。

2、請(qǐng)求與保持條件。

3、不剝奪條件。

4、循環(huán)等待。

從日志上來(lái)看事務(wù)1和事務(wù)2都是取爭(zhēng)奪同一行的行鎖，和以往的互相循環(huán)爭(zhēng)奪鎖有點(diǎn)不同，怎么看都無(wú)法滿足循環(huán)等待條件。經(jīng)過(guò)同事提醒，既然從死鎖日志中不能進(jìn)行排查，那么就只能從業(yè)務(wù)代碼和業(yè)務(wù)日志從排查。這段代碼的邏輯如下：

public int saveTenantConfig(PoiContext poiContext, TenantConfigDO tenantConfig) { 
 try { 
  return tenantConfigMapper.saveTenantConfig(poiContext.getTenantId(), poiContext.getPoiId(), tenantConfig); 
 } catch (DuplicateKeyException e) { 
  LOGGER.warn("[saveTenantConfig] 主鍵沖突，更新該記錄。context:{}, config:{}", poiContext, tenantConfig); 
  return tenantConfigMapper.updateTenantConfig(poiContext.getTenantId(), tenantConfig); 
 } 
 } 

這段代碼的意思是保存一個(gè)配置文件，如果發(fā)生了唯一索引沖突那么就會(huì)進(jìn)行更新，當(dāng)然這里可能寫(xiě)得不是很規(guī)范，其實(shí)可以用

insert into ... 
on duplicate key update 

也可以達(dá)到同樣的效果，但是就算用這個(gè)其實(shí)也會(huì)發(fā)生死鎖。看了代碼之后同事又給我發(fā)了當(dāng)時(shí)業(yè)務(wù)日志,

可以看見(jiàn)這里有三條同時(shí)發(fā)生的日志，說(shuō)明都發(fā)生了唯一索引沖突進(jìn)入了更新的語(yǔ)句，然后發(fā)生的死鎖。到這里答案終于稍微有點(diǎn)眉目了。

這個(gè)時(shí)候再看我們的表結(jié)構(gòu)如下(做了簡(jiǎn)化處理)：

CREATE TABLE `tenant_config` ( 
 `id` bigint(21) NOT NULL AUTO_INCREMENT, 
 `tenant_id` int(11) NOT NULL, 
 `open_card_point` int(11) DEFAULT NULL, 
 PRIMARY KEY (`id`), 
 UNIQUE KEY `uidx_tenant` (`tenant_id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=COMPACT 

我們的tenant_id是用來(lái)做唯一索引，我們的插入和更新的where條件都是基于唯一索引來(lái)操作的。

UPDATE tenant_config SET 
 open_card_point = 0 
 where tenant_id = 123 

到了這里感覺(jué)插入的時(shí)候?qū)ξㄒ凰饕渔i有關(guān)系，接下來(lái)我們進(jìn)行下一步的深入剖析。

深入剖析

上面我們說(shuō)有三個(gè)事務(wù)進(jìn)入update語(yǔ)句，為了簡(jiǎn)化說(shuō)明這里我們只需要兩個(gè)事務(wù)同時(shí)進(jìn)入update語(yǔ)句即可，下面的表格展示了我們整個(gè)的發(fā)生過(guò)程：

小提示:S鎖是共享鎖，X鎖是互斥鎖。一般來(lái)說(shuō)X鎖和S，X鎖都互斥，S鎖和S鎖不互斥。

我們從上面的流程中看見(jiàn)發(fā)生這個(gè)死鎖的關(guān)鍵需要獲取S鎖，為什么我們?cè)俨迦氲臅r(shí)候需要獲取S鎖呢？因?yàn)槲覀冃枰獧z測(cè)唯一索引？在RR隔離級(jí)別下如果要讀取那么就是當(dāng)前讀,那么其實(shí)就需要加上S鎖。這里發(fā)現(xiàn)唯一鍵已經(jīng)存在，這個(gè)時(shí)候執(zhí)行update就會(huì)被兩個(gè)事務(wù)的S鎖互相阻塞，從而形成上面的循環(huán)等待條件。

小提示: 在MVCC中，當(dāng)前讀和快照讀的區(qū)別:當(dāng)前讀每次需要加鎖（可以使共享鎖或者互斥鎖）獲取到最新的數(shù)據(jù)，而快照讀是讀取的是這個(gè)事務(wù)開(kāi)始的時(shí)候那個(gè)快照，這個(gè)是通過(guò)undo log去進(jìn)行實(shí)現(xiàn)的。

這個(gè)就是整個(gè)死鎖的原因，能出現(xiàn)這種死鎖的還有一個(gè)情況，就是同一時(shí)間來(lái)三個(gè)插入操作，其中先插入的那個(gè)事務(wù)如果最后回滾了，其余兩個(gè)事務(wù)也會(huì)出現(xiàn)這種死鎖。

解決方案

這里的核心問(wèn)題是需要把S鎖給干掉，這里有三個(gè)可供參考的解決方案:

•  將RR隔離級(jí)別，降低成RC隔離級(jí)別。這里RC隔離級(jí)別會(huì)用快照讀，從而不會(huì)加S鎖。
•  再插入的時(shí)候使用select * for update,加X(jué)鎖，從而不會(huì)加S鎖。
•  可以提前加上分布式鎖，可以利用Redis,或者ZK等等，分布式鎖可以參考我的這篇文章。聊聊分布式鎖

第一種方法不太現(xiàn)實(shí)，畢竟隔離級(jí)別不能輕易的修改。第三種方法又比較麻煩。所以第二種方法是我們最后確定的。

總結(jié)

說(shuō)了這么多，最后做一個(gè)小小的總結(jié)吧。排查死鎖這種問(wèn)題的時(shí)候有時(shí)候光看死鎖日志有時(shí)候會(huì)解決不了問(wèn)題，需要結(jié)合整個(gè)的業(yè)務(wù)日志，代碼以及表結(jié)構(gòu)來(lái)進(jìn)行分析，才能得到正確的結(jié)果。當(dāng)然上面有一些數(shù)據(jù)庫(kù)鎖的基本知識(shí)如果不了解可以查看我的另一篇文章為什么開(kāi)發(fā)人員需要了解數(shù)據(jù)庫(kù)鎖。

最后這篇文章被我收錄于JGrowing-CaseStudy篇，一個(gè)全面，優(yōu)秀，由社區(qū)一起共建的Java學(xué)習(xí)路線，如果您想?yún)⑴c開(kāi)源項(xiàng)目的維護(hù)，可以一起共建，github地址為：https://github.com/javagrowing/JGrowing

好了，以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。