歡迎光臨
每天分享高質量文章

程式員,知道MySQL中事務ACID的原理嗎?

來自:孤獨煙(微信號:zrj_guduyan)

引言

照例,我們先來一個場景~

面試官:”知道事務的四大特性麽?”
你:”懂,ACID嘛,原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability)!”
面試官:“你們是用mysql資料庫吧,能簡單說說innodb中怎麼實現這四大特性的麽?”
你:”我只知道隔離性是怎麼做的balabala~~”
面試官:”還是回去等通知吧~”

OK,回到正題。說到事務的四大特性原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability),懂的人很多。但是稍微涉及細節一點,這四大特性在資料庫中的實現原理是怎麼樣的?那就沒有幾個人能夠答得上來了。因此,我們這篇文章著重討論一下四大特性在Mysql中的實現原理。

正文

我們以從A賬戶轉賬50元到B賬戶為例進行說明一下ACID,四大特性。

原子性

根據定義,原子性是指一個事務是一個不可分割的工作單位,其中的操作要麼都做,要麼都不做。即要麼轉賬成功,要麼轉賬失敗,是不存在中間的狀態!
如果無法保證原子性會怎麼樣?
OK,就會出現資料不一致的情形,A賬戶減去50元,而B賬戶增加50元操作失敗。系統將無故丟失50元~

隔離性

根據定義,隔離性是指多個事務併發執行的時候,事務內部的操作與其他事務是隔離的,併發執行的各個事務之間不能互相干擾。
如果無法保證隔離性會怎麼樣?
OK,假設A賬戶有200元,B賬戶0元。A賬戶往B賬戶轉賬兩次,金額為50元,分別在兩個事務中執行。如果無法保證隔離性,會出現下麵的情形

如圖所示,如果不保證隔離性,A扣款兩次,而B只加款一次,憑空消失了50元,依然出現了資料不一致的情形!

ps:可能有細心的讀者已經發現了,mysql中是依靠鎖來解決隔離性問題。嗯,我們後面來說明。

持久性

根據定義,持久性是指事務一旦提交,它對資料庫的改變就應該是永久性的。接下來的其他操作或故障不應該對其有任何影響。

如果無法保證持久性會怎麼樣?
在Mysql中,為瞭解決CPU和磁盤速度不一致問題,Mysql是將磁盤上的資料加載到記憶體,對記憶體進行操作,然後再回寫磁盤。好,假設此時宕機了,在記憶體中修改的資料全部丟失了,持久性就無法保證。

設想一下,系統提示你轉賬成功。但是你發現金額沒有發生任何改變,此時資料出現了不合法的資料狀態,我們將這種狀態認為是資料不一致的情形。

一致性

根據定義,一致性是指事務執行前後,資料處於一種合法的狀態,這種狀態是語意上的而不是語法上的。
那什麼是合法的資料狀態呢?
oK,這個狀態是滿足預定的約束就叫做合法的狀態,再通俗一點,這狀態是由你自己來定義的。滿足這個狀態,資料就是一致的,不滿足這個狀態,資料就是不一致的!

如果無法保證一致性會怎麼樣?
例一:A賬戶有200元,轉賬300元出去,此時A賬戶餘額為-100元。你自然就發現了此時資料是不一致的,為什麼呢?因為你定義了一個狀態,餘額這列必須大於0。
例二:A賬戶200元,轉賬50元給B賬戶,A賬戶的錢扣了,但是B賬戶因為各種意外,餘額並沒有增加。你也知道此時資料是不一致的,為什麼呢?因為你定義了一個狀態,要求A+B的餘額必須不變。

實戰解答

問題一:Mysql怎麼保證一致性的?
OK,這個問題分為兩個層面來說。
從資料庫層面,資料庫通過原子性、隔離性、持久性來保證一致性。也就是說ACID四大特性之中,C(一致性)是目的,A(原子性)、I(隔離性)、D(持久性)是手段,是為了保證一致性,資料庫提供的手段。資料庫必須要實現AID三大特性,才有可能實現一致性。例如,原子性無法保證,顯然一致性也無法保證。

