[[410031]]

本文主要探討MySQL InnoDB 引擎下ACID的實現原理，對于諸如什么是事務，隔離級別的含義等知識請看我前面mysql 系列的文章。

ACID

MySQL 作為一個關系型數據庫，以最常見的 InnoDB 引擎來說，是如何保證 ACID 的。

• (Atomicity)原子性：事務是最小的執行單位，不允許分割。原子性確保動作要么全部完成，要么完全不起作用;
• (Consistency)一致性：執行事務前后，數據保持一致;
• (Isolation)隔離性：并發訪問數據庫時，一個事務不被其他事務所干擾。
• (Durability)持久性: 一個事務被提交之后。對數據庫中數據的改變是持久的，即使數據庫發生故障。

隔離性

隔離性主要是 鎖 和 MVCC 實現的。這個也可以看我前面mysql 系列的文章，這里就不在贅述了。

原子性

MySQL的日志有很多種,如二進制日志、錯誤日志、查詢日志、慢查詢日志等,此外InnoDB存儲引擎還提供了兩種事務日志:

redo log(重做日志)和undo log(回滾日志)。其中redo log用于保證事務持久性;

undo log則是事務原子性和隔離性實現的基礎。

undo log ，回滾日志。我們知道隔離性的MVCC就是依靠它來實現的，原子性也是。實現原子性的關鍵，是當事務回滾時能夠撤銷所有已經成功執行的sql語句。

當事務對數據庫進行修改時，InnoDB會生成對應的 undo log;如果事務執行失敗或調用了 rollback，導致事物需要回滾，便可以利用 undo log 中的信息將數據回滾到修改之前的樣子。undo log 屬于邏輯日志，它記錄的是sql執行相關的信息。當發生回滾時，InnoDB 會根據 undo log 的內容做與之前相反的工作：

• 對于每個 insert，回滾時會執行 delete;
• 對于每個 delete，回滾時會執行insert;
• 對于每個 update，回滾時會執行一個相反的 update，把數據改回去。

以update操作為例：當事務執行update時，其生成的undo log中會包含被修改行的主鍵(以便知道修改了哪些行)、修改了哪些列、這些列在修改前后的值等信息，回滾時便可以使用這些信息將數據還原到update之前的狀態。

持久性

上面講到Innnodb有很多 log，持久性靠的是 redo log。

讀數據：會首先從緩沖池中讀取，如果緩沖池中沒有，則從磁盤讀取在放入緩沖池;

寫數據：會首先寫入緩沖池，緩沖池中的數據會定期同步到磁盤中(會產生臟讀);

于是 redo log就派上用場了。

既然redo log也需要存儲，也涉及磁盤IO為啥還用它?

1、redo log 的存儲是順序存儲，而緩存同步是隨機操作。

2、緩存同步是以數據頁為單位的，每次傳輸的數據大小大于redo log。

redo log采用的是WAL(Write-ahead logging，預寫式日志)，所有修改先寫入日志，再更新到Buffer Pool，保證了數據不會因MySQL宕機而丟失，從而滿足了持久性要求。

既然redo log也需要在事務提交時將日志寫入磁盤，為什么它比直接將Buffer Pool中修改的數據寫入磁盤(即刷臟)要快呢?主要有以下兩方面的原因：

1、刷臟是隨機IO，因為每次修改的數據位置隨機，但寫redo log是追加操作，屬于順序IO。

2、刷臟是以數據頁(Page)為單位的，MySQL默認頁大小是16KB，一個Page上一個小修改都要整頁寫入;而redo log中只包含真正需要寫入的部分，無效IO大大減少。

redo log 與binlog的區別:

1、作用不同:redo log是用于crash recovery的，保證MySQL宕機也不會影響持久性;binlog是用于point-in-time recovery的，保證服務器可以基于時間點恢復數據，此外binlog還用于主從復制。

2、層次不同:redo log是InnoDB存儲引擎實現的，而binlog是MySQL的服務器層(可以參考文章前面對MySQL邏輯架構的介紹)實現的，同時支持InnoDB和其他存儲引擎。

