《Mysql應用全面了解MySql中的事務》要點：
本文介紹了Mysql應用全面了解MySql中的事務，希望對您有用。如果有疑問，可以聯系我們。

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

為什么要有事務?MYSQL應用

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

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

2. A賬戶扣除500元；MYSQL應用

3. B賬戶增加500元；MYSQL應用

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

事務是什么?MYSQL應用

與其給事務定義,不如說一說事務的特性.眾所周知,事務需要滿足ACID四個特性.MYSQL應用

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

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

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

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

事務的四種隔離級別MYSQL應用

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

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

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

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

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

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

MYSQL應用

圖1MYSQL應用

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

圖2羅列了不同隔離級別所面對的問題.MYSQL應用

MYSQL應用

圖2MYSQL應用

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

MYSQL應用

圖3MYSQL應用

MySql中的事務MYSQL應用

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

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

1.redo logMYSQL應用

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

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

記錄1：<trx1, insert...>MYSQL應用

記錄2：<trx2, delete...>MYSQL應用

記錄3：<trx3, update...>MYSQL應用

記錄4：<trx1, update...>MYSQL應用

記錄5：<trx3, insert...>MYSQL應用

2.undo logMYSQL應用

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

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

假設有2個數值,分別為A和B,值為1,2MYSQL應用

1. start transaction;MYSQL應用

2. 記錄 A=1 到undo log;MYSQL應用

3. update A = 3；MYSQL應用

4. 記錄 A=3 到redo log；MYSQL應用

5. 記錄 B=2 到undo log；MYSQL應用

6. update B = 4；MYSQL應用

7. 記錄B = 4 到redo log；MYSQL應用

8. 將redo log刷新到磁盤MYSQL應用

9. commitMYSQL應用

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

所以,redo log其實保障的是事務的持久性和一致性,而undo log則保障了事務的原子性.MYSQL應用

分布式事務MYSQL應用

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

MYSQL應用

如圖,mysql的分布式事務模型.模型中分三塊：應用程序(AP)、資源管理器(RM)、事務管理器(TM).MYSQL應用

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

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

事務管理器協調參與了全局事務中的各個事務.MYSQL應用

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

總結 MYSQL應用

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

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/2132.html