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

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

     1.模擬用戶提交申請

         a)  涉及到的表

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

              ii. 申請的醫(yī)生明細，一次申請包含多個醫(yī)生，一個申請包含100個醫(yī)生

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

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

        b)   申請邏輯

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

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

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

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

     2. 壓力設(shè)置

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

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

 [[110028]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

偏門解決方案：

通過一個取票排隊的隊列去解決數(shù)據(jù)插入以及更新的并發(fā)，原理就是一個線程想要插入數(shù)據(jù)時，先取票然后排隊，當(dāng)號輪到它時才能執(zhí)行數(shù)據(jù)庫操作，其它線程正在執(zhí)行時，我們通過自族鎖來實現(xiàn)排隊。這個方法***程序上解決死鎖的問題，但不推薦這么做，之所以采用這種非常規(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<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