什麼是事物？系統的詳盡的認識事物------>咬文嚼字版

文章目錄：

事物的理解

壹、什麼是事物？事物的 ACID（Atomicity 、Consistency 、Durability、Isolation ）？

貳、臟讀、不可重覆讀、幻讀？

叄、事物的隔離級別？

深入理解 Spring 事務原理 

壹、事務的基本原理

貳、Spring 事務的傳播屬性

叄、資料庫隔離級別

肆、常量解釋

伍、事務的嵌套

陸、總結

事物的認知

壹、什麼是事物？事物的 ACID（Atomicity 、Consistency 、Durability、Isolation ）？

事物 ：邏輯上的一系列操作 要麼成功（commit） 要麼失敗（rollback）；
A原子性：事物是不可分割的工作單位。要麼成功， 要麼失敗。比如說 付款、發貨，這一系列操作是不可分割的，要麼付款和發貨都成功，要麼都失敗；不能說付款後，還不發貨又或者付款失敗，還繼續發貨
C一致性：在事物的一系列操作中 ，數據的完整性得到保證。
I隔離性：多用戶訪問資料庫時，併發產生的多個事物要相互隔離，互不幹擾。也就是說多個事物訪問數據時，需要設置隔離級別。
D持久性：一次事物一旦Commit，數據就會被永久保存至資料庫。即使資料庫發生故障也不會造成數據丟失。

貳、臟讀、不可重覆讀、幻讀？

