很久沒有寫博客了，這里面的原因有很多。最近的一個項目由於客戶明確提出要做下性能壓力測試，使用的工具就是VS自帶的壓力測試工具。以前其它項目做壓力測試后反饋的其中一個重要問題就是數據庫的死鎖。沒想到我們這個項目測試時死鎖同樣的發生了，我之前的項目由於很少參與壓力測試，基本上也不會去了解死鎖，以及死鎖如何解決的問題。
既然有了這個需求，那么要想解決死鎖就需要對死鎖的相關知識有一定的了解，對於非DBA的來講並不需要了解的特別深，知道基本概念以及常見分析方法即可，畢竟我們不靠這個吃飯，沒必要達到特別細的境界。這里我找到了一個微軟MVP寫的一系統博客，對我理解死鎖非常重要，這里分享下目前我為解決死鎖所采用過的方案。
壓力測試的業務場景：
1.模擬用戶提交申請
a) 涉及到的表
i. 申請主表，一次申請生成一條數據。
ii. 申請的醫生明細，一次申請包含多個醫生，一個申請包含100個醫生
iii. 單個醫生明細，每個醫生一條明細數據
綜上所述一條申請的創建，需要插入201條數據。
b) 申請邏輯
i. 首先調用保存
ii. 然后執行提交邏輯
各種邏輯驗證，這是歷史原因造成的(一個維護了幾年的項目代碼邏輯的混亂是難以想象的)，總是在提交數據時做雙重較驗 ，比如數據是否有重復行的邏輯，這里會反復讀取申請醫生表以及醫生明細這兩個申請明細子表。這也是產生死鎖的主要原因，此場景已經滿足了同時讀取以及修改同一表的情況。除此還會往其它表中插入數據，比如一些狀態跟蹤信息，發郵件等。
至於為什么被分割成兩個邏輯來處理這原本是同一動作的需求，已經法考正最初的設計者了，這些邏輯包含各種EntityFramwork的查詢寫法，很難做有效的優化。
2. 壓力設置
a) 並發8個用戶
b) 每1分鍾增加5個用戶
曾經學過的方法：
- 降低事務隔離級別為read uncommitted,結果是並不能消除死鎖，但死鎖的次數有所降低，主要時共享鎖引發的死鎖次數降低了。
- 分段分析法，也可以說是排除法。只執行一部分邏輯，比如我們上面的一個申請分為兩步，先保存后提交，只保存的結果是死鎖依舊。
- 尋找死鎖跟蹤的方法，試圖尋找死鎖的本質原因。我簡單的按我自己的理解翻譯了一些MVP寫的文章，大家可以參考 。
解釋了SQL 中的各種鎖以及它們之間的兼容性，只有了解了這些才能知道鎖發生的場景，比如知道了共享鎖之間是兼容的就能馬上反應出純讀的操作是不會發生阻塞的
事務隔離級別的不同會影響鎖的行為，其中重要說明了降低事務隔離級別並不能消除死鎖
只有出現了阻塞才會升級成死鎖，所有了解阻塞是第一件事
這篇通過兩種方式說明如何去跟蹤分析死鎖的本質原因，通過SQL自帶的性能監控工且可以很方便的導出出現死鎖的相關信息
這篇非常詳細的說明了死鎖產生的原理
死鎖文章的重要結論：
大部分死鎖是因為未經過優化的查詢導致的，但因為我們項目在處理這個申請的邏輯中有太多邏輯，不太可能在短時間內進行有效的優化，所以我暫時采用了一個也許不是很好的方案，即想辦法降低排它鎖的相互競爭，說的簡單點說是在程序中通過一定的手段避免並發去調用更新或者插入數據的邏輯。
偏門解決方案：
通過一個取票排隊的隊列去解決數據插入以及更新的並發，原理就是一個線程想要插入數據時，先取票然后排隊，當號輪到它時才能執行數據庫操作，其它線程正在執行時，我們通過自族鎖來實現排隊。這個方法最大程序上解決死鎖的問題，但不推薦這么做，之所以采用這種非常規手段，也是受制於現有程序的邏輯。如果大家在EF中也解決過死鎖問題，可將經理分享給我。
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;
}