前段時間我在準備暑期實習嘛，這是當時面攜程的時候二面的一道問題，我一臉懵逼，趕緊道歉，不好意思不知道沒了解過，面試官又解釋說 redo log，我尋思著 redo log 我知道啊，WAL 是啥？給面試官整無語了（滑稽），為我當時的無知道歉。後來回去百度了一下才知道，最近又在丁奇大佬的《MySQL 實戰 45 講》 中看到了 WAL，遂來寫篇文章總結下。
InnoDB 體系架構
在說 WAL 之前，有必要簡單介紹下 InnoDB 儲存引擎的體系架構，方便我們理解下文，並且 redo log 也是 InnoDB 儲存引擎所特有的。
如下圖，InnoDB 儲存引擎由記憶體池和一些後臺執行緒組成：
記憶體池
先來解釋下記憶體池。
首先，我們需要知道，InnoDB 儲存引擎是基於磁碟儲存的，並將其中的記錄按照頁的方式進行管理。因此可將其視為基於磁碟的資料庫系統（Disk-base Database），在這樣的系統中，眾所周知，由於 CPU 速度與磁碟速度之間的不匹配，通常會使用緩衝池技術來提高資料庫的整體效能。
所以這裡的記憶體池也被稱為緩衝池（簡單理解為快取就好了）。
具體來說，緩衝池其實就是一塊記憶體區域，在 CPU 與磁碟之間加入記憶體訪問，通過記憶體的速度來彌補磁碟速度較慢對資料庫效能的影響。
擁有了緩衝池後，“讀取頁” 操作的具體步驟就是這樣的：
- 首先將從磁碟讀到的頁存放在緩衝池中
- 下一次再讀相同的頁時，首先判斷該頁是否在緩衝池中。若在緩衝池中，稱該頁在緩衝池中被命中，直接讀取該頁。否則，讀取磁碟上的頁。
“修改頁” 操作的具體步驟就是這樣的：
- 首先修改在緩衝池中的頁；然後再以一定的頻率重新整理到磁碟上。
所謂 ”髒頁“ 就發生在修改這個操作中，如果緩衝池中的頁已經被修改了，但是還沒有重新整理到磁碟上，那麼我們就稱緩衝池中的這頁是 ”髒頁“，即緩衝池中的頁的版本要比磁碟的新。
至此，綜上所述，我們可以得出這樣的結論：緩衝池的大小直接影響著資料庫的整體效能。
後臺執行緒
後臺執行緒其實最大的作用就是用來完成 “將從磁碟讀到的頁存放在緩衝池中” 以及 “將緩衝池中的資料以一定的頻率重新整理到磁碟上” 這倆個操作的，當然了，還有其他的作用。以下是《MySQL 技術內幕：InnoDB 儲存引擎 - 第 2 版》對於後臺執行緒的描述：
後臺執行緒的主要作用就是重新整理記憶體池中的資料，保證記憶體池中快取的是最近的資料；此外將已修改的資料檔案重新整理到磁碟檔案，同時保證在資料庫發生異常的情況下 InnoDB 能恢復到正常執行狀態。
另外，InnoDB 儲存引擎是多執行緒的模型，也就是說它擁有多個不同的後臺執行緒，負責處理不同的任務。這裡簡單列舉下幾種不同的後臺執行緒：
- Master Thread：主要負責將緩衝池中的資料非同步重新整理到磁碟，保證資料的一致性
- IO Thread：在 InnoDB 儲存引擎中大量使用了 AIO（Async IO）來處理寫 IO 請求，這樣可以極大提高資料庫的效能。IO Thread 的工作主要是負責這些 IO 請求的回撥（call back）處理
- Purge Thread：回收已經使用並分配的 undo 頁
- Page Cleaner Thread：將之前版本中髒頁的重新整理操作都放入到單獨的執行緒中來完成。其目的是為了減輕原 Master Thread 的工作及對於使用者查詢執行緒的阻塞，進一步提高 InnoDB 儲存引擎的效能
redo log 與 WAL 策略
上文我們提到，當緩衝池中的某頁資料被修改後，該頁就被標記為 ”髒頁“，髒頁的資料會被定期重新整理到磁碟上。
倘若每次一個頁發生變化，就將新頁的版本重新整理到磁碟，那麼這個開銷是非常大的。並且，如果熱點資料都集中在某幾個頁中，那麼資料庫的效能將變得非常差。另外，如果在從緩衝池將頁的新版本重新整理到磁碟時發生了當機，那麼這個資料就不能恢復了。
所以，為了避免發生資料丟失的問題，當前事務資料庫系統（並非 MySQL 所獨有）普遍都採用了 WAL（Write Ahead Log，預寫日誌）策略：即當事務提交時，先寫重做日誌（redo log），再修改頁（先修改緩衝池，再重新整理到磁碟）；當由於發生當機而導致資料丟失時，通過 redo log 來完成資料的恢復。這也是事務 ACID 中 D（Durability 永續性）的要求。
有了 redo log，InnoDB 就可以保證即使資料庫發生異常重啟，之前提交的記錄都不會丟失，這個能力稱為 crash-safe。
舉個簡單的例子，假設你非常熱心且 rich 的，借出去了很多錢，但是你非常 old school，不會使用電子裝置並且記性不太好，所以你用一個小本本記下了所有欠你錢的人的名字和具體金額。這樣，別人還你錢的時候，你就翻出你的小本本，一頁頁地找到他的名字然後把這次還的錢扣除掉。
但是呢，其實你平常是非常忙碌的，沒辦法隨時隨地翻小本本做記錄，因此你就想出了一個主意：每當有人還你錢的時候，你就在一張白紙上記下來，然後挑個時間對照小本本把白紙上的賬目都給清了。
這就是 WAL。白紙就是 redo log，小本本就是磁碟。
當然了，redo log 可不是白紙這麼簡單，一張用完了換一張就行了，這裡有必要詳細解釋下。
每個 InnoDB 儲存引擎至少有 1 個重做日誌檔案組（ redo log group），每個檔案組下至少有 2 個重做日誌檔案（redo log file），預設的話是一個 redo log group，其中包含 2 個 redo log file：ib_logfile0 和 ib_logfile1 。
一般來說，為了得到更高的可靠性，使用者可以設定多個映象日誌組（mirrored log groups），將不同的檔案組放在不同的磁碟上，以此提高 redo log 的高可用性。在日誌組中每個 redo log file 的大小一致，並以迴圈寫入的方式執行。
所謂迴圈寫入，也就是為啥我們說 redo log 不像白紙那樣用完一張換一張就行，舉個例子，如下圖，一個 redo log group，包含 3 個 redo log file：
InnoDB 儲存引擎會先寫 redo log file 0，當 file 0 被寫滿的時候，會切換至 redo log file 1，當 file 1 也被寫滿時，會切換到 redo log file 2 中，而當 file 2 也被寫滿時，會再切換到 file 0 中。
可以看出，redo log file 的大小設定對於 InnoDB 儲存引擎的效能有著非常大的影響：
- redo log file 不能設定得太大，如果設定得很大，在恢復時可能需要很長的時間
- redo log file 又不能設定得太小了，否則可能導致一個事務的日誌需要多次切換重做日誌檔案
CheckPoint 技術
有了 redo log 就可以高枕無憂了嗎？顯然不是這麼簡單，我們仍然面臨這樣 3 個問題：
1）緩衝池不是無限大的，也就是說不能沒完沒了的儲存我們的資料等待一起重新整理到磁碟
2）redo log 是迴圈使用而不是無限大的（也許可以，但是成本太高，同時不便於運維），那麼當所有的 redo log file 都寫滿了怎麼辦？
3）當資料庫執行了幾個月甚至幾年時，這時如果發生當機，重新應用 redo log 的時間會非常久，此時恢復的代價將會非常大。
因此 Checkpoint 技術的目的就是解決上述問題：
- 緩衝池不夠用時，將髒頁重新整理到磁碟
- redo log 不可用時，將髒頁重新整理到磁碟
- 縮短資料庫的恢復時間
所謂 CheckPoint 技術簡單來說其實就是在 redo log file 中找到一個位置，將這個位置前的頁都重新整理到磁碟中去，這個位置就稱為 CheckPoint（檢查點）。
針對上面這三點我們依次來解釋下：
1）縮短資料庫的恢復時間：當資料庫發生當機時，資料庫不需要重做所有的日誌，因為 Checkpoint 之前的頁都已經重新整理回磁碟。故資料庫只需對 Checkpoint 後的 redo log 進行恢復就行了。這顯然大大縮短了恢復的時間。
2）緩衝池不夠用時，將髒頁重新整理到磁碟：所謂緩衝池不夠用的意思就是緩衝池的空間無法存放新讀取到的頁，這個時候 InnoDB 引擎會怎麼辦呢？LRU 演算法。 InnoDB 儲存引擎對傳統的 LRU 演算法做了一些優化，用其來管理緩衝池這塊空間。
總的思路還是傳統 LRU 那套，具體的優化細節這裡就不再贅述了：即最頻繁使用的頁在 LRU 列表（LRU List）的前端，最少使用的頁在 LRU 列表的尾端；當緩衝池的空間無法存放新讀取到的頁時，將首先釋放 LRU 列表中尾端的頁。這個被釋放出來（溢位）的頁，如果是髒頁，那麼就需要強制執行 CheckPoint，將髒頁重新整理到磁碟中去。
3）redo log 不可用時，將髒頁重新整理到磁碟：
所謂 redo log 不可用就是所有的 redo log file 都寫滿了。但事實上，其實 redo log 中的資料並不是時時刻刻都是有用的，那些已經不再需要的部分就稱為 ”可以被重用的部分“，即當資料庫發生當機時，資料庫恢復操作不需要這部分的 redo log，因此這部分就可以被覆蓋重用（或者說被擦除）。
舉個例子來具體解釋下：一組 4 個檔案，每個檔案的大小是 1GB，那麼總共就有 4GB 的 redo log file 空間。write pos 是當前 redo log 記錄的位置，隨著不斷地寫入磁碟，write pos 也不斷地往後移，就像我們上文說的，寫到 file 3 末尾後就回到 file 0 開頭。CheckPoint 是當前要擦除的位置（將 Checkpoint 之前的頁重新整理回磁碟），也是往後推移並且迴圈的：
write pos 和 CheckPoint 之間的就是 redo log file 上還空著的部分，可以用來記錄新的操作。如果 write pos 追上 CheckPoint，就表示 redo log file 滿了，這時候不能再執行新的更新，得停下來先覆蓋（擦掉）一些 redo log，把 CheckPoint 推進一下。
綜上所述，Checkpoint 所做的事情無外乎是將緩衝池中的髒頁重新整理到磁碟。不同之處在於每次重新整理多少頁到磁碟，每次從哪裡取髒頁，以及什麼時間觸發 Checkpoint。在 InnoDB 儲存引擎內部，有兩種 Checkpoint，分別為：
- Sharp Checkpoint：發生在資料庫關閉時將所有的髒頁都重新整理回磁碟，這是預設的工作方式，引數
innodb_fast_shutdown=1 - Fuzzy Checkpoin：InnoDB 儲存引擎內部使用這種模式，只重新整理一部分髒頁，而不是重新整理所有的髒頁回磁碟。關於 Fuzzy CheckPoint 具體的情況這裡就不再贅述了。
有了 bin log 為什麼還需要 redo log？
前文我們講過，MySQL 架構可以分成倆層，一層是 Server 層，它主要做的是 MySQL 功能層面的事情；另一層就是儲存引擎，負責儲存與提取相關的具體事宜。
redo log 是 InnoDB 引擎特有的日誌，而 Server 層也有自己的日誌，包括錯誤日誌（error log）、二進位制日誌（binlog）、慢查詢日誌（slow query log）、查詢日誌（log）。
其他三個日誌顧明思意都挺好理解的，需要解釋的就是 binlog（二進位制日誌，binary log），它記錄了對 MySQL 資料庫執行更改的所有操作，但是不包括 SELECT 和 SHOW 這類操作，因為這類操作對資料本身並沒有修改。也就是說，binlog 是邏輯日誌，記錄的是這個語句的原始邏輯，比如 “給 ID=1 這一行的 a 欄位加 1”。
可以看出來，binlog 日誌只能用於歸檔，因此 binlog 也被稱為歸檔日誌，顯然如果 MySQL 只依靠 binlog 等這四種日誌是沒有 crash-safe 能力的，所以為了彌補這種先天的不足，得益於 MySQL 可插拔的儲存引擎架構，InnoDB 開發了另外一套日誌系統 — 也就是 redo log 來實現 crash-safe 能力。
這就是為什麼有了 bin log 為什麼還需要 redo log 的答案。
回顧下 redo log 儲存的東西，可以發現 redo log 是物理日誌，記錄的是 “在某個資料頁上做了什麼修改”。
另外，還有一點不同的是：binlog 是追加寫入的，就是說 binlog 檔案寫到一定大小後會切換到下一個，並不會覆蓋以前的日誌；而 redo log 是迴圈寫入的。
? 關注公眾號 | 飛天小牛肉，即時獲取更新
- 博主東南大學碩士在讀，攜程 Java 後臺開發暑期實習生，利用課餘時間運營一個公眾號『 飛天小牛肉 』，2020/12/29 日開通，專注分享計算機基礎（資料結構 + 演算法 + 計算機網路 + 資料庫 + 作業系統 + Linux）、Java 技術棧等相關原創技術好文。本公眾號的目的就是讓大家可以快速掌握重點知識，有的放矢。關注公眾號第一時間獲取文章更新，成長的路上我們一起進步
- 並推薦個人維護的開源教程類專案： CS-Wiki（Gitee 推薦專案，現已累計 1.8k+ star）, 致力打造完善的後端知識體系，在技術的路上少走彎路，歡迎各位小夥伴前來交流學習 ~ ?
- 如果各位小夥伴春招秋招沒有拿得出手的專案的話，可以參考我寫的一個專案「開源社群系統 Echo」Gitee 官方推薦專案，目前已累計 900+ star，基於 SpringBoot + MyBatis + MySQL + Redis + Kafka + Elasticsearch + Spring Security + ... 並提供詳細的開發文件和配套教程。公眾號後臺回覆 Echo 可以獲取配套教程，目前尚在更新中。