最近一直在做訂單類的項目，使用了事務。我們的數據庫選用的是MySql，存儲引擎選用innoDB，innoDB對事務有著良好的支持。這篇文章我們一起來扒一扒事務相關的知識。

為什么要有事務？

事務廣泛的運用于訂單系統、銀行系統等多種場景。如果有以下一個場景：A用戶和B用戶是銀行的儲戶。現在A要給B轉賬500元。那么需要做以下幾件事：

1. 檢查A的賬戶余額>500元；

2. A賬戶扣除500元；

3. B賬戶增加500元；

正常的流程走下來，A賬戶扣了500，B賬戶加了500，皆大歡喜。那如果A賬戶扣了錢之后，系統出故障了呢？A白白損失了500，而B也沒有收到本該屬于他的500。以上的案例中，隱藏著一個前提條件：A扣錢和B加錢，要么同時成功，要么同時失敗。事務的需求就在于此。

事務是什么？

與其給事務定義，不如說一說事務的特性。眾所周知，事務需要滿足ACID四個特性。

1. A(atomicity) 原子性。一個事務的執行被視為一個不可分割的最小單元。事務里面的操作，要么全部成功執行，要么全部失敗回滾，不可以只執行其中的一部分。

2. C(consistency) 一致性。一個事務的執行不應該破壞數據庫的完整性約束。如果上述例子中第2個操作執行后系統崩潰，保證A和B的金錢總計是不會變的。

3. I(isolation) 隔離性。通常來說，事務之間的行為不應該互相影響。然而實際情況中，事務相互影響的程度受到隔離級別的影響。文章后面會詳述。

4. D(durability) 持久性。事務提交之后，需要將提交的事務持久化到磁盤。即使系統崩潰，提交的數據也不應該丟失。

事務的四種隔離級別

前文中提到，事務的隔離性受到隔離級別的影響。那么事務的隔離級別是什么呢？事務的隔離級別可以認為是事務的"自私"程度，它定義了事務之間的可見性。隔離級別分為以下幾種：

1.READ UNCOMMITTED(未提交讀)。在RU的隔離級別下，事務A對數據做的修改，即使沒有提交，對于事務B來說也是可見的，這種問題叫臟讀。這是隔離程度較低的一種隔離級別，在實際運用中會引起很多問題，因此一般不常用。

2.READ COMMITTED(提交讀)。在RC的隔離級別下，不會出現臟讀的問題。事務A對數據做的修改，提交之后會對事務B可見，舉例，事務B開啟時讀到數據1，接下來事務A開啟，把這個數據改成2，提交，B再次讀取這個數據，會讀到最新的數據2。在RC的隔離級別下，會出現不可重復讀的問題。這個隔離級別是許多數據庫的默認隔離級別。

3.REPEATABLE READ(可重復讀)。在RR的隔離級別下，不會出現不可重復讀的問題。事務A對數據做的修改，提交之后，對于先于事務A開啟的事務是不可見的。舉例，事務B開啟時讀到數據1，接下來事務A開啟，把這個數據改成2，提交，B再次讀取這個數據，仍然只能讀到1。在RR的隔離級別下，會出現幻讀的問題�；米x的意思是，當某個事務在讀取某個范圍內的值的時候，另外一個事務在這個范圍內插入了新記錄，那么之前的事務再次讀取這個范圍的值，會讀取到新插入的數據。Mysql默認的隔離級別是RR，然而mysql的innoDB引擎間隙鎖成功解決了幻讀的問題。

4.SERIALIZABLE(可串行化)。可串行化是最高的隔離級別。這種隔離級別強制要求所有事物串行執行，在這種隔離級別下，讀取的每行數據都加鎖，會導致大量的鎖征用問題，性能最差。

為了幫助理解四種隔離級別，這里舉個例子。如圖1，事務A和事務B先后開啟，并對數據1進行多次更新。四個小人在不同的時刻開啟事務，可能看到數據1的哪些值呢？



圖1

第一個小人，可能讀到1-20之間的任何一個。因為未提交讀的隔離級別下，其他事務對數據的修改也是對當前事務可見的。第二個小人可能讀到1，10和20，他只能讀到其他事務已經提交了的數據。第三個小人讀到的數據去決于自身事務開啟的時間點。在事務開啟時，讀到的是多少，那么在事務提交之前讀到的值就是多少。第四個小人，只有在A end 到B start之間開啟，才有可能讀到數據，而在事務A和事務B執行的期間是讀不到數據的。因為第四小人讀數據是需要加鎖的，事務A和B執行期間，會占用數據的寫鎖，導致第四個小人等待鎖。

圖2羅列了不同隔離級別所面對的問題。



圖2

