資料庫中異常與隔離級别

概述

資料庫相對于其它存儲軟體一個核心的特征是它支援事務，所謂事務的ACID就是原子性，一緻性，隔離性和持久性。其中原子性，一緻性，持久性更多是關注單個事務本身，比如，原子性要求事務中的操作要麼都送出，要麼都不送出；一緻性要求事務的操作必須滿足定義的限制，包括觸發器，外鍵限制等；持久性則要求如果事務成功送出了，無論發生什麼異常，包括程序crash，主機掉電等，都應該確定事務不會丢失。而隔離性，則關注的是多個事務之間的并發。

 如果所有的事務都串行執行，互相不影響，不會有隔離的級别的問題。但是，串行無法充分發揮多核的優勢，是以需要并發執行多個事務，并且“盡量”做到并發執行的事務與串行執行等價。為什麼是“盡量”？是因為資料庫中實際上不隻有一種隔離級别，可串行化，是以才有必要讨論資料庫中的隔離級别。比如拿MySQL舉例，隔離級别包括，讀未送出，讀送出，可重複讀，和串行化4種，其中可串行化是最嚴格的隔離級别，意味着事務之間産生沖突的機率最高。理論上，隻有“可串行化”的事務序列才是“正确的”，但是，由于資料庫系統需要追求更好的性能，更高的系統吞吐，是以系統中會定義另外“比較弱”的隔離級别。每種“弱”的隔離級别定義，都會明确說明它會産生哪些“異常”，如果使用者能容忍這些“異常”，很好，那麼我們不用将資料庫設定為最嚴的并發控制模式。是以，簡單來說，通過隔離級别的設定，使用者可以在“異常”和資料庫性能之間做一個權衡。

資料庫中異常

本文讨論的隔離級别主要源于論文A Critique of ANSI SQL Isolation Levels，論文中定義了一系列“異常”，并且說明了不同的隔離級别分别解決了哪些“異常”。說明下文中，w[n]表示事務n寫，r[n]表示事務n讀，a[n]表示事務n-abort，c[n]表示事務n-commit。A0，P1，P2，P3，A4，A5等異常命名編号均來源于論文。

1.髒寫

A0,dirty-write(WW)，髒寫

通路模式：w1[x], w2[x],c1,c2

兩個事務先後寫x，這種會導緻w2事務覆寫w1的寫。

2.髒讀

P1,dirty-read(WR)，髒讀

通路模式：w1[x], r2[x],a1,c2

事務2讀到的x值，而最終事務1 abort了，這個x值根本不應該存在。

P1是區分Read Uncommitted和Read Committed隔離級别

3.不可重複讀

P2,Non-repeatable Read【Fuzzy Read】

通路模式，r1[x],w2[x],w2[commit],r1[x]

事務r1兩次通路x,傳回的結果不一樣。比如x=10，

r1[x=10],w2(x=50),w2[commit],r1[x=50]

事務r1兩次讀取x，讀到了不同的值。

P2用于區分ReadCommitted和RepeatableRead隔離級别。

4.幻讀

P3,Phantom

異常：同一個事務，兩次讀傳回的結果集不一樣，

這裡主要是說的幻讀，幻讀比不可重複讀要求更嚴格，即事務内的任何一個查詢，都不應該受其他事務的更新操作影響(insert,update,delete)，而出現結果不一緻的現象。比如說，第一個查詢select... where x>1 傳回了3條記錄(3,4,5)；在這個時候，有另外的一個事務insert x=6；當再次查詢時，發現x>1傳回了(3,4,5,6)4條記錄，這個就是幻讀現象的一種。

P3用于差別Repeatable Read和Serializable。

P1--P3是傳統的根據異常區分而定義的隔離級别，讀送出，可重複讀，串行化。但這種分法描述的異常可能還不夠多和完整，特别是對于普遍廣泛流行的MVCC并發控制，于是論文中在标準隔離級别基礎上将“異常”定義地更豐富，并且詳細介紹了目前Snapshot-Isolation。

5.Lost Update(寫覆寫)

A4, Lost Update

A4的通路模式r1[x], w2[x], w2[commit], w1[x], w1[commit]

這種通路模式下，w2的更新可能會丢失。因為w1可能基于一個比較old-x來做更新x的操作。

6.Read&Write Skew

A5, (Constraint Violation)，考慮到兩個相關聯記錄x,y，滿足x+y=100，根據讀寫可以分為兩種

A5A, Read Skew

r1[x]...w2[x]...w2[y]...c2...r1[y]...(c1 or a1)

事務1讀取x後，事務2同時更新了x，y然後commit，那麼事務1再讀取y。

x=50, y=50

r1[x=50]...w2[x=20]...w2[y=80]...c2...r1[y=80]...(c1 or a1)

那麼對于事務1，x+y=130

A5B, Write Skew(讀後寫)

A5B: r1[x]...r2[y]...w1[y]...w2[x]...(c1 and c2 occur)

C(x,y)滿足x+y >= 0, x=10, y=0

r1[x=10,y=0],r2[x=10,y=0],w1[y=-10],w2[x=0],w1(commit),w2(commit)

最終結果是x=0,y=-10，導緻不滿足x+y>=0的限制

資料庫的隔離級别

