@[toc] 爲什麼要兩階段提交？一階段提交不行嗎？
小夥伴們知道，MySQL 中的事務是兩階段提交，我們見到的很多分佈式事務也都是兩階段提交的，例如 Seata，那麼爲什麼要兩階段提交呢？一次直接提交了不行嗎？今天我們來聊聊這個話題。
關於分佈式事務 seata，不懂的小夥伴可以參考松哥之前的文章，傳送門：
1. 什麼是兩階段提交
1.1 binlog 與 redolog
binlog
binlog 我們中文一般稱作歸檔日誌，如果大家看過鬆哥之前發的 MySQL 主從搭建，應該對這個日誌有印象，當我們搭建 MySQL 主從的時候就離不開 binlog（傳送門：MySQL8 主從複製踩坑指南）。
binlog 是 MySQL Server 層的日誌，而不是存儲引擎自帶的日誌，它記錄了所有的 DDL 和 DML(不包含數據查詢語句)語句，而且是以事件形式記錄，還包含語句所執行的消耗的時間等，需要注意的是：
- binlog 是一種邏輯日誌，他裏邊所記錄的是一條 SQL 語句的原始邏輯，例如給某一個字段 +1，注意這個區別於 redo log 的物理日誌（在某個數據頁上做了什麼修改）。
- binlog 文件寫滿後，會自動切換到下一個日誌文件繼續寫，而不會覆蓋以前的日誌，這個也區別於 redo log，redo log 是循環寫入的，即後面寫入的可能會覆蓋前面寫入的。
- 一般來說，我們在配置 binlog 的時候，可以指定 binlog 文件的有效期，這樣在到期後，日誌文件會自動刪除，這樣避免佔用較多存儲空間。
根據 MySQL 官方文檔的介紹，開啓 binlog 之後，大概會有 1% 的性能損耗，不過這還是可以接受的，一般來說，binlog 有兩個重要的使用場景：
- MySQL 主從複製時：在主機上開啓 binlog，主機將 binlog 同步給從機，從機通過 binlog 來同步數據，進而實現主機和從機的數據同步。
- MySQL 數據恢復，通過使用 mysqlbinlog 工具再結合 binlog 文件，可以將數據恢復到過去的某一時刻。
redo log
前面我們說的 binlog 是 MySQL 自己提供的，在 MySQL 的 server 層，而 redo log 則不是 MySQL 提供的，是存儲引擎 InnoDB 自己提供的。所以在 MySQL 中就存在兩類日誌 binlog 和 redo log，存在兩類日誌既有歷史原因（InnoDB 最早不是 MySQL 官方存儲引擎）也有技術原因，這個咱們以後再細聊。
我們都知道，事務的四大特性裏面有一個是持久性，即只要事務提交成功，那麼對數據庫做的修改就被永久保存下來了，寫到磁盤中了，怎麼做到的呢？其實我們很容易想到是在每次事務提交的時候，將該事務涉及修改的數據頁全部刷新到磁盤中，一旦寫到磁盤中，就不怕數據丟失了。
但是要是每次都這麼搞，數據庫就不知道慢到哪裏去了！因爲 Innodb 是以頁爲單位進行磁盤交互的，而一個事務很可能只修改一個數據頁裏面的幾個字節，這個時候將完整的數據頁刷到磁盤的話，不僅效率低，也浪費資源。效率低是因爲這些數據頁在物理上並不連續，將數據頁刷到磁盤會涉及到隨機 IO。
有鑑於此，MySQL 設計了 redo log，在 redo log 中只記錄事務對數據頁做了哪些修改。那有人說，寫 redo log 不就是磁盤 IO 嗎？而寫數據到磁盤也是磁盤 IO，既然都是磁盤 IO，那幹嘛不把直接把數據寫到磁盤呢？還費這事！
此言差矣。
寫 redo log 跟寫數據有一個很大的差異，那就是 redo log 是順序 IO，而寫數據涉及到隨機 IO，寫數據需要尋址，找到對應的位置，然後更新/添加/刪除，而寫 redo log 則是在一個固定的位置循環寫入，是順序 IO，所以速度要高於寫數據。
redo log 本身又分爲：
- 日誌緩衝（redo log buffer)，該部分日誌是易失性的。
- 重做日誌(redo log file)，這是磁盤上的日誌文件，該部分日誌是持久的。
MySQL 每執行一條 DML 語句，先將記錄寫入 redo log buffer，後續在某個時間點再一次性將多個操作記錄寫到 redo log file，這種先寫日誌再寫磁盤的技術就是 MySQL 裏經常說到的 WAL(Write-Ahead Logging) 技術（預寫日誌）。
1.2 兩階段提交
在 MySQL 中，兩階段提交的主角就是 binlog 和 redolog，我們來看一個兩階段提交的流程圖：
從上圖中可以看出，在最後提交事務的時候，有 3 個步驟：
- 寫入 redo log，處於 prepare 狀態。
- 寫 binlog。
- 修改 redo log 狀態變爲 commit。
由於 redo log 的提交分爲 prepare 和 commit 兩個階段，所以稱之爲兩階段提交。
2. 爲什麼需要兩階段提交
如果沒有兩階段提交，那麼 binlog 和 redolog 的提交，無非就是兩種形式：
- 先寫 binlog 再寫 redolog。
- 先寫 redolog 再寫 binlog。
這兩種情況我們分別來看。
假設我們要向表中插入一條記錄 R，如果是先寫 binlog 再寫 redolog，那麼假設 binlog 寫完後崩潰了，此時 redolog 還沒寫。那麼重啓恢復的時候就會出問題：binlog 中已經有 R 的記錄了，當從機從主機同步數據的時候或者我們使用 binlog 恢復數據的時候，就會同步到 R 這條記錄；但是 redolog 中沒有關於 R 的記錄，所以崩潰恢復之後，插入 R 記錄的這個事務是無效的，即數據庫中沒有該行記錄，這就造成了數據不一致。
相反，假設我們要向表中插入一條記錄 R，如果是先寫 redolog 再寫 binlog，那麼假設 redolog 寫完後崩潰了，此時 binlog 還沒寫。那麼重啓恢復的時候也會出問題：redolog 中已經有 R 的記錄了，所以崩潰恢復之後，插入 R 記錄的這個事務是有效的，通過該記錄將數據恢復到數據庫中；但是 binlog 中還沒有關於 R 的記錄，所以當從機從主機同步數據的時候或者我們使用 binlog 恢復數據的時候，就不會同步到 R 這條記錄，這就造成了數據不一致。
那麼按照前面說的兩階段提交就能解決問題嗎？
我們來看如下三種情況：
**情況一：**一階段提交之後崩潰了，即寫入 redo log，處於 prepare 狀態 的時候崩潰了，此時：
由於 binlog 還沒寫，redo log 處於 prepare 狀態還沒提交，所以崩潰恢復的時候，這個事務會回滾，此時 binlog 還沒寫，所以也不會傳到備庫。
**情況二：**假設寫完 binlog 之後崩潰了，此時：
redolog 中的日誌是不完整的，處於 prepare 狀態，還沒有提交，那麼恢復的時候，首先檢查 binlog 中的事務是否存在並且完整，如果存在且完整，則直接提交事務，如果不存在或者不完整，則回滾事務。
**情況三：**假設 redolog 處於 commit 狀態的時候崩潰了，那麼重啓後的處理方案同情況二。
由此可見，兩階段提交能夠確保數據的一致性。
3. 小結
好啦，今天和小夥伴們簡單聊了一下 MySQL 中的兩階段提交，有問題歡迎留言討論。