很顯然，隔離級別越高，它所帶來的資源消耗也就越大(鎖)，因此它的并發性能越低。準確的說，在可串行化的隔離級別下，是沒有并發的。



圖3

MySql中的事務

事務的實現是基于數據庫的存儲引擎。不同的存儲引擎對事務的支持程度不一樣。mysql中支持事務的存儲引擎有innoDB和NDB。innoDB是mysql默認的存儲引擎，默認的隔離級別是RR，并且在RR的隔離級別下更進一步，通過多版本并發控制（MVCC，Multiversion Concurrency Control ）解決不可重復讀問題，加上間隙鎖（也就是并發控制）解決幻讀問題。因此innoDB的RR隔離級別其實實現了串行化級別的效果，而且保留了比較好的并發性能。

事務的隔離性是通過鎖實現，而事務的原子性、一致性和持久性則是通過事務日志實現。說到事務日志，不得不說的就是redo和undo。

1.redo log

在innoDB的存儲引擎中，事務日志通過重做(redo)日志和innoDB存儲引擎的日志緩沖(InnoDB Log Buffer)實現。事務開啟時，事務中的操作，都會先寫入存儲引擎的日志緩沖中，在事務提交之前，這些緩沖的日志都需要提前刷新到磁盤上持久化，這就是DBA們口中常說的“日志先行”(Write-Ahead Logging)。當事務提交之后，在Buffer Pool中映射的數據文件才會慢慢刷新到磁盤。此時如果數據庫崩潰或者宕機，那么當系統重啟進行恢復時，就可以根據redo log中記錄的日志，把數據庫恢復到崩潰前的一個狀態。未完成的事務，可以繼續提交，也可以選擇回滾，這基于恢復的策略而定。

在系統啟動的時候，就已經為redo log分配了一塊連續的存儲空間,以順序追加的方式記錄Redo Log,通過順序IO來改善性能。所有的事務共享redo log的存儲空間，它們的Redo Log按語句的執行順序，依次交替的記錄在一起。如下一個簡單示例：

記錄1：<trx1, insert...>

記錄2：<trx2, delete...>

記錄3：<trx3, update...>

記錄4：<trx1, update...>

記錄5：<trx3, insert...>

2.undo log

undo log主要為事務的回滾服務。在事務執行的過程中，除了記錄redo log，還會記錄一定量的undo log。undo log記錄了數據在每個操作前的狀態，如果事務執行過程中需要回滾，就可以根據undo log進行回滾操作。單個事務的回滾，只會回滾當前事務做的操作，并不會影響到其他的事務做的操作。

以下是undo+redo事務的簡化過程

假設有2個數值，分別為A和B,值為1，2

1. start transaction;

2. 記錄 A=1 到undo log;

3. update A = 3；

4. 記錄 A=3 到redo log；

5. 記錄 B=2 到undo log；

6. update B = 4；

7. 記錄B = 4 到redo log；

8. 將redo log刷新到磁盤

9. commit

在1-8的任意一步系統宕機，事務未提交，該事務就不會對磁盤上的數據做任何影響。如果在8-9之間宕機，恢復之后可以選擇回滾，也可以選擇繼續完成事務提交，因為此時redo log已經持久化。若在9之后系統宕機，內存映射中變更的數據還來不及刷回磁盤，那么系統恢復之后，可以根據redo log把數據刷回磁盤。

所以，redo log其實保障的是事務的持久性和一致性，而undo log則保障了事務的原子性。

分布式事務

分布式事務的實現方式有很多，既可以采用innoDB提供的原生的事務支持，也可以采用消息隊列來實現分布式事務的最終一致性。這里我們主要聊一下innoDB對分布式事務的支持。



如圖，mysql的分布式事務模型。模型中分三塊：應用程序（AP）、資源管理器（RM）、事務管理器（TM）。

應用程序定義了事務的邊界，指定需要做哪些事務；

資源管理器提供了訪問事務的方法，通常一個數據庫就是一個資源管理器；

事務管理器協調參與了全局事務中的各個事務。

分布式事務采用兩段式提交（two-phase commit）的方式。第一階段所有的事務節點開始準備，告訴事務管理器ready。第二階段事務管理器告訴每個節點是commit還是rollback。如果有一個節點失敗，就需要全局的節點全部rollback，以此保障事務的原子性。

總結

什么時候需要使用事務呢？我想，只要業務中需要滿足ACID的場景，都需要事務的支持。尤其在訂單系統、銀行系統中，事務是不可或缺的。這篇文章主要介紹了事務的特性，以及mysql innoDB對事務的支持。事務相關的知識遠不止文中所說，本文僅作拋磚引玉，不足之處還望讀者多多見諒。

以上就是圖文詳解MySql中的事務的詳細內容，更多請關注php中文網其它相關文章！