本文節選自《軟件架構設計：大型網站技術架構與業務架構融合之道》第6.4章節。 做者微信公衆號：
架構之道與術。進入後，能夠加入書友羣，與做者和其餘讀者進行深刻討論。也能夠在京東、天貓上購買紙質書。java
6.4.1 事務的四個隔離級別
通俗地講，事務就是一個「代碼塊」，這個代碼塊要麼不執行，要麼所有執行。事務要操做數據（數據庫裏面的表），事務與事務之間會存在併發衝突，就比如在多線程編程中，多個線程操做同一份數據，存在線程間的併發衝突是一個道理。
事務與事務併發地操做數據庫的表記錄，可能會致使下面幾類問題，如表6-3所示。
表6-3 事務併發致使的幾類問題
算法
爲了解決上面幾類問題，數據庫設置了不一樣的事務隔離級別。不一樣數據庫在事務隔離級別的定義和實現上會有差別，下面以MySQL InnoDB引擎爲例，分析隔離級別是如何定義的，如表6-4所示。sql
表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的加一、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要請求鎖一、鎖2，而鎖一、鎖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操做了表T一、T2的兩條記錄，事務B也操做了表T一、T2中一樣的兩條記錄，順序恰好反過來，可能發生死鎖。
表6-7 死鎖發生場景1
場景2：如表6-8所示，同一張表，在第三個隔離級別（RR）下，insert操做會增長Gap鎖，可能致使兩個事務死鎖。這個比較隱晦，不容易看出來。
表6-8 死鎖發生場景2