資料庫原理 - 序列2 - 事務隔離級別和死鎖檢測

本文節選自《軟體架構設計：大型網站技術架構與業務架構融合之道》第6.4章節。作者微信公眾號：架構之道與術。進入後，可以加入書友群，與作者和其他讀者進行深入討論。也可以在京東、天貓上購買紙質書。 6.4.1 事務的四個隔離級別通俗地講，事務就是一個“代碼塊”，這個代碼塊要麼不執行，要麼全部執行。事 ...

本文節選自《軟體架構設計：大型網站技術架構與業務架構融合之道》第6.4章節。作者微信公眾號：
架構之道與術。進入後，可以加入書友群，與作者和其他讀者進行深入討論。也可以在京東、天貓上購買紙質書。

6.4.1 事務的四個隔離級別

通俗地講，事務就是一個“代碼塊”，這個代碼塊要麼不執行，要麼全部執行。事務要操作數據（資料庫裡面的表），事務與事務之間會存在併發衝突，就好比在多線程編程中，多個線程操作同一份數據，存線上程間的併發衝突是一個道理。
事務與事務併發地操作資料庫的表記錄，可能會導致下麵幾類問題，如表6-3所示。
表6-3 事務併發導致的幾類問題
在這裡插入圖片描述

為瞭解決上面幾類問題，資料庫設置了不同的事務隔離級別。不同資料庫在事務隔離級別的定義和實現上會有差異，下麵以MySQL InnoDB引擎為例，分析隔離級別是如何定義的，如表6-4所示。

表6-4 InnoDB事務隔離級別
在這裡插入圖片描述
從表6-4中可以看出，隔離級別，一級比一級嚴格。隔離級別4就是串列化，所有事務串列執行，雖然能解決上面的四個問題，但性能無法接受，所以一般不會採用；隔離級別1沒有任何作用，也不會採用；所以常用的是隔離級別2和隔離級別3。
既然預設的隔離級別是3（RR），如何解決最後一個問題，丟失更新呢？這涉及下麵要講的悲觀鎖和樂觀鎖。

6.4.2 悲觀鎖和樂觀鎖

丟失更新在業務場景中非常常見，資料庫沒有幫工程師解決這個問題，只能靠我們自己解決了。先看丟失更新出現的場景：假設DB中有張數據表，如表6-5所示。
表6-5 用戶餘額表T
在這裡插入圖片描述
兩個事務併發地對同一條記錄進行修改，一個充錢，一個扣錢，偽代碼如下：
事務A：

start transaction 
int b = select balance from T where user_id = 1 
b = b + 50
update T set balance = b where user_id = 1
commit

事務B：

start transaction 
int b = select balance from T where user_id = 1 
b = b - 50
update T set balance = b where user_id = 1
commit

如果正確地執行了事務A和事務B（無論誰先誰後），執行完成之後，user_id=1的用戶餘額都是30；但現在事務A和事務B並行執行，執行結果可能是30（正確結果），也可能是80（事務A把事務B的結果覆蓋了），或者是20（事務B把事務A的結果覆蓋了），這兩種結果都是錯誤的。
要解決這個問題，有下麵幾種方法：
方法1：利用單條語句的原子性
在上面的每個事務里，都是把數據先select出來，再update回去，沒有辦法保證兩條語句的原子性。如果改成一條語句，就能保證原子性，如下所示：
事務A：

start transaction 
update T set balance = balance + 50 where user_id = 1
commit

事務B：

start transaction 
update T set balance = balance -50 where user_id = 1
commit

這種方法簡單可行，但很有局限性。因為實際的業務場景往往需要把balance先讀出來，做各種邏輯計算之後再寫回去。如果不讀，直接修改balance，沒有辦法知道修改之前的balance的值是多少。

方法2：悲觀鎖
悲觀鎖，就是認為數據發生併發衝突的概率很大，所以讀之前就上鎖。利用select xxx for update語句，偽代碼如下所示：
事務A：

start transaction 
//對user_id=1的記錄上悲觀鎖
int b = select balance from T where user_id = 1 for update 
b = b + 50
update T set balance = b where user_id = 1
commit

事務B：

start transaction 
//對user_id=1的記錄上悲觀鎖
int b = select balance from T where user_id = 1 for update
b = b - 50
update T set balance = b where user_id = 1
commit

悲觀鎖有潛在問題，假如事務A在拿到鎖之後、Commit之前出問題了，會造成鎖不能釋放，資料庫死鎖。另外，一個事務拿到鎖之後，其他訪問該記錄的事務都會被阻塞，這在高併發場景下會造成用戶端的大量請求阻塞。為此，有了下麵的樂觀鎖。

方法3：樂觀鎖
對於樂視鎖，認為數據發生併發衝突的概率比較小，所以讀之前不上鎖。等到寫回去的時候再判斷數據是否被其他事務改了，即多線程裡面經常會講的CAS（Comapre And Set）的思路。下麵來看一下，如何實現在資料庫層面做CAS：如表6-6所示，給上面的表再加一列version欄位。
表6-6 實現樂觀鎖的表結構
在這裡插入圖片描述

對應的偽代碼如下所示：
事務A