臟讀是`1針對未commit的數據而言。
臟讀主要是在修改數據的時候產生，指的是A事物在修改數據時未commit，也未rollback的，B事物卻讀到A事物在修改數據時未commit，也未rollback的數據，那麼我們就稱B事物所讀數據的操作為臟讀。（臟讀數據具有不可操作性）

不可重覆讀是針對同一數據而言。
不可重覆讀主要體現在修改數據時，例如開啟的C事物對資料庫中data1數據的兩次讀取結果的不對應，所產生的情況。這樣的情況是可以想到的，事務C在事務D修改data1數據之前，讀取一次data1數據；又在事務D修 改data1數據之後（不管事物D修改data1數據時是否commit,事物C都可讀到修改的數據，所以修改的data1數據不需要考慮是否commit；只不過若未commit，事物C所讀的data1具有不可操作性），再讀取一次data1數據，那麼D事物兩次讀的結果可想而知了。（開啟事物後，同一個查詢是可以多次執行的）

幻讀是針對資料庫中的多條數據而言。
幻讀通常是插入數據或者刪除數據時產生的,例如開啟事物E，插入（刪除3）條數據，而開啟的事物F在事物E插入（刪除3）條數據前查詢一下資料庫的數據條數，又在事物E插入（刪除3）條數據後查詢一下資料庫的 數據條數。那麼事物F兩次查詢的數據條數就會不一致，也就產生了一種視覺欺騙，然後就會想：哎呀，資料庫明明10條數據，怎麼有多了（少了）3條數據，。

叄、事物的隔離級別？

1、Read Uncommit:當隔離級別設置為Read Uncommit時，可能會出現臟讀、不可重覆讀、幻讀這三種情況
2、Read Commit:當隔離級別設置為Read Commit時，避免了臟讀，但可能會出現不可重覆讀、幻讀這兩種情況
3、Repeatable Read:當隔離級別設置為Repeatable Read時，避免了臟讀、不可重覆讀幻讀，但可能會出現幻讀這種情況
4、Serializable:當設置為最為嚴格的隔離級別Serializable時，就會完全避免了臟讀、不可重覆讀幻讀、幻讀。而且所有的事物的一系列操作都必須按順序依次執行，因為各個事物被絕對隔離，數據絕對安全，但處理 業務的吞吐量就會下降，性能也就下降了。當然這種隔離級別很少用到，畢竟很影響整個系統的性能。通常我們會採用其他相對較低的隔離級別，再加上相應併發鎖的機制來控制用戶對數據的訪問量，這樣的做法既 可提高系統的吞吐量又可提高系統的性能，而且在一定程度上保證數據的一致性。

深入理解 Spring 事務原理

壹、事務的基本原理

       Spring事務的本質其實就是資料庫對事務的支持，沒有資料庫的事務支持，spring是無法提供事務功能的。對於純JDBC操作資料庫，想要用到事務，可以按照以下步驟進行：
1、獲取連接 Connection connection = DriverManager.getConnection()
2、開啟事務connection.setAutoCommit(true/false);
3、執行CRUD
4、提交事務/回滾事務 connection.commit() / connection.rollback();
5、關閉連接 connection.close();

使用Spring的事務管理功能後，我們可以不再寫步驟 2 和 4 的代碼，而是由Spirng 自動完成。那麼Spring是如何在我們書寫的 CRUD 之前和之後開啟事務和關閉事務的呢？解決這個問題，也就可以從整體上理解Spring的事務管理實現原理了。下麵簡單地介紹下，註解方式為例子
1、配置文件開啟註解驅動，在相關的類和方法上通過註解@Transactional標識。
2、spring 在啟動的時候會去解析生成相關的bean，這時候會查看擁有相關註解的類和方法，並且為這些類和方法生成代理，並根據@Transaction的相關參數進行相關配置註入，這樣就在代理中為我們把相關的事務處理掉了（開啟正常提交事務，異常回滾事務）。
3、真正的資料庫層的事務提交和回滾是通過binlog或者redo log實現的。

貳、Spring 事務的傳播屬性

       所謂spring事務的傳播屬性，就是定義在存在多個事務同時存在的時候，spring應該如何處理這些事務的行為。這些屬性在TransactionDefinition中定義，具體常量的解釋見下表：
常量名稱常量解釋
PROPAGATION_REQUIRED支持當前事務，如果當前沒有事務，就新建一個事務。這是最常見的選擇，也是 Spring 預設的事務的傳播。
PROPAGATION_REQUIRES_NEW新建事務，如果當前存在事務，把當前事務掛起。新建的事務將和被掛起的事務沒有任何關係，是兩個獨立的事務，外層事務失敗回滾之後，不能回滾內層事務執行的結果，內層事務失敗拋出異常，外層事務捕獲，也可以不處理回滾操作
PROPAGATION_SUPPORTS支持當前事務，如果當前沒有事務，就以非事務方式執行。
PROPAGATION_MANDATORY支持當前事務，如果當前沒有事務，就拋出異常。
PROPAGATION_NOT_SUPPORTED以非事務方式執行操作，如果當前存在事務，就把當前事務掛起。
PROPAGATION_NEVER以非事務方式執行，如果當前存在事務，則拋出異常。
PROPAGATION_NESTED
如果一個活動的事務存在，則運行在一個嵌套的事務中。如果沒有活動事務，則按REQUIRED屬性執行。它使用了一個單獨的事務，這個事務擁有多個可以回滾的保存點。內部事務的回滾不會對外部事務造成影響。它只對DataSourceTransactionManager事務管理器起效。

叄、資料庫隔離級別

       隔離級別隔離級別的值導致的問題
Read-Uncommitted：導致臟讀
Read-Committed：避免臟讀，允許不可重覆讀和幻讀
Repeatable-Read：避免臟讀，不可重覆讀，允許幻讀
Serializable：串列化讀，事務只能一個一個執行，避免了臟讀、不可重覆讀、幻讀。執行效率慢，使用時慎重
臟讀：G事務對數據進行了增刪改，但未提交，H事務可以讀取到未提交的數據。如果G事務這時候回滾了，那麼H事務就讀到了臟數據。
不可重覆讀：J事務中發生了兩次讀操作，第1次讀操作和第2次操作之間，K事務對數據進行了修改，這時候2次讀取的數據是不一致的。
幻讀：M事務對一定範圍的數據進行批量修改，N事務在這個範圍增加1條數據，這時候M事務就會失去對新增數據的修改，那麼M事物再進行讀操作時，發現範圍內還有一條未改，以為 修改有問題，實際是一次視覺欺騙。
小總結：
       隔離級別越高，越能保證數據的完整性和一致性，但是對併發性能的影響也越大。
大多數的資料庫預設隔離級別為 Read Commited，比如 SqlServer、Oracle
少數資料庫預設隔離級別為：Repeatable Read 比如： MySQL InnoDB四、Spring中的隔離級別

肆、常量解釋

ISOLATION_DEFAULT：這是個 PlatfromTransactionManager 預設的隔離級別，使用資料庫預設的事務隔離級別。另外四個與 JDBC 的隔離級別相對應。
ISOLATION_READ_UNCOMMITTED：這是事務最低的隔離級別，它充許另外一個事務可以看到這個事務未提交的數據。這種隔離級別會產生臟讀，不可重覆讀和幻像讀。
ISOLATION_READ_COMMITTED：保證一個事務修改的數據提交後才能被另外一個事務讀取。另外一個事務不能讀取該事務未提交的數據。
ISOLATION_REPEATABLE_READ：這種事務隔離級別可以防止臟讀，不可重覆讀。但是可能出現幻像讀。
ISOLATION_SERIALIZABLE：這是花費最高代價但是最可靠的事務隔離級別。事務被處理為順序執行。

伍、事務的嵌套

       通過上面的理論知識的鋪墊，我們大致知道了資料庫事務和spring事務的一些屬性和特點，接下來我們通過分析一些嵌套事務的場景，來深入理解spring事務傳播的機制。
假設外層事務 Service A 的 Method A() 調用 內層Service B 的 Method B()
PROPAGATION_REQUIRED(spring 預設)
如果ServiceB.methodB() 的事務級別定義為 PROPAGATION_REQUIRED，那麼執行 ServiceA.methodA() 的時候spring已經起了事務，這時調用 ServiceB.methodB()，ServiceB.methodB() 看到自己已經運行在 ServiceA.methodA() 的事務內部，就不再起新的事務。
假如 ServiceB.methodB() 運行的時候發現自己沒有在事務中，他就會為自己分配一個事務。
這樣，在 ServiceA.methodA() 或者在 ServiceB.methodB() 內的任何地方出現異常，事務都會被回滾。
PROPAGATION_REQUIRES_NEW
       比如我們設計 ServiceA.methodA() 的事務級別為 PROPAGATION_REQUIRED，ServiceB.methodB() 的事務級別為 PROPAGATION_REQUIRES_NEW。
那麼當執行到 ServiceB.methodB() 的時候，ServiceA.methodA() 所在的事務就會掛起，ServiceB.methodB() 會起一個新的事務，等待 ServiceB.methodB() 的事務完成以後，它才繼續執行。
他與 PROPAGATION_REQUIRED 的事務區別在於事務的回滾程度了。因為 ServiceB.methodB() 是新起一個事務，那麼就是存在兩個不同的事務。如果 ServiceB.methodB() 已經提交，那麼 ServiceA.methodA() 失敗回滾，ServiceB.methodB() 是不會回滾的。如果 ServiceB.methodB() 失敗回滾，如果他拋出的異常被 ServiceA.methodA() 捕獲，ServiceA.methodA() 事務仍然可能提交(主要看B拋出的異常是不是A會回滾的異常)。
PROPAGATION_SUPPORTS
       假設ServiceB.methodB() 的事務級別為 PROPAGATION_SUPPORTS，那麼當執行到ServiceB.methodB()時，如果發現ServiceA.methodA()已經開啟了一個事務，則加入當前的事務，如果發現ServiceA.methodA()沒有開啟事務，則自己也不開啟事務。這種時候，內部方法的事務性完全依賴於最外層的事務。
PROPAGATION_NESTED
       現在的情況就變得比較複雜了, ServiceB.methodB() 的事務屬性被配置為 PROPAGATION_NESTED, 此時兩者之間又將如何協作呢? ServiceB#methodB 如果 rollback, 那麼內部事務(即 ServiceB#methodB) 將回滾到它執行前的 SavePoint 而外部事務(即 ServiceA#methodA) 可以有以下兩種處理方式:
a、捕獲異常，執行異常分支邏輯
voidmethodA(){ try { ServiceB.methodB(); } catch (SomeException) { // 執行其他業務, 如 ServiceC.methodC(); } }
這種方式也是嵌套事務最有價值的地方, 它起到了分支執行的效果, 如果 ServiceB.methodB 失敗, 那麼執行 ServiceC.methodC(), 而 ServiceB.methodB 已經回滾到它執行之前的 SavePoint, 所以不會產生臟數據(相當於此方法從未執行過), 這種特性可以用在某些特殊的業務中, 而 PROPAGATION_REQUIRED 和 PROPAGATION_REQUIRES_NEW 都沒有辦法做到這一點。
b、 外部事務回滾/提交 代碼不做任何修改, 那麼如果內部事務(ServiceB#methodB) rollback, 那麼首先 ServiceB.methodB 回滾到它執行之前的 SavePoint(在任何情況下都會如此), 外部事務(即 ServiceA#methodA) 將根據具體的配置決定自己是 commit 還是 rollback
另外三種事務傳播屬性基本用不到，在此不做分析。

陸、總結

       對於項目中需要使用到事務的地方，我建議開發者還是使用spring的TransactionCallback介面來實現事務，不要盲目使用spring事務註解，如果一定要使用註解，那麼一定要對spring事務的傳播機制和隔離級別有個詳細的瞭解，否則很可能發生意想不到的效果。
此外以上文章是站在各個角度看待事物的，從初步認知事物到深入理解事物，看不明白的，可以反覆參考。雖自認為很嚴謹了，但若有疏漏之處，還請包涵、指正，謝謝！