国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

記一次死鎖解析

IT那活兒 / 948人閱讀
記一次死鎖解析



概述



每個(gè)MySQL DBA和開發(fā)可能都會(huì)在工作過程中遇到死鎖問題,死鎖是并發(fā)系統(tǒng)中比較常見的問題,同樣也會(huì)出現(xiàn)在數(shù)據(jù)庫系統(tǒng)的并發(fā)讀寫請(qǐng)求場(chǎng)景中。當(dāng)兩個(gè)及以上的事務(wù),雙方都在等待對(duì)方釋放已經(jīng)持有的鎖或因?yàn)榧渔i順序不一致造成循環(huán)等待鎖資源,就會(huì)出現(xiàn)"死鎖"。

由于加鎖順序不一致造成的死鎖在RC(READ-COMMIT)隔離級(jí)別下較為常見,本文分享一個(gè)RR(REPEATABLE-READ)隔離級(jí)別下由于GAP鎖導(dǎo)致的死鎖案例。



案例



得知有死鎖發(fā)生時(shí),首先查看數(shù)據(jù)庫隔離級(jí)別為默認(rèn)的RR(REPEATABLE-READ)模式:

然后再查看innodb存儲(chǔ)引擎日志可以看到最近一次死鎖的相關(guān)信息:

從日志中我們可以看出死鎖發(fā)生在表T_ORDERBILL_TASK上而且是兩條相同類型的針對(duì)表T_ORDERBILL_TASK插入的insert語句!檢查T_ORDERBILL_TASK表結(jié)構(gòu)如下:

可見ORG_CODE上有二級(jí)索引。

1. TRANSACTION也就是第一個(gè)事務(wù)的信息中:

  • WAITING FOR THIS LOCK TO BE GRANTED,表示的是這個(gè)事務(wù)在等待的鎖信息;

  • index ORG_CODE of table `T_BSE_QUERY_SCHEME`.`T_ORDERBILL_TASK`表示等的是表T_ORDERBILL_TASK上ORG_CODE索引上面的鎖;

  • lock_mode X locks gap before rec insert intention waiting Record lock 表示這個(gè)語句要加一個(gè)插入意向鎖但是還在等待狀態(tài),Record lock說明這是一個(gè)記錄鎖。

2. TRANSACTION 也就是第二個(gè)事務(wù)中:

  • (2) HOLDS THE LOCK(S)中l(wèi)ock_mode X locks gap before rec 表示了持有GAP鎖

  • (2) WAITING FOR THIS LOCK TO BE GRANTED中l(wèi)ock_mode X locks gap before rec insert intention waiting同(1)TRANSACTION等待加插入意向鎖

結(jié)合業(yè)務(wù)開發(fā)提供的該模塊兒的業(yè)務(wù)邏輯和發(fā)生死鎖時(shí)間上下文業(yè)務(wù)日志可以整理出事務(wù)1和事務(wù)2的執(zhí)行順序?yàn)椋?/span>

或者

可以看出在插入一條數(shù)據(jù)前先執(zhí)行當(dāng)前讀鎖住該條數(shù)據(jù),弱不存在則插入該條數(shù)據(jù),否則執(zhí)行update。

由于索引是順序存儲(chǔ)的,查出110026介于110019和110036之間:

由此可知:

當(dāng)session 1執(zhí)行select ... for update當(dāng)前讀,由于ORG_CODE = 110026的數(shù)據(jù)不存在,因此會(huì)加上gap鎖(110019,110036)。

Session 2執(zhí)行select ... for update當(dāng)前讀,同樣也會(huì)加上gap鎖(110019,110036),由于gap鎖不互斥,所以該語句也可成功執(zhí)行。

但是到第三步時(shí)無論是session 1先插入還是session 2先插入都會(huì)等待對(duì)方的gap鎖,第四步時(shí)后插入的也會(huì)被對(duì)方的gap鎖阻塞。兩個(gè)session進(jìn)入互相等待狀態(tài)形成死鎖,最后死鎖檢測(cè)將session2回滾。



結(jié)論



其實(shí)GAP鎖,就是RR隔離級(jí)別相對(duì)于RC隔離級(jí)別不會(huì)出現(xiàn)幻讀的關(guān)鍵。