但是,如果你在事務里故意寫出違反約束的代碼,一致性還是無法保證的。例如,你在轉賬的例子中,你的代碼里故意不給B賬戶加錢,那一致性還是無法保證。因此,還必須從應用層角度考慮。

從應用層面,通過代碼判斷資料庫資料是否有效,然後決定回滾還是提交資料!

問題二: Mysql怎麼保證原子性的?
OK,是利用Innodb的undo log
undo log名為回滾日誌,是實現原子性的關鍵,當事務回滾時能夠撤銷所有已經成功執行的sql陳述句,他需要記錄你要回滾的相應日誌信息。
例如

  • (1)當你delete一條資料的時候,就需要記錄這條資料的信息,回滾的時候,insert這條舊資料

  • (2)當你update一條資料的時候,就需要記錄之前的舊值,回滾的時候,根據舊值執行update操作

  • (3)當年insert一條資料的時候,就需要這條記錄的主鍵,回滾的時候,根據主鍵執行delete操作

undo log記錄了這些回滾需要的信息,當事務執行失敗或呼叫了rollback,導致事務需要回滾,便可以利用undo log中的信息將資料回滾到修改之前的樣子。

ps:具體的undo log日誌長啥樣,這個可以寫一篇文章了。而且寫出來,看的人也不多,姑且先這麼簡單的理解吧。

問題三: Mysql怎麼保證持久性的?
OK,是利用Innodb的redo log
正如之前說的,Mysql是先把磁盤上的資料加載到記憶體中,在記憶體中對資料進行修改,再刷回磁盤上。如果此時突然宕機,記憶體中的資料就會丟失。
怎麼解決這個問題?
簡單啊,事務提交前直接把資料寫入磁盤就行啊。
這麼做有什麼問題?

  • 只修改一個頁面里的一個位元組,就要將整個頁面刷入磁盤,太浪費資源了。畢竟一個頁面16kb大小,你只改其中一點點東西,就要將16kb的內容刷入磁盤,聽著也不合理。

  • 畢竟一個事務里的SQL可能牽涉到多個資料頁的修改,而這些資料頁可能不是相鄰的,也就是屬於隨機IO。顯然操作隨機IO,速度會比較慢。

於是,決定採用redo log解決上面的問題。當做資料修改的時候,不僅在記憶體中操作,還會在redo log中記錄這次操作。當事務提交的時候,會將redo log日誌進行刷盤(redo log一部分在記憶體中,一部分在磁盤上)。當資料庫宕機重啟的時候,會將redo log中的內容恢復到資料庫中,再根據undo logbinlog內容決定回滾資料還是提交資料。

採用redo log的好處?
其實好處就是將redo log進行刷盤比對資料頁刷盤效率高,具體表現如下

  • redo log體積小,畢竟只記錄了哪一頁修改了啥,因此體積小,刷盤快。

  • redo log是一直往末尾進行追加,屬於順序IO。效率顯然比隨機IO來的快。

ps:不想具體去談redo log具體長什麼樣,因為內容太多了。

問題四: Mysql怎麼保證隔離性的?
OK,利用的是鎖和MVCC機制。還是拿轉賬例子來說明,有一個賬戶表如下
表名t_balance

其中id是主鍵,user_id為賬戶名,balance為餘額。還是以轉賬兩次為例,如下圖所示

至於MVCC,即多版本併發控制(Multi Version Concurrency Control),一個行記錄資料有多個版本對快照資料,這些快照資料在undo log中。

如果一個事務讀取的行正在做DELELE或者UPDATE操作,讀取操作不會等行上的鎖釋放,而是讀取該行的快照版本。
由於MVCC機制在可重覆讀(Repeateable Read)和讀已提交(Read Commited)的MVCC表現形式不同,就不贅述了。
但是有一點說明一下,在事務隔離級別為讀已提交(Read Commited)時,一個事務能夠讀到另一個事務已經提交的資料,是不滿足隔離性的。但是當事務隔離級別為可重覆讀(Repeateable Read)中,是滿足隔離性的。

總結

本文講了Mysql中事務ACID四大特性的實現原理,希望大家有所收穫。

已同步到看一看
赞(0)

分享創造快樂