while(!result)  //CAS不成功，把數據重新讀出來，修改之後，重新CAS
 {
start transaction
int b, v1 = select balance, version from T where user_id = 1 ; 
  b = b + 50;
 result = update T set balance = b, version = version + 1 where user_id = 1 and version = v1;  //CAS
commit
 }

事務B

while(!result) 
{
start transaction 
 int b, v1 = select balance, version from T where user_id = 1 ;
 b = b - 50;
  result = update T set balance = b, version = version + 1 where user_id = 1 and version = v1; //CAS
commit
}

CAS的核心思想是：數據讀出來的時候有一個版本v1，然後在記憶體裡面修改，當再寫回去的時候，如果發現資料庫中的版本不是v1（比v1大），說明在修改的期間內別的事務也在修改，則放棄更新，把數據重新讀出來，重新計算邏輯，再重新寫回去，如此不斷地重試。

在實現層面，就是利用update語句的原子性實現了CAS，當且僅當version=v1時，才能把balance更新成功。在更新balance的同時，version也必須加1。version的比較、version的加1、balance的更新，這三件事情都是在一條update語句裡面完成的，這是這個事情的關鍵所在！
當然，在實際場景中，不會讓客戶端無限迴圈地重試，可以重試三次，然後在操作界面上提示稍後再操作。

順便介紹Java是如何利用CAS來做樂觀鎖的。下麵是JDK6的JUC包裡面，AtomicInteger的源代碼：

public final int getAndIncrement() { 
for (;;) {  //失敗，無限迴圈重試 
int current = get();  //讀取值 
int next = current + 1;  //修改值 
if (compareAndSet(current, next))  return current;  //CAS
} 
}
public final int getAndDecrement() {
 for (;;) {
 int current = get(); 
int next = current - 1; 
if (compareAndSet(current, next)) return current; 
} 
}
public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);  //調用native代碼，實現一個CAS原子操作
}

方法4：分散式鎖
樂觀鎖的方案可以很好地應對上述場景，但有一個限制是select和update的是同一張表的同一條記錄，如果業務場景更加複雜，有類似下麵的事務：

start_transaction
  select xxx from T1
  select xxx from T2
  …根據T1和T2查詢結果進行邏輯計算，然後更新T3
  update T3
commit

要實現update表T3的同時，表T1和表T2是鎖住狀態，不能讓其他事務修改。在這種場景下，樂觀鎖也不能解決，需要分散式鎖。當然，分散式鎖也不是一個完善的方案，存在各種問題，後面會對其專門探討。

6.4.3 死鎖檢測

上層應用開發會加各種鎖，有些鎖是隱式的，資料庫會主動加；而有些鎖是顯式的，比如上文所說的悲觀鎖。因為開發使用的不當，資料庫會發生死鎖。所以，作為資料庫，必須有機制檢測出死鎖，並解決死鎖問題。
先以兩個事務為例，看一下死鎖發生的原理。

如圖6-5所示：事務A持有鎖1，事務B持有鎖2，然後事務A請求鎖2，但請求不到；事務B請求鎖1，也請求不到。兩個事務各拿一個鎖，各請求對方的鎖，互相等待，發生死鎖。

圖6-5 兩個事務發生死鎖示意圖
在這裡插入圖片描述

把兩個事務的場景擴展到多個事務，如圖6-6所示。

圖6-6 多個事務發生死鎖的示意圖
在這裡插入圖片描述
以事務為頂點，以事務請求的鎖為邊，構建一個有向圖，這個圖被稱為Wait-for Graph。比如事務A要請求鎖1、鎖2，而鎖1、鎖2分別被事務B、事務C持有，因此事務A依賴事務B、事務C；事務B要請求鎖3，而鎖3被事務C持有，所以事務B依賴事務C；事務C要請求鎖4，而鎖4被事務A持有，所以事務C依賴事務A；依此類推。

死鎖檢測就是發現這種有向圖中存在的環，本圖中就是事務A、事務B、事務C之間出現了環，所以發生了死鎖。關於如何判斷一個有向圖是否存在環屬於圖論中的基本問題，存在多種演算法，此處不展開討論。

檢測到死鎖後，資料庫可以強制讓其中某個事務回滾，釋放掉鎖，把環斷開，死鎖就解除了。

具體到MySQL，開發者可以通過日誌或者命令查看當前資料庫是否發生了死鎖現象。遇到這種問題，需要排查代碼，分析死鎖發生的原因，定位到具體的SQL語句，然後解決。死鎖發生的場景非常的多，與代碼有關，也與事務隔離級別有關，只能根據具體問題分析SQL語句解決。下麵隨便列舉兩個死鎖發生的場景。

場景1：如表6-7所示，事務A操作了表T1、T2的兩條記錄，事務B也操作了表T1、T2中同樣的兩條記錄，順序剛好反過來，可能發生死鎖。
表6-7 死鎖發生場景1
在這裡插入圖片描述

場景2：如表6-8所示，同一張表，在第三個隔離級別（RR）下，insert操作會增加Gap鎖，可能導致兩個事務死鎖。這個比較隱晦，不容易看出來。
表6-8 死鎖發生場景2
在這裡插入圖片描述