在RR隔離級(jí)別下,條件列上為非唯一索引時(shí),當(dāng)前讀通過條件列未定位到滿足條件的記錄時(shí)會(huì)加GAP鎖,保證后續(xù)的insert不能插入相同值的數(shù)據(jù),以防止出現(xiàn)幻讀。需要注意的是GAP鎖并不互斥但是和插入意向鎖互斥。相同語句的情況下RR模式由于會(huì)加GAP鎖可能鎖住更多的數(shù)據(jù),雖然防止了幻讀,但是會(huì)影響一定的并發(fā)。在配置RC和RR隔離級(jí)別的時(shí)候一定要根據(jù)業(yè)務(wù)場(chǎng)景進(jìn)行選擇。


END


更多精彩干貨分享

點(diǎn)擊下方名片關(guān)注

IT那活兒

文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址:http://m.specialneedsforspecialkids.com/yun/129763.html

相關(guān)文章

  • 一次升級(jí)Oracle驅(qū)動(dòng)引發(fā)的死鎖

    摘要:問題描述近期項(xiàng)目需要從虛擬機(jī)環(huán)境遷移到容器環(huán)境,其中有一個(gè)項(xiàng)目在遷移到容器環(huán)境之后的兩天之內(nèi)出現(xiàn)了次死鎖的問題,部分關(guān)鍵日志如下日志還是挺明顯的,線程獲得了鎖,等待獲取而正好相反,從而導(dǎo)致死鎖問題分析以上的錯(cuò)誤 問題描述 近期項(xiàng)目需要從虛擬機(jī)環(huán)境遷移到容器環(huán)境,其中有一個(gè)項(xiàng)目在遷移到容器環(huán)境之后的兩天之內(nèi)出現(xiàn)了2次死鎖(deadlock)的問題,部分關(guān)鍵日志如下: Found one ...

    Caicloud 評(píng)論0 收藏0
  • 一次 .NET 某電商無貨源后端服務(wù) 死鎖分析

    摘要:的情況下,必然就會(huì)死鎖,對(duì)吧,接下來怎么用驗(yàn)證呢切到號(hào)線程查看線程棧及棧對(duì)象。死鎖原因分析死鎖原因分析要想追究死鎖的原因,只能仔細(xì)推敲線程棧線程棧對(duì)象。在幾個(gè)痙攣過程中進(jìn)入了另外一個(gè)線程池的方法中,希望能得到該池中的鎖對(duì)象。一:背景1. 講故事這個(gè)月初,星球里的一位朋友找到我,說他的程序出現(xiàn)了死鎖,懷疑是自己的某些寫法導(dǎo)致mongodb出現(xiàn)了如此尷尬的情況,截圖如下:說實(shí)話,看過這么多dum...

    yimo 評(píng)論0 收藏0
  • 一次線程掛死的排查過程(附 HttpClient 配置建議)

    摘要:此時(shí)我想到了福爾摩斯說過的一句話當(dāng)你排除掉各種不可能出現(xiàn)的情況之后,剩下的情況無論多么難以置信,都是真相。福爾摩斯冷靜下來想一想,這個(gè)線程,有可能靜悄悄地退出了嗎,沒留下半點(diǎn)異常日志從理論上來說,不可能。配置建議最后,附上一份配置建議。 1、事發(fā) 我們有個(gè)視頻處理程序,基于 SpringBoot,會(huì)啟動(dòng)幾個(gè)線程來跑。要退出程序時(shí),會(huì)發(fā)送一個(gè)信號(hào)給程序,每個(gè)線程收到信號(hào)后會(huì)平滑退出,等全...

    jollywing 評(píng)論0 收藏0
  • 一次優(yōu)惠券最優(yōu)使用算法

    摘要:記一次優(yōu)惠券最優(yōu)使用算法先說一下業(yè)務(wù)背景。公司做的一個(gè)投資的,投資金額可以用優(yōu)惠券抵扣。但是無法獲取具體使用了哪張優(yōu)惠券簡單就是很難獲得優(yōu)惠券的窮舉法數(shù)據(jù)太多,不可控。但是這種面額的優(yōu)惠券出現(xiàn)幾率幾乎沒有請(qǐng)教期待有大神給出更好的算法 記一次優(yōu)惠券最優(yōu)使用算法 先說一下業(yè)務(wù)背景。公司做的一個(gè)投資的APP,投資金額可以用優(yōu)惠券抵扣。紅包面額(100,50,30,10) 優(yōu)惠券使用規(guī)則: ...

    Lowky 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<