來源?| 阿丸筆記

封圖|?CSDN下載于視覺中國

提到MySQL的事務，我相信對MySQL有了解的同學都能聊上幾句，無論是面試求職，還是日常開發，MySQL的事務都跟我們息息相關。

而事務的ACID（即原子性Atomicity、一致性Consistency、隔離性Isolation、持久性Durability）可以說涵蓋了事務的全部知識點，所以，我們不僅要知道ACID是什么，還要了解ACID背后的實現，只有這樣，無論在日常開發還是面試求職，都能無往而不利。

本篇內容將介紹原子性、一致性、持久性相關實現，由于這部分內容可能很多人會相對陌生，因為日常業務開發可能不太會去接觸和深究，但是了解完后，你對MySQL會有更深刻的認識。

基本概念

• 原子性

整個事務是不可分割的最小單位，事務中任何一個語句執行失敗，所有已經執行成功的語句也要回滾，整個數據庫狀態要恢復到執行事務前到狀態。

• 一致性

事務將數據庫從一種狀態轉變為下一種一致的狀態。在事務的前后，數據庫的完整性約束沒有被破壞。（事務的acid不是完全正交的，尤其是一致性，可能跟原子性、隔離性都有一定關系，后面會看到）

• 持久性

事務一旦提交，那么就是永久性的，不會因為宕機等故障導致數據丟失（外力影響不保證，比如磁盤損害）。持久性是保證了數據庫的高可靠性（High Reliability），而不是高可用性(Hign Availability)。高可用性并不能通過事務來保證。

持久性的實現

MySQL的innoDB存儲引擎，使用Redo log保證了事務的持久性。

當事務提交時，必須先將事務的所有日志寫入日志文件進行持久化，就是我們常說的WAL（write ahead log）機制（這個技術是保障持久性的關鍵技術，在HBase中也扮演重要角色，有興趣的同學可以參考我之前的HBase文章）。這樣才能保證斷電或宕機等情況發生后，已提交的事務不會丟失，這個能力稱為 crash-safe。

下面深入聊一聊redo log的機制，給大家更深刻的理解。

Redo log包括兩部分，重做日志緩沖（redo log buffer）和重做日志文件（redo log file），前者是易失的緩存，后者是持久化的文件。

舉一個事務的例子：

• 步驟1:begin;

• 步驟2:insert into t1 …r

• 步驟3:insert into t2 …

• 步驟4:commit;

這個事務的寫入過程實際拆解如下：

innodb緩沖池的概念本文就不展開說明了，以后有機會可以展開說一下。

重點關注在這個事務提交前，將 redo log 的寫入拆成了兩個步驟，prepare 和 commit，這就是"兩階段提交”。

為什么要采用兩階段提交呢？

實際上，兩階段提交是分布式系統常用的機制。MySQL使用了兩階段提交后，也是為了保證事務的持久性。Redo log 和bingo 有一個共同的數據字段，叫 XID,崩潰恢復的時候，會按順序掃描 redo log。

• 假設在寫入binlog前系統崩潰，那么數據庫恢復后順序掃描 redo log，碰到只有 parepare、而沒有 commit 的 redo log，就拿著 XID 去 binlog 找對應的事務，而且binlog也沒寫入，所以事務就直接回滾了。

• 假設在寫入binlog之后，事務提交前數據庫崩潰，那么數據庫恢復后順序掃描 redo log，碰到既有 prepare、又有 commit 的 redo log，就直接提交，保證數據不丟失。

這個事務要往兩個表中插入記錄，插入數據的過程中，生成的日志都得先寫入redo log buffer ，等到commit的時候，才真正把日志寫到 redo log 文件。（當然，這里不絕對，因為redo log buffer可能因為其他原因被迫刷新到redo log）。

而為了確保每次日志都能寫入日志文件，在每次將重做日志緩沖 寫入 重做日志文件 后，InnoDB存儲引擎都需要調用一次fsync操作，確保寫入了磁盤。

對于redo log的持久化，可以如下圖所示。

1）先寫入redo log buffer，在藍色區域。

2）寫入redo log file，但是還沒有fsync，這時候是處于黃色的位置，處于系統緩存。

3）調用fsync，真正寫入磁盤。

為了控制 redo log 的寫入策略，InnoDB 提供了 innodb_flush_log_at_trx_commit 參數，它有三種可能取值：

• 設置為 0 的時候，表示每次事務提交時都只是把 redo log 留在 redo log buffer 中 ;

• 設置為 1 的時候，表示每次事務提交時都將 redo log 直接持久化到磁盤；

• 設置為 2 的時候，表示每次事務提交時都只是把 redo log 寫到 page cache。

