很久沒有寫博客了，這里面的原因有很多。最近的一個(gè)項(xiàng)目由于客戶明確提出要做下性能壓力測(cè)試，使用的工具就是VS自帶的壓力測(cè)試工具。以前其它項(xiàng)目做壓力測(cè)試后反饋的其中一個(gè)重要問題就是數(shù)據(jù)庫的死鎖。沒想到我們這個(gè)項(xiàng)目測(cè)試時(shí)死鎖同樣的發(fā)生了，我之前的項(xiàng)目由于很少參與壓力測(cè)試，基本上也不會(huì)去了解死鎖，以及死鎖如何解決的問題。

既然有了這個(gè)需求，那么要想解決死鎖就需要對(duì)死鎖的相關(guān)知識(shí)有一定的了解，對(duì)于非DBA的來講并不需要了解的特別深，知道基本概念以及常見分析方法即可，畢竟我們不靠這個(gè)吃飯，沒必要達(dá)到特別細(xì)的境界。這里我找到了一個(gè)微軟MVP寫的一系統(tǒng)博客，對(duì)我理解死鎖非常重要，這里分享下目前我為解決死鎖所采用過的方案。

壓力測(cè)試的業(yè)務(wù)場(chǎng)景：

1.模擬用戶提交申請(qǐng)

a) 涉及到的表

i.申請(qǐng)主表，一次申請(qǐng)生成一條數(shù)據(jù)。

ii. 申請(qǐng)的醫(yī)生明細(xì)，一次申請(qǐng)包含多個(gè)醫(yī)生，一個(gè)申請(qǐng)包含100個(gè)醫(yī)生

iii. 單個(gè)醫(yī)生明細(xì)，每個(gè)醫(yī)生一條明細(xì)數(shù)據(jù)

綜上所述一條申請(qǐng)的創(chuàng)建，需要插入201條數(shù)據(jù)。

b) 申請(qǐng)邏輯

i. 首先調(diào)用保存

ii. 然后執(zhí)行提交邏輯

各種邏輯驗(yàn)證，這是歷史原因造成的(一個(gè)維護(hù)了幾年的項(xiàng)目代碼邏輯的混亂是難以想象的)，總是在提交數(shù)據(jù)時(shí)做雙重較驗(yàn) ，比如數(shù)據(jù)是否有重復(fù)行的邏輯，這里會(huì)反復(fù)讀取申請(qǐng)醫(yī)生表以及醫(yī)生明細(xì)這兩個(gè)申請(qǐng)明細(xì)子表。這也是產(chǎn)生死鎖的主要原因，此場(chǎng)景已經(jīng)滿足了同時(shí)讀取以及修改同一表的情況。除此還會(huì)往其它表中插入數(shù)據(jù)，比如一些狀態(tài)跟蹤信息，發(fā)郵件等。

至于為什么被分割成兩個(gè)邏輯來處理這原本是同一動(dòng)作的需求，已經(jīng)法考正最初的設(shè)計(jì)者了，這些邏輯包含各種EntityFramwork的查詢寫法，很難做有效的優(yōu)化。

2.壓力設(shè)置

a)并發(fā)8個(gè)用戶

b)每1分鐘增加5個(gè)用戶

曾經(jīng)學(xué)過的方法：

1. 降低事務(wù)隔離級(jí)別為read uncommitted,結(jié)果是并不能消除死鎖，但死鎖的次數(shù)有所降低，主要時(shí)共享鎖引發(fā)的死鎖次數(shù)降低了。
2. 分段分析法，也可以說是排除法。只執(zhí)行一部分邏輯，比如我們上面的一個(gè)申請(qǐng)分為兩步，先保存后提交，只保存的結(jié)果是死鎖依舊。
3. 尋找死鎖跟蹤的方法，試圖尋找死鎖的本質(zhì)原因。我簡(jiǎn)單的按我自己的理解翻譯了一些MVP寫的文章，大家可以參考 。

• [翻譯]:SQL死鎖-鎖的類型

解釋了SQL 中的各種鎖以及它們之間的兼容性，只有了解了這些才能知道鎖發(fā)生的場(chǎng)景，比如知道了共享鎖之間是兼容的就能馬上反應(yīng)出純讀的操作是不會(huì)發(fā)生阻塞的

• [翻譯]:SQL死鎖-鎖與事務(wù)級(jí)別

事務(wù)隔離級(jí)別的不同會(huì)影響鎖的行為，其中重要說明了降低事務(wù)隔離級(jí)別并不能消除死鎖

• [翻譯]:SQL死鎖-阻塞

只有出現(xiàn)了阻塞才會(huì)升級(jí)成死鎖，所有了解阻塞是第一件事

• [翻譯]:SQL死鎖-阻塞探測(cè)

這篇通過兩種方式說明如何去跟蹤分析死鎖的本質(zhì)原因，通過SQL自帶的性能監(jiān)控工且可以很方便的導(dǎo)出出現(xiàn)死鎖的相關(guān)信息

• [翻譯]:SQL死鎖-為什么會(huì)出現(xiàn)死鎖

這篇非常詳細(xì)的說明了死鎖產(chǎn)生的原理

死鎖文章的重要結(jié)論：

大部分死鎖是因?yàn)槲唇?jīng)過優(yōu)化的查詢導(dǎo)致的，但因?yàn)槲覀冺?xiàng)目在處理這個(gè)申請(qǐng)的邏輯中有太多邏輯，不太可能在短時(shí)間內(nèi)進(jìn)行有效的優(yōu)化，所以我暫時(shí)采用了一個(gè)也許不是很好的方案，即想辦法降低排它鎖的相互競(jìng)爭(zhēng)，說的簡(jiǎn)單點(diǎn)說是在程序中通過一定的手段避免并發(fā)去調(diào)用更新或者插入數(shù)據(jù)的邏輯。

偏門解決方案：

通過一個(gè)取票排隊(duì)的隊(duì)列去解決數(shù)據(jù)插入以及更新的并發(fā)，原理就是一個(gè)線程想要插入數(shù)據(jù)時(shí)，先取票然后排隊(duì)，當(dāng)號(hào)輪到它時(shí)才能執(zhí)行數(shù)據(jù)庫操作，其它線程正在執(zhí)行時(shí)，我們通過自族鎖來實(shí)現(xiàn)排隊(duì)。這個(gè)方法最大程序上解決死鎖的問題，但不推薦這么做，之所以采用這種非常規(guī)手段，也是受制于現(xiàn)有程序的邏輯。如果大家在EF中也解決過死鎖問題，可將經(jīng)理分享給我。

       public   int AddWithSpinLock(ObjectModel.Request svarRequest)        {            bool lockTaken = false;            svarRequest.Ticket = Guid.NewGuid();            var newRequestId = 0;            try            {                _spinlock.Enter(ref lockTaken);                _queue.Enqueue(svarRequest);                while (null != _queue && _queue.Count > 0 && _queue.Peek().Ticket == svarRequest.Ticket)                {                    // do something                    _queue.Dequeue();                    return newRequestId;                }            }            catch (Exception ex)            {                if (lockTaken) _spinlock.Exit(false);                _queue.Dequeue();                throw ex;            }            finally            {                               if (lockTaken) _spinlock.Exit(false);            }            return newRequestId;        }