讀寫分離死鎖解決方案、事務發佈死鎖解決方案、發佈訂閱死鎖解決方案

前言：

        因爲網站訪問壓力的問題，綜合分析各類因素後結合實際狀況，採用數據庫讀寫分離模式來解決當前問題。實際方案中採用「事務發佈」模式實現主數據庫和只讀數據庫的同步，其中：

　　　　發佈服務器1臺：sql2008，推送訂閱模式

　　　　訂閱服務器2臺：sql2008

問題：

        以上方案後實施後，數據同步正常，但從日誌中發現了死鎖狀況。錯誤提示如：事務(進程 ID *)與另外一個進程被死鎖在 鎖 資源上，而且已被選做死鎖犧牲品。請從新運行該事務。

查詢一些資料後，肯定是數據同步的同時資源被鎖，同時用戶訪問頁面請求，致使死鎖產生，按照事務優先級，應用程序產生死鎖。

解決方法：

        找到大體思路後，查詢了一些資料，大部分資料顯示是死鎖如何產生，若是跟蹤日誌，而後根據日誌優化查詢等方向，嘗試一些方案後死鎖減小，但並無完全解決，最後轉換思路，從項目實際狀況來看，主要是資訊信息的查詢，對查詢結果的安全性要求相對不高，因此能夠接受「髒」數據的狀況，在某種狀況下又能提高查詢的性能，因而在一些查詢頻繁和數據量比較大的幾個表的select語句中加入with(nolock)，死鎖問題完全解決。

 

建議：

        處理一個數據庫死鎖的異常時候，其中一個建議就是使用 NOLOCK 或者 READPAST，對於非銀行等嚴格要求事務的行業，搜索記錄中出現或者不出現某條記錄，都是在可容忍範圍內，因此碰到死鎖，應該首先考慮，咱們業務邏輯是否能容忍出現或者不出現某些記錄，而不是尋求對雙方都加鎖條件下如何解鎖的問題。

NOLOCK 和 READPAST 都是處理查詢、插入、刪除等操做時候，如何應對鎖住的數據記錄。可是這時候必定要注意NOLOCK 和 READPAST的侷限性，確認你的業務邏輯能夠容忍這些記錄的出現或者不出現： 
簡單來講：

NOLOCK 可能把沒有提交事務的數據也顯示出來．

READPAST 會把被鎖住的行不顯示出來 

不使用 NOLOCK 和 READPAST ，在 Select 操做時候則有可能報錯誤：事務(進程 ID **)與另外一個進程被死鎖在 鎖 資源上，而且已被選做死鎖犧牲品。 

 

作此記錄，但願給遇到一樣的問題的朋友一些幫助。