全面了解MySql中的事務(wù)
最近一直在做訂單類的項(xiàng)目,使用了事務(wù)。我們的數(shù)據(jù)庫選用的是MySql,存儲引擎選用innoDB,innoDB對事務(wù)有著良好的支持。這篇文章我們一起來扒一扒事務(wù)相關(guān)的知識。
為什么要有事務(wù)?
事務(wù)廣泛的運(yùn)用于訂單系統(tǒng)、銀行系統(tǒng)等多種場景。如果有以下一個(gè)場景:A用戶和B用戶是銀行的儲戶?,F(xiàn)在A要給B轉(zhuǎn)賬500元。那么需要做以下幾件事:
1. 檢查A的賬戶余額>500元;
2. A賬戶扣除500元;
3. B賬戶增加500元;
正常的流程走下來,A賬戶扣了500,B賬戶加了500,皆大歡喜。那如果A賬戶扣了錢之后,系統(tǒng)出故障了呢?A白白損失了500,而B也沒有收到本該屬于他的500。以上的案例中,隱藏著一個(gè)前提條件:A扣錢和B加錢,要么同時(shí)成功,要么同時(shí)失敗。事務(wù)的需求就在于此。
事務(wù)是什么?
與其給事務(wù)定義,不如說一說事務(wù)的特性。眾所周知,事務(wù)需要滿足ACID四個(gè)特性。
1. A(atomicity) 原子性。一個(gè)事務(wù)的執(zhí)行被視為一個(gè)不可分割的最小單元。事務(wù)里面的操作,要么全部成功執(zhí)行,要么全部失敗回滾,不可以只執(zhí)行其中的一部分。
2. C(consistency) 一致性。一個(gè)事務(wù)的執(zhí)行不應(yīng)該破壞數(shù)據(jù)庫的完整性約束。如果上述例子中第2個(gè)操作執(zhí)行后系統(tǒng)崩潰,保證A和B的金錢總計(jì)是不會(huì)變的。
3. I(isolation) 隔離性。通常來說,事務(wù)之間的行為不應(yīng)該互相影響。然而實(shí)際情況中,事務(wù)相互影響的程度受到隔離級別的影響。文章后面會(huì)詳述。
4. D(durability) 持久性。事務(wù)提交之后,需要將提交的事務(wù)持久化到磁盤。即使系統(tǒng)崩潰,提交的數(shù)據(jù)也不應(yīng)該丟失。
事務(wù)的四種隔離級別
前文中提到,事務(wù)的隔離性受到隔離級別的影響。那么事務(wù)的隔離級別是什么呢?事務(wù)的隔離級別可以認(rèn)為是事務(wù)的"自私"程度,它定義了事務(wù)之間的可見性。隔離級別分為以下幾種:
1.READ UNCOMMITTED(未提交讀)。在RU的隔離級別下,事務(wù)A對數(shù)據(jù)做的修改,即使沒有提交,對于事務(wù)B來說也是可見的,這種問題叫臟讀。這是隔離程度較低的一種隔離級別,在實(shí)際運(yùn)用中會(huì)引起很多問題,因此一般不常用。
2.READ COMMITTED(提交讀)。在RC的隔離級別下,不會(huì)出現(xiàn)臟讀的問題。事務(wù)A對數(shù)據(jù)做的修改,提交之后會(huì)對事務(wù)B可見,舉例,事務(wù)B開啟時(shí)讀到數(shù)據(jù)1,接下來事務(wù)A開啟,把這個(gè)數(shù)據(jù)改成2,提交,B再次讀取這個(gè)數(shù)據(jù),會(huì)讀到最新的數(shù)據(jù)2。在RC的隔離級別下,會(huì)出現(xiàn)不可重復(fù)讀的問題。這個(gè)隔離級別是許多數(shù)據(jù)庫的默認(rèn)隔離級別。
3.REPEATABLE READ(可重復(fù)讀)。在RR的隔離級別下,不會(huì)出現(xiàn)不可重復(fù)讀的問題。事務(wù)A對數(shù)據(jù)做的修改,提交之后,對于先于事務(wù)A開啟的事務(wù)是不可見的。舉例,事務(wù)B開啟時(shí)讀到數(shù)據(jù)1,接下來事務(wù)A開啟,把這個(gè)數(shù)據(jù)改成2,提交,B再次讀取這個(gè)數(shù)據(jù),仍然只能讀到1。在RR的隔離級別下,會(huì)出現(xiàn)幻讀的問題?;米x的意思是,當(dāng)某個(gè)事務(wù)在讀取某個(gè)范圍內(nèi)的值的時(shí)候,另外一個(gè)事務(wù)在這個(gè)范圍內(nèi)插入了新記錄,那么之前的事務(wù)再次讀取這個(gè)范圍的值,會(huì)讀取到新插入的數(shù)據(jù)。Mysql默認(rèn)的隔離級別是RR,然而mysql的innoDB引擎間隙鎖成功解決了幻讀的問題。
4.SERIALIZABLE(可串行化)??纱谢亲罡叩母綦x級別。這種隔離級別強(qiáng)制要求所有事物串行執(zhí)行,在這種隔離級別下,讀取的每行數(shù)據(jù)都加鎖,會(huì)導(dǎo)致大量的鎖征用問題,性能最差。
為了幫助理解四種隔離級別,這里舉個(gè)例子。如圖1,事務(wù)A和事務(wù)B先后開啟,并對數(shù)據(jù)1進(jìn)行多次更新。四個(gè)小人在不同的時(shí)刻開啟事務(wù),可能看到數(shù)據(jù)1的哪些值呢?
圖1
第一個(gè)小人,可能讀到1-20之間的任何一個(gè)。因?yàn)槲刺峤蛔x的隔離級別下,其他事務(wù)對數(shù)據(jù)的修改也是對當(dāng)前事務(wù)可見的。第二個(gè)小人可能讀到1,10和20,他只能讀到其他事務(wù)已經(jīng)提交了的數(shù)據(jù)。第三個(gè)小人讀到的數(shù)據(jù)去決于自身事務(wù)開啟的時(shí)間點(diǎn)。在事務(wù)開啟時(shí),讀到的是多少,那么在事務(wù)提交之前讀到的值就是多少。第四個(gè)小人,只有在A end 到B start之間開啟,才有可能讀到數(shù)據(jù),而在事務(wù)A和事務(wù)B執(zhí)行的期間是讀不到數(shù)據(jù)的。因?yàn)榈谒男∪俗x數(shù)據(jù)是需要加鎖的,事務(wù)A和B執(zhí)行期間,會(huì)占用數(shù)據(jù)的寫鎖,導(dǎo)致第四個(gè)小人等待鎖。
圖2羅列了不同隔離級別所面對的問題。
圖2
很顯然,隔離級別越高,它所帶來的資源消耗也就越大(鎖),因此它的并發(fā)性能越低。準(zhǔn)確的說,在可串行化的隔離級別下,是沒有并發(fā)的。
圖3
MySql中的事務(wù)
事務(wù)的實(shí)現(xiàn)是基于數(shù)據(jù)庫的存儲引擎。不同的存儲引擎對事務(wù)的支持程度不一樣。mysql中支持事務(wù)的存儲引擎有innoDB和NDB。innoDB是mysql默認(rèn)的存儲引擎,默認(rèn)的隔離級別是RR,并且在RR的隔離級別下更進(jìn)一步,通過多版本并發(fā)控制(MVCC,Multiversion Concurrency Control )解決不可重復(fù)讀問題,加上間隙鎖(也就是并發(fā)控制)解決幻讀問題。因此innoDB的RR隔離級別其實(shí)實(shí)現(xiàn)了串行化級別的效果,而且保留了比較好的并發(fā)性能。
事務(wù)的隔離性是通過鎖實(shí)現(xiàn),而事務(wù)的原子性、一致性和持久性則是通過事務(wù)日志實(shí)現(xiàn)。說到事務(wù)日志,不得不說的就是redo和undo。
1.redo log
在innoDB的存儲引擎中,事務(wù)日志通過重做(redo)日志和innoDB存儲引擎的日志緩沖(InnoDB Log Buffer)實(shí)現(xiàn)。事務(wù)開啟時(shí),事務(wù)中的操作,都會(huì)先寫入存儲引擎的日志緩沖中,在事務(wù)提交之前,這些緩沖的日志都需要提前刷新到磁盤上持久化,這就是DBA們口中常說的“日志先行”(Write-Ahead Logging)。當(dāng)事務(wù)提交之后,在Buffer Pool中映射的數(shù)據(jù)文件才會(huì)慢慢刷新到磁盤。此時(shí)如果數(shù)據(jù)庫崩潰或者宕機(jī),那么當(dāng)系統(tǒng)重啟進(jìn)行恢復(fù)時(shí),就可以根據(jù)redo log中記錄的日志,把數(shù)據(jù)庫恢復(fù)到崩潰前的一個(gè)狀態(tài)。未完成的事務(wù),可以繼續(xù)提交,也可以選擇回滾,這基于恢復(fù)的策略而定。
在系統(tǒng)啟動(dòng)的時(shí)候,就已經(jīng)為redo log分配了一塊連續(xù)的存儲空間,以順序追加的方式記錄Redo Log,通過順序IO來改善性能。所有的事務(wù)共享redo log的存儲空間,它們的Redo Log按語句的執(zhí)行順序,依次交替的記錄在一起。如下一個(gè)簡單示例:
記錄1:<trx1, insert...>
記錄2:<trx2, delete...>
記錄3:<trx3, update...>
記錄4:<trx1, update...>
記錄5:<trx3, insert...>
2.undo log
undo log主要為事務(wù)的回滾服務(wù)。在事務(wù)執(zhí)行的過程中,除了記錄redo log,還會(huì)記錄一定量的undo log。undo log記錄了數(shù)據(jù)在每個(gè)操作前的狀態(tài),如果事務(wù)執(zhí)行過程中需要回滾,就可以根據(jù)undo log進(jìn)行回滾操作。單個(gè)事務(wù)的回滾,只會(huì)回滾當(dāng)前事務(wù)做的操作,并不會(huì)影響到其他的事務(wù)做的操作。
以下是undo+redo事務(wù)的簡化過程
假設(shè)有2個(gè)數(shù)值,分別為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的任意一步系統(tǒng)宕機(jī),事務(wù)未提交,該事務(wù)就不會(huì)對磁盤上的數(shù)據(jù)做任何影響。如果在8-9之間宕機(jī),恢復(fù)之后可以選擇回滾,也可以選擇繼續(xù)完成事務(wù)提交,因?yàn)榇藭r(shí)redo log已經(jīng)持久化。若在9之后系統(tǒng)宕機(jī),內(nèi)存映射中變更的數(shù)據(jù)還來不及刷回磁盤,那么系統(tǒng)恢復(fù)之后,可以根據(jù)redo log把數(shù)據(jù)刷回磁盤。
所以,redo log其實(shí)保障的是事務(wù)的持久性和一致性,而undo log則保障了事務(wù)的原子性。
分布式事務(wù)
分布式事務(wù)的實(shí)現(xiàn)方式有很多,既可以采用innoDB提供的原生的事務(wù)支持,也可以采用消息隊(duì)列來實(shí)現(xiàn)分布式事務(wù)的最終一致性。這里我們主要聊一下innoDB對分布式事務(wù)的支持。
如圖,mysql的分布式事務(wù)模型。模型中分三塊:應(yīng)用程序(AP)、資源管理器(RM)、事務(wù)管理器(TM)。
應(yīng)用程序定義了事務(wù)的邊界,指定需要做哪些事務(wù);
資源管理器提供了訪問事務(wù)的方法,通常一個(gè)數(shù)據(jù)庫就是一個(gè)資源管理器;
事務(wù)管理器協(xié)調(diào)參與了全局事務(wù)中的各個(gè)事務(wù)。
分布式事務(wù)采用兩段式提交(two-phase commit)的方式。第一階段所有的事務(wù)節(jié)點(diǎn)開始準(zhǔn)備,告訴事務(wù)管理器ready。第二階段事務(wù)管理器告訴每個(gè)節(jié)點(diǎn)是commit還是rollback。如果有一個(gè)節(jié)點(diǎn)失敗,就需要全局的節(jié)點(diǎn)全部rollback,以此保障事務(wù)的原子性。
總結(jié)
什么時(shí)候需要使用事務(wù)呢?我想,只要業(yè)務(wù)中需要滿足ACID的場景,都需要事務(wù)的支持。尤其在訂單系統(tǒng)、銀行系統(tǒng)中,事務(wù)是不可或缺的。這篇文章主要介紹了事務(wù)的特性,以及mysql innoDB對事務(wù)的支持。事務(wù)相關(guān)的知識遠(yuǎn)不止文中所說,本文僅作拋磚引玉,不足之處還望讀者多多見諒。
相關(guān)文章
mysql-8.0.16 winx64的最新安裝教程圖文詳解
最近剛學(xué)習(xí)數(shù)據(jù)庫,首先是了解數(shù)據(jù)庫是什么,數(shù)據(jù)庫、數(shù)據(jù)表的基本操作,這就面臨了一個(gè)問題,mysql的安裝,我這里下載的是64位的,基于Windows的,需要的朋友可以參考下2019-06-06mysql中binlog_format模式與配置詳細(xì)分析
這篇文章主要介紹了mysql中binlog_format模式與配置的相關(guān)內(nèi)容,詳細(xì)介紹了binlog的三種格式與SBR、 RBR 兩種模式各自的優(yōu)缺點(diǎn),需要的朋友可以參考。2017-10-10MySQL問答系列之什么情況下會(huì)用到臨時(shí)表
MySQL在很多情況下都會(huì)用到臨時(shí)表,下面這篇文章主要給大家介紹了關(guān)于MySQL在什么情況下會(huì)用到臨時(shí)表的相關(guān)資料,文中介紹的非常詳細(xì),需要的朋友可以參考借鑒,下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2018-09-09mysql 復(fù)制表結(jié)構(gòu)和數(shù)據(jù)實(shí)例代碼
這篇文章主要介紹了mysql 復(fù)制表結(jié)構(gòu)和數(shù)據(jù)實(shí)例代碼的相關(guān)資料,需要的朋友可以參考下2016-10-10MySQL用truncate命令快速清空一個(gè)數(shù)據(jù)庫中的所有表
這篇文章主要介紹了MySQL用truncate命令快速清空一個(gè)數(shù)據(jù)庫中的所有表,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-11-11淺談mysql數(shù)據(jù)庫中的換行符與textarea中的換行符
下面小編就為大家?guī)硪黄獪\談mysql數(shù)據(jù)庫中的換行符與textarea中的換行符。小編覺得挺不錯(cuò)的,現(xiàn)在就分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2017-01-01mysql雙機(jī)熱備實(shí)現(xiàn)方案【可測試】
雙機(jī)熱備從廣義上講,就是對于重要的服務(wù),使用兩臺服務(wù)器,互相備份,共同執(zhí)行同一服務(wù)。這篇文章主要介紹了mysql雙機(jī)熱備實(shí)現(xiàn)方案,需要的朋友可以參考下2019-10-10