binlog的寫入和redo log一樣，也是包括bingo cache和bingo file，同樣跟上面的三色層次類似（當然，binlog是server層的，不是存儲引擎層的），包括log buffer、文件系統page cache、hard disk。

寫入page cache 和 fsync到disk 的時機，是由參數 sync_binlog 控制的：

• sync_binlog=0 的時候，表示每次提交事務都只 寫入文件系統的page cache，不 fsync；

• sync_binlog=1 的時候，表示每次提交事務都會執行 fsync；

• sync_binlog=N(N>1) 的時候，表示每次提交事務都寫入文件系統的page cache，但累積 N 個事務后才 fsync。（如果主機發生異常重啟，會丟失最近 N 個事務的 binlog 日志）

通常我們說 MySQL 的“雙 1”配置，指的就是 sync_binlog 和 innodb_flush_log_at_trx_commit 都設置成 1。也就是說，一個事務完整提交前，需要等待兩次刷盤，一次是 redo log（prepare 階段），一次是 binlog。

特別需要區分的是，redo log和binlog的不同。這也是經常在面試中可能會問到的兩種日志的差異。

注意有這么幾點不同：

• 產生位置不同。

redo log是innodb的存儲引擎產生的，而binlog是數據庫的server層實現的。換句話說，如果你使用MySQL，換其他存儲引擎，那么可能沒有redo log，但是還是會有binlog。

• 日志記錄的內容形式不同。

binlog是一種邏輯日志，記錄對應的SQL語句，而redo log記錄了物理日志，是針對每個數據頁的修改。

• 日志寫入時間不同。

binlog只有在事務提交后完成一次寫入，對于一個事物而言，在binlog中只有一條記錄。而redo log在事務進行中不斷被寫入，而且是并發寫入的，不是順序寫入的。

• 保存方式不同。

redo log 是循環寫的，空間固定會用完；binlog 是可以追加寫入的。“追加寫”是指 binlog 文件寫到一定大小后會切換到下一個，并不會覆蓋以前的日志。

原子性的實現

Undo log保證了事務的原子性。

在對數據庫進行修改時，innoDB引擎除了會產生redo log，還會產生undo log。InnoDB實現回滾，靠的是undo log：當事務對數據庫進行修改時，InnoDB會生成對應的undo log；如果事務執行失敗導致事務需要回滾，就利用undo log中的信息將數據回滾到修改之前的樣子。

有人認為undo log是redo log的逆過程，其實是不對的。兩個日志文件其實都能看作是一種對數據的恢復操作，redo log恢復事務導致的數據頁的修改，而undo log能夠恢復數據記錄到某個特定的版本。

所以redo log是一種物理日志（數據頁的修改），而undo log是一種邏輯日志（數據記錄）。

undo log還要另外一個重要作用，就是用于mvcc中，進行多版本控制，也就是實現事務隔離性的基礎，當用戶讀取一行記錄時，如果這個記錄已接被其他事務占用，那么當前事務就可以通過undo讀取之前的行版本信息，用來實現非鎖定讀取，就是“快照讀”。（事務隔離性的問題，可以看我上一篇文章?跟面試官侃半小時MySQL事務隔離性，從基本概念深入到實現?）。

一致性的實現

就像一開始在定義的時候介紹的，事務的ACID性質不是完全正交的，尤其是一致性，我們可以認為原子性、持久性和隔離性都是為了實現事務的一致性。

當然，這里的一致性是指數據庫層面的事務一致性。

如果說你在應用層面做一個操作，給轉賬者扣錢，沒給接收者加錢，那么這個不一致跟事務的不一致是沒有關系的，需要開發人員自己做業務邏輯一致性的保證。

同時，歡迎所有開發者掃描下方二維碼填寫《開發者與AI大調研》，只需2分鐘，便可收獲價值299元的「AI開發者萬人大會」在線直播門票!

推薦閱讀：你公司的虛擬機還閑著？基于 Jenkins 和 Kubernetes 的持續集成測試實踐了解一下！ 北京四環堵車引發的智能交通大構想 400 多行代碼！超詳細中文聊天機器人開發指南 | 原力計劃 三大運營商將上線 5G 消息；蘋果谷歌聯手，追蹤 30 億用戶；jQuery 3.5.0 發布 | 極客頭條比特幣當贖金，WannaRen 勒索病毒二度來襲！從 Web 1.0到Web 3.0：詳析這些年互聯網的發展及未來方向真香，朕在看了！

總結

以上是生活随笔為你收集整理的跟面试官侃了半小时 MySQL 事务，把原子性、一致性、持久性的实现都讲完了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。