易寫科技事務(wù)是采用的Spring的編程式的事務(wù)，我們x選擇的數(shù)據(jù)庫選是MySql，存儲(chǔ)引擎選用innoDB，innoDB對(duì)事務(wù)有著良好的支持。這篇文章我們?cè)敿?xì)介紹事務(wù)相關(guān)的知識(shí)。

為什么要有事務(wù)？

事務(wù)廣泛的運(yùn)用于訂單系統(tǒng)、銀行系統(tǒng)等多種場(chǎng)景。如果有以下一個(gè)場(chǎng)景：A用戶和B用戶是銀行的儲(chǔ)戶。現(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ù)相互影響的程度受到隔離級(jí)別的影響。文章后面會(huì)詳述。

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

事務(wù)的四種隔離級(jí)別

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

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

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

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

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

為了幫助理解四種隔離級(jí)別，下面這張圖可以解釋一下：

不同隔離級(jí)別所面對(duì)的問題，看下圖：

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

所以說要針對(duì)不同的場(chǎng)景去設(shè)置不同的事務(wù)隔離級(jí)別。下面我們說下Mysql中的事務(wù)。

MySql中的事務(wù)

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

事務(wù)的隔離性是通過鎖實(shí)現(xiàn)，而事務(wù)的原子性、一致性和持久性則是通過事務(wù)日志實(shí)現(xiàn)。說到事務(wù)日志，不得不說的就是redo和undo。

1.redo log

在innoDB的存儲(chǔ)引擎中，事務(wù)日志通過重做(redo)日志和innoDB存儲(chǔ)引擎的日志緩沖(InnoDB Log Buffer)實(shí)現(xiàn)。事務(wù)開啟時(shí)，事務(wù)中的操作，都會(huì)先寫入存儲(chǔ)引擎的日志緩沖中，在事務(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ù)的存儲(chǔ)空間,以順序追加的方式記錄Redo Log,通過順序IO來改善性能。所有的事務(wù)共享redo log的存儲(chǔ)空間，它們的Redo Log按語句的執(zhí)行順序，依次交替的記錄在一起。如下一個(gè)簡(jiǎn)單示例：

記錄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ù)的簡(jiǎn)化過程

假設(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ì)對(duì)磁盤上的數(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對(duì)分布式事務(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ù)的原子性。

一般分布式事務(wù)在互聯(lián)網(wǎng)大的并發(fā)中效率是很低的，尤其是大型的分布式系統(tǒng)的，一些分布式的框架本身就不支持分布式的事務(wù)，比如阿里巴巴的Dubbo，一般用一些異步的消息框架來處理，或者分析日志。當(dāng)然具體還得看業(yè)務(wù)需求，當(dāng)然事務(wù)的知識(shí)遠(yuǎn)不止本文所說，本文僅做拋磚引玉，不如之處還請(qǐng)諒解。

總結(jié)

以上是生活随笔為你收集整理的MySql中的事务详细介绍的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。