亞信科技AntDB資料庫——深入瞭解AntDB-M後設資料鎖的實現（二）

5.5  防止低優先順序鎖飢餓

AntDB-M按照優先順序將鎖又分了兩類，用於解決低優先順序鎖飢餓問題。

●獨佔型(hog): X, SNRW, SNW; 具有較強的不相容性，優先順序高，容易霸佔鎖，造成其他低優先順序鎖一直處於等待狀態。

●闇弱型(piglet): SW; 優先順序僅高於SRO。

這兩種型別鎖會分別進行加鎖計數。當授予hog型別鎖時，如果等待佇列中有非hog型別，則計數加1。當授予piglet型別鎖時，如果等待佇列中有SRO，則計數加1。針對計數是否超過閥值(max_write_lock_count)制定了四種優先順序矩陣。在加鎖授權檢測時，如果兩種型別中有任一達到統計閥值，則切換到對應的優先順序矩陣，重新檢測是否可以授權，此時優先順序進行了反轉，會提升低優先順序鎖優先獲取鎖。當前等待佇列裡低優先順序鎖處理完畢後，會重置對應的hog,piglet計數器，並反轉優先順序。

5.6  死鎖檢測

圖1-死鎖等待

每個執行緒在進入鎖等待前，都會先進行死鎖檢測，避免陷入死鎖等待。在檢測前，會先將自己獲取到的unobtrusive鎖進行物化，即將鎖放入鎖的授予列表中，以便死鎖檢測能區分鎖的歸屬執行緒。然後設定自己上下文等待ticket，每個進入等待的執行緒都有自己的等待ticket，用於死鎖檢測。

AntDB-M使用等待圖演算法進行死鎖檢測，每個鎖物件下的waiting佇列中的每個ticket都存在自己的不相容鎖，即正在等待的鎖，所有鎖物件下的waiting佇列中的ticket根據等待關係，構成了一個等待圖。先對當前執行緒的等待的鎖物件下的所有ticket進行廣度優先檢測，即對當前ticket節點的所有邊進行檢測，在沒有發現死鎖時，再進入每個ticket上下文的等待ticket對應的鎖物件進行深度檢測。

圖2-死鎖檢測

檢測開始時記住此次檢測的起始上下文，即當前執行緒的上下文。當在廣度、深度遍歷過程中，發現等待路徑上再次出現起始上下文，說明出現了迴圈等待，即死鎖。如果檢測深度(即檢測上下文個數)超過閥值（32），也認為出現了死鎖。

5.7  死鎖驅逐

當發現死鎖時，在整個檢測路徑上包括自己會有2到多個ticket，對於這些ticket，會選其中死鎖權重最低的設定狀態為驅逐，即喚醒該執行緒結束等待，將自己從鎖物件的等待佇列中移除。權重分為3級:DDL鎖 > 使用者級鎖 > DML鎖。在出現死鎖時，更傾向於讓DML事務回滾，讓DDL語句繼續執行。權重相同時，更傾向於後進入等待佇列的事務回滾。在設定了驅逐狀態後，並不能保證剩餘的鎖間沒有死鎖，會重新進行一次死鎖檢測，直到沒有發現死鎖，或者將自己設為驅逐狀態為止。對每個上下文進行檢測時，對其加讀鎖，避免上下文的等待物件被重置。

對每個鎖物件進行檢測時，對其加讀鎖，避免已授權、等待佇列被更新。透過讀鎖保障資料安全的同時，又保障了多執行緒間的併發操作。

5.8  鎖等待及通知

每個執行緒的鎖上下文都有一個條件變數來進行鎖等待。執行緒在沒有獲取鎖的授權時，會將自己的ticket新增到鎖物件的等待佇列，並進入等待狀態。等待佇列的鎖授予檢測有3個時機：

1）加鎖申請階段，hog,piglet型別鎖申請個數超過閥值。

2）當有執行緒釋放後設資料鎖。

3）後設資料鎖降級。

時機觸發時，會遍歷該鎖物件的等待列表，檢測到可以授予時，設定執行緒等待狀態為授予鎖，通知該執行緒，並將ticket從等待佇列移到授予佇列。

總結

AntDB-M透過多層次、多粒度、多優先順序提供了靈活豐富的後設資料鎖功能，適用於各種業務場景。將加鎖路徑區分快速、慢速路徑，提高絕大部分業務場景的加鎖效率。透過優先順序反轉，避免低優先順序飢餓。高效的廣度優先死鎖檢測技術，避免了死鎖的發生。如果檢測到了死鎖，會優先驅逐DML操作，保障成本更高的DDL操作，相同操作會優先驅逐等待時間更短的操作，保持公平性。

關於亞信安慧AntDB資料庫

AntDB資料庫始於2008年，在運營商的核心繫統上，服務國內24個省市自治區的數億使用者，具備高效能、彈性擴充套件、高可靠等產品特性，峰值每秒可處理百萬筆通訊核心交易，保障系統持續穩定執行超十年，並在通訊、金融、交通、能源、物聯網等行業成功商用落地。