我們談隔離級别，實際上是在談并發控制。通常資料庫實作并發控制主要有兩類，基于鎖的悲觀并發控制(2PL)和樂觀并發控制(OCC)。前者在操作資料的過程中加鎖，直到事務送出時才釋放。後者在事務讀寫的過程中不加鎖，而是在送出的時候通過對比操作的readset和writeset來判斷事務是否存在沖突，來決定是否送出。原始的基于鎖的悲觀并發控制，讀和寫都加鎖，并發度比較低，是以目前主流的資料庫系統都引入了多版本并發控制機制(MVCC)，所謂MVCC，簡單來說，通過備援曆史版本，達到讀不加鎖，讀寫不互斥的目的，這種讀就是快照讀，差別于加鎖模式的目前讀。這一改進大大送出的整個資料庫系統的并發度，當然，如果要實作可串行化隔離級别，需要做額外的工作來保證。下面簡單讨論下不同隔離級别下，分别有哪些異常，以及主流資料庫的實作方式。

1.READ UNCOMMITTED

讀寫都不加鎖，資料庫完全不做并發控制，基本上沒什麼實用價值。

2.READ COMMITTED

寫記錄加鎖，讀基于快照讀，并且事務中每個語句有獨立的快照，確定讀到最新的事務送出，解決了髒讀的問題，但不解決可重複讀問題，當然也無法避免幻讀，ReadSkew&WriteSkew等問題。

3.REPEATABLE READ

提到REPEATABLE READ隔離級别，不得不提到SNAPSHOT，一般主流資料庫裡面都不提SNAPSHOT隔離級别，但是實際實作的時候又都是基于SNAPSHOT來做的，但這裡又有一些細微的差別。對于MySQL(InnoDB)而言，讀的時候仍然是快照讀，相對于READ-COMMITED隔離級别，是一個事務一個快照，確定可重複讀，也不存在幻讀問題；但是寫的時候，采用的目前讀，也就是更新的時候，不再考慮快照，而是基于最新的版本來更新，這樣就可能會造成LostUpdate問題。當然，解決辦法也很簡單，事務内的讀也采用目前讀，這樣也就避免了LostUpdate問題。這裡舉個例子：假設t是一張庫存表，pk='iphone'是主鍵，賣出一部iphone就減去一個庫存，count=count-1；假設有兩種寫法

case1:

begin:
select var = count from t where pk = 'iphone';
var = var - 1;
update count = var from t where pk = 'iphone';
commit;

case2：
begin：
update count = count - 1 from t where pk = 'iphone';
commit;
      

對于case1，就會發生LostUpdate，試想下如果兩個同類型的事務并發，快照讀讀到的是old count，就可能出現覆寫寫的問題，導緻庫存少減了。      

對于case2，則不會有LostUpdate問題，update場景下，讀都是目前讀，在RR隔離級别下，會加寫鎖，確定能讀到最新的count。      

對于MySQL(RocksDB)而言，讀一樣是基于同一個快照；寫的時候，仍然是基于快照讀(這個與RocksDB的LSM存儲結構有關，隻能基于一個快照去讀取多版本資料)，那麼要更新記錄時候，會判斷記錄中的版本是否比事務的快照版本新(ValidateSnapshot)，如果是，說明在事務擷取快照後，有其它事務執行了更新操作，這個時候事務會復原，也就不會發生LostUpdate問題。PG也是采用類似的機制，與MySQL(InnoDB)的本質差別在于，寫的時候，是基于快照讀去寫，而還是基于目前讀去寫。最終的效果是，MySQL(InnoDB)在RR隔離級别下，也會存在LostUpdate問題，同時因為快照讀和目前讀混用(select, select ... for update)，實際上嚴格來說，也就沒有解決幻讀和可重複讀的問題。Oracle沒有實作RR隔離級别，隻提供RC和SERIALIZABLE隔離級别。無論是MySQL(InnoDB,RocksDB),PG都沒有解決WriteSkew問題。

4.SERIALIZABLE

最嚴格的隔離級别，自然是沒有“異常”的，我們前面也說到，為了提供系統的并發度，才選擇通過降低資料庫的隔離級别，但必需要容忍部分“異常”。串行化解決了髒讀/寫，丢失更新，幻讀，不可重複讀，以及ReadSkew&WriteSkew等問題。MySQL(Innodb)通過将所有所有讀都變為目前讀，并結合(GAP,Next-Key,InsertIntention)lock來實作串行化隔離，PG則是事務送出時，根據readset和writeset檢查是否與其它事務之間有讀寫依賴成環，最終确定事務能否送出。MySQL(Rocksdb)隻支援RC和RR，不支援串行化隔離級别。下圖來源于論文，整理了不同隔離級别對應的異常。            

總結

本文結合論文和主流的資料庫系統讨論了資料庫的隔離級别。一般來說，生産環境中設定ReadCommit的居多，文章中也提到了，在讀送出隔離級别下，會存在有不可重複讀，幻讀以及Read/Write Skew等問題。說明，生産環境是可以“容忍”這些“異常”的。當然，這不能說明隔離級别不重要，如果某些業務場景，不能容忍“異常”，就比如我文章中提到的減庫存的例子，如果業務代碼寫法不正确，就可能導緻問題。總之，我們需要在系統的并發度和隔離級别做一個權衡，確定業務正确的前提下，得到最好的性能。

參考文檔

A Critique of ANSI SQL Isolation Levels

MyRocks隔離級别

PostgreSQL隔離級别