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

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

     1.模擬用戶(hù)提交申請(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)滿(mǎn)足了同時(shí)讀取以及修改同一表的情況。除此還會(huì)往其它表中插入數(shù)據(jù)，比如一些狀態(tài)跟蹤信息，發(fā)郵件等。

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

     2. 壓力設(shè)置

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

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

 [[110028]]

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

1. 降低事務(wù)隔離級(jí)別為read uncommitted,結(jié)果是并不能消除死鎖，但死鎖的次數(shù)有所降低，主要時(shí)共享鎖引發(fā)的死鎖次數(shù)降低了。

2. 分段分析法，也可以說(shuō)是排除法。只執(zhí)行一部分邏輯，比如我們上面的一個(gè)申請(qǐng)分為兩步，先保存后提交，只保存的結(jié)果是死鎖依舊。

3. 尋找死鎖跟蹤的方法，試圖尋找死鎖的本質(zhì)原因。我簡(jiǎn)單的按我自己的理解翻譯了一些MVP寫(xiě)的文章，大家可以參考 。

• [翻譯]:SQL死鎖-鎖的類(lèi)型

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

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

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

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

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

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

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

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

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

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

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

偏門(mén)解決方案：

通過(guò)一個(gè)取票排隊(duì)的隊(duì)列去解決數(shù)據(jù)插入以及更新的并發(fā)，原理就是一個(gè)線(xiàn)程想要插入數(shù)據(jù)時(shí)，先取票然后排隊(duì)，當(dāng)號(hào)輪到它時(shí)才能執(zhí)行數(shù)據(jù)庫(kù)操作，其它線(xiàn)程正在執(zhí)行時(shí)，我們通過(guò)自族鎖來(lái)實(shí)現(xiàn)排隊(duì)。這個(gè)方法***程序上解決死鎖的問(wèn)題，但不推薦這么做，之所以采用這種非常規(guī)手段，也是受制于現(xiàn)有程序的邏輯。如果大家在EF中也解決過(guò)死鎖問(wèn)題，可將經(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<br>                    _queue.Dequeue(); 
             return newRequestId; 
         } 
     } 
     catch (Exception ex) 
     { 
         if (lockTaken) _spinlock.Exit(false); 
         _queue.Dequeue(); 
         throw ex; 
     } 
     finally 
     {                
         if (lockTaken) _spinlock.Exit(false); 
     } 
     return newRequestId; 
 } 

原文鏈接：http://www.cnblogs.com/ASPNET2008/p/3604335.html