3、內容不同:redo log是物理日志，內容基于磁盤的Page;binlog的內容是二進制的，根據binlog_format參數的不同，可能基于sql語句、基于數據本身或者二者的混合。

4、寫入時機不同:binlog在事務提交時寫入;redo log的寫入時機相對多元：

默認刷盤策略：當事務提交時會調用fsync對redo log進行刷盤;修改innodb_flush_log_at_trx_commit參數可以改變該策略，但事務的持久性將無法保證。

其他刷盤時機：如master thread每秒刷盤一次redo log等，這樣的好處是不一定要等到commit時刷盤，commit速度大大加快。

我們看看一條SQL更新語句怎么運行的：

比如：

update t set age=20 where id=1;

持久性肯定和寫有關，MySQL 用到了 WAL 技術，WAL 的全稱是 Write-Ahead Logging，它的關鍵點就是先寫日志，再寫磁盤。

[redo log]

redo log 就是這個日志，當有一條記錄要更新時，InnoDB 引擎就會先把記錄寫到 redo log(并更新內存)，這個時候更新就算完成了。在適當的時候(上文提到的刷盤時機)，將這個操作記錄更新到磁盤里面，redo log 有兩個特點:

大小固定，循環寫

• crash-safe(只要刷入磁盤的數據，都會從 redo log 中抹掉，數據庫重啟后，直接把 redo log 中的數據都恢復至內存就可以了。這就是為什么 redo log 具有 crash-safe 的能力)

對于redo log 是有兩階段的：commit 和 prepare 如果不使用“兩階段提交”，數據庫的狀態就有可能和用它的日志恢復出來的庫的狀態不一致.

[Buffer Pool]

Buffer Pool 中包含了磁盤中部分數據頁的映射，作為訪問數據庫的緩沖：

• 當讀取數據時，會先從Buffer Pool中讀取，如果Buffer Pool中沒有，則從磁盤讀取后放入Buffer Pool;
• 當向數據庫寫入數據時，會首先寫入Buffer Pool，Buffer Pool中修改的數據會定期刷新到磁盤中。

Buffer Pool 的使用大大提高了讀寫數據的效率，但是也帶了新的問題：如果MySQL宕機，而此時 Buffer Pool 中修改的數據還沒有刷新到磁盤，就會導致數據的丟失，事務的持久性無法保證。

所以加入了 redo log。 當數據修改時，除了修改Buffer Pool中的數據，還會在redo log記錄這次操作;

當事務提交時，會調用fsync接口對redo log進行刷盤。

如果MySQL宕機，重啟時可以讀取redo log中的數據，對數據庫進行恢復。

一致性

一致性是事務追求的最終目標，實現一致性的措施包括：

• 保證原子性、持久性和隔離性，如果這些特性無法保證，事務的一致性也無法保證.
• 數據庫本身提供保障，例如不允許向整形列插入字符串值、字符串長度不能超過列的限制等
• 應用層面進行保障，例如如果轉賬操作只扣除轉賬者的余額，而沒有增加接收者的余額，無論數據庫實現的多么完美，也無法保證狀態的一致.

CAP 和ACID中的一致性

CAP 定理中的數據一致性，其實是說分布式系統中的各個節點中對于同一數據的拷貝有著相同的值;而 ACID 中的一致性是指數據庫的規則，如果 schema 中規定了一個值必須是唯一的，那么一致的系統必須確保在所有的操作中，該值都是唯一的，由此來看 CAP 和 ACID 對于一致性的定義有著根本性的區別。

總結

事務的 ACID 四大基本特性是保證數據庫能夠運行的基石，但是完全保證數據庫的 ACID，尤其是隔離性會對性能有比較大影響，在實際的使用中我們也會根據業務的需求對隔離性進行調整，除了隔離性，數據庫的原子性和持久性相信都是比較好理解的特性，前者保證數據庫的事務要么全部執行、要么全部不執行，后者保證了對數據庫的寫入都是持久存儲的、非易失的，而一致性不僅是數據庫對本身數據的完整性的要求，同時也對開發者提出了要求 - 寫出邏輯正確并且合理的事務。

最后，也是最重要的，當別人在講一致性的時候，一定要搞清楚他的上下文。