又是被自己菜醒的一天，總結面經看到這題目聽都沒聽過，打開百度就像吃飯一樣自然
老規矩，背誦版在文末，點擊閱讀原文可以直達我收錄整理的各大廠面試真題
首先，咱需要明白的是，啥是持久化？
聽起來高大上，換句簡單的話來說，就是把資料寫到磁盤上，也成為落盤，
那為啥要做持久化到磁盤？
目的就是可以在資料丟失后進行恢復，保證資料不丟失，
那么對于 MySQL 來說，只要 binlog 和 redolog 都能正確持久化到磁盤上，就可以保證資料不丟失了，
由此引出文題，不過在講 redolog 之前，我們還是有必要先來說一下 binlog 的持久化操作，
binlog 持久化
這里引入了一個新的概念：binlog cache
從名字就能看出來，binlog cache 其實就是一片記憶體區域，充當快取的作用，
每個執行緒都有自己 binlog cache 區域，在事務運行的程序中，MySQL 會先把日志寫到 binlog cache 中，等到事務真正提交的時候，再統一把 binlog cache 中的資料寫到 binlog 檔案中，（binlog cache 有很多個，binlog 檔案只有一個！）
事實上，這個從 binlog cache 寫到 binlog 檔案中的操作，并不就是落盤操作了，這里僅僅是把 binlog 寫到了檔案系統的 page cache 上（這一步對應下圖中的 write 操作），
簡單解釋下檔案系統的 page cache：
CPU 如果要訪問外部磁盤上的檔案，需要首先將這些檔案的內容拷貝到記憶體中，由于硬體的限制，從磁盤到記憶體的資料傳輸速度是很慢的，如果現在物理記憶體有空余，干嘛不用這些空閑記憶體來快取一些磁盤的檔案內容呢，這部分用作快取磁盤檔案的記憶體就叫做 page cache，
很多同學看到這里可能覺得特別特別熟悉，是的，和 CPU 里的高速快取是不是很像？兩者其實都是利用的區域性原理，只不過高速快取是 CPU 快取記憶體的資料，而 page cache 是記憶體快取磁盤的資料，這也體現了作業系統記憶體層次結構分級的思想，
所以，最后需要把 page cache 中的資料同步到磁盤上，才算真正完成了 binlog 的持久化（這一步對應下圖中的 fsync 操作），一般情況下，我們認為 fsync 才占磁盤的 IOPS (Input/Output Operations Per Second)
write 和 fsync 的時機，是由引數 sync_binlog 控制的：
- sync_binlog = 0，每次提交事務的時候，只進行 write，不進行 fsync
- sync_binlog = 1候，每次提交事務的時候，執行 write 和 fsync
- sync_binlog = N(N>1)，每次提交事務的時候，執行 write，累積 N 個事務后再執行 fsync
可以看出來，如果業務場景涉及到的 IO 操作很多的話，可以適當增大 sync_binlog 的值，提高性能，但是也存在一定的風險，比如你設定成 100，萬一在第 80 個事務提交的時候資料庫宕機了，那這些事務的 binlog 日志由于沒有執行 fsync，也就丟失了，
redolog 持久化
類比 binlog，在事務執行程序中，binlog 都是存在 binlog cache 中，redolog 也有這樣一塊記憶體區域，叫作 redolog buffer，
在事務運行的程序中，MySQL 會先把日志寫到 redolog buffer 中，等到事務真正提交的時候，再統一把 redolog buffer 中的資料寫到 redolog 檔案中，和 binlog 的落盤操作一樣，這個從 redolog buffer 寫到 redolog 檔案中的操作，并不就是落盤操作了，這里僅僅是把 redolog 寫到了檔案系統的 page cache 上，最后還需要執行 fsync 才能夠實作真正的落盤，
解釋下 redo log buffer？
在一個事務的更新程序中，日志是要寫多次的，比如下面這個事務：
begin;
insert into table1 ...
insert into table2 ...
commit;
這個事務要往兩個表 table1 和 table2 中插入記錄，為了確保這個事務不被拆開，一次性的完整寫入日志檔案中，在插入資料的程序中，我們需要把生成的日志都先保存起來，redolog buffer 就是這么一個用來先存 redo 日志的地方，
也就是說，在執行第一條 insert 陳述句的時候，redolog buffer 也就寫入了這條記錄的日志，
不同于 binlog cache 每個執行緒都有一個，redolog buffer 只有那么一個，
事實上，日志寫到 redolog buffer 是很快的，wirte 到 page cache 也差不多，但是 fsync 持久化到磁盤的速度就慢多了，為了控制 redo log 的寫入策略，InnoDB 提供了 innodb_flush_log_at_trx_commit 引數，它有三種可能取值：
innodb_flush_log_at_trx_commit = 0，每次事務提交的時候，都只是把 redolog 留在 redolog buffer 中innodb_flush_log_at_trx_commit = 1，每次事務提交的時候，都執行 fsync 將 redolog 直接持久化到磁盤innodb_flush_log_at_trx_commit = 2，每次事務提交的時候，都只執行 write 將 redolog 寫到檔案系統的 page cache 中
說了這么多，各位小伙伴們對 binlog 和 redolog 的持久化機制想必都有所了解了，我們來看文題：事務還沒提交的時候，redolog 能不能被持久化到磁盤呢？
先說答案，答案就是有可能，
分析下 redolog 可能存在的三種狀態（binlog 也差不多）：
- 事務執行程序中，存在 MySQL 的行程記憶體中的 redolog buffer 中
- 事務提交，執行 write 操作存在檔案系統的 page cache 中，但是沒有執行 fsync 操作持久化到磁盤
- 事務提交，執行 fsync 操作持久化到磁盤
至于為什么說事務還沒提交的時候，redolog 也有可能被持久化到磁盤呢？
InnoDB 有一個后臺執行緒，每隔 1 秒輪詢一次，具體的操作是這樣的：呼叫 write 將 redolog buffer 中的日志寫到檔案系統的 page cache，然后呼叫 fsync 持久化到磁盤，而在事務執行中間程序的 redolog 都是直接寫在 redolog buffer 中的，也就是說，一個沒有提交的事務的 redolog，也是有可能會被后臺執行緒一起持久化到磁盤的，
另外，除了后臺執行緒每秒一次的輪詢操作外，還有兩種場景會讓一個沒有提交的事務的 redolog 寫盤：
-
innodb_flush_log_at_trx_commit 設定是 1，這樣并行的某個事務提交的時候，就會順帶將這個事務的 redolog buffer 持久化到磁盤
舉個例子，假設事務 A 執行到一半，已經寫了一些 redolog 到 redolog buffer 中，這時候有另外一個事務 B 提交，按照 innodb_flush_log_at_trx_commit = 1 的邏輯，事務 B 要把 redolog buffer 里的日志全部持久化到磁盤，這時候，就會帶上事務 A 在 redolog buffer 里的日志一起持久化到磁盤
-
redo log buffer 占用的空間達到 redolo buffer 大小（由引數
innodb_log_buffer_size控制，默認是 8MB）一半的時候，后臺執行緒會主動寫盤，不過由于這個事務并沒有提交，所以這個寫盤動作只是 write 到了檔案系統的 page cache，仍然是在記憶體中，并沒有呼叫 fsync 真正落盤
最后放上這道題的背誦版：
?? 面試官：
- 問題：事務還沒提交的時候，redo log 能不能被持久化到磁盤呢？
- 相關問題：MySQL 是如何保證資料不丟失的呢？
?? 小牛肉：事務還沒有提交的時候，redo log 是有可能被持久化到磁盤的，
redolog 的具體落盤操作是這樣的：在事務運行的程序中，MySQL 會先把日志寫到 redolog buffer 中，等到事務真正提交的時候，再統一把 redolog buffer 中的資料寫到 redolog 檔案中，不過這個從 redolog buffer 寫到 redolog 檔案中的操作也就是 write 并不就是落盤操作了，這里僅僅是把 redolog 寫到了檔案系統的 page cache 上，最后還需要執行 fsync 才能夠實作真正的落盤，
也就是說，redolog 其實存在三種狀態：
- 事務執行程序中，存在 MySQL 的行程記憶體中的 redolog buffer 中
- 事務提交，執行 write 操作存在檔案系統的 page cache 中，但是沒有執行 fsync 操作持久化到磁盤
- 事務提交，執行 fsync 操作持久化到磁盤
額為什么說事務還沒提交的時候，redolog 也有可能被持久化到磁盤呢？
主要有三種可能的原因：
- 第一種情況：InnoDB 有一個后臺執行緒，每隔 1 秒輪詢一次，具體的操作是這樣的：呼叫 write 將 redolog buffer 中的日志寫到檔案系統的 page cache，然后呼叫 fsync 持久化到磁盤，而在事務執行中間程序的 redolog 都是直接寫在 redolog buffer 中的，也就是說，一個沒有提交的事務的 redolog，也是有可能會被后臺執行緒一起持久化到磁盤的，
- 第二種情況：innodb_flush_log_at_trx_commit 設定是 1，這個引數的意思就是，每次事務提交的時候，都執行 fsync 將 redolog 直接持久化到磁盤（還有 0 和 2 的選擇，0 表示每次事務提交的時候，都只是把 redolog 留在 redolog buffer 中；2 表示每次事務提交的時候，都只執行 write 將 redolog 寫到檔案系統的 page cache 中），舉個例子，假設事務 A 執行到一半，已經寫了一些 redolog 到 redolog buffer 中，這時候有另外一個事務 B 提交，按照 innodb_flush_log_at_trx_commit = 1 的邏輯，事務 B 要把 redolog buffer 里的日志全部持久化到磁盤，這時候，就會帶上事務 A 在 redolog buffer 里的日志一起持久化到磁盤
- 第二種情況：redo log buffer 占用的空間達到 redolog buffer 大小（由引數
innodb_log_buffer_size控制，默認是 8MB）一半的時候，后臺執行緒會主動寫盤，不過由于這個事務并沒有提交，所以這個寫盤動作只是 write 到了檔案系統的 page cache，仍然是在記憶體中，并沒有呼叫 fsync 真正落盤
大廠面試火箭計劃
準備面試的小伙伴可以參考我的 Notion 筆記呀：https://flying-veal.notion.site/，總結了很多大廠面試題，提供背誦版和詳解版，應該對小伙伴們有所幫助~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/415273.html
標籤：其他