作者：楊一迪，騰訊雲資料庫後臺開發工程師，主要負責雲資料庫postgresql、雲資料庫CynosDB等產品的後臺開發工作。

前言

最開始瞭解mysql實現的時候，總聽到redo log， WAL（write-ahead logging），undo log這些關鍵詞，瞭解到redo log主要是用於實現事務的持久化的。為了進一步瞭解redo log，看了下相關程式碼（原始碼版本： mysql 8.0.12），這裡簡單總結下，主要介紹redo log是如何產生，如何落盤，以及最終通知使用者的。

由於學習mysql的時間不長，mysql程式碼也非常龐大，自己看的也只是其中一小部分，文中有理解得不對的地方，歡迎大家糾正指導，共同學習。

redo log的產生

讀寫事務在執行的過程中，會不斷的產生redo log。申請資料頁、修改資料頁、記錄undo log等，都會產生redo log。mysql將使用者事務拆分成一個個mtr(mini transaction），redo log最初產生時就是被記錄到mtr中的，並伴隨著mtr的提交而提交，最終落到硬碟上。

redo log 的提交

mtr在提交時，會將mtr中的redo log寫到系統變數log_sys的log buffer中。mysql8.0一個新特性就是redo log提交的無鎖化。在8.0以前，各個使用者執行緒都是通過互斥量競爭，序列的寫log buffer，因此能保證lsn的順序無間隔增長。8.0時使用者執行緒可以併發寫log buffer，如果某個使用者執行緒寫log buffer成功後，就將自己寫的lsn以前的log buffer刷盤，則有可能導致其他使用者執行緒寫log buffer還沒完成就被刷盤。

為了解決這個問題，mysql 8.0引入了Link_buf這個資料結構來避免log buffer的空洞。Link_buf實際是一個定長陣列，像滑動視窗一樣跟蹤log buffer一段區間的寫入情況，隨著log buffer中寫入連續redo log不斷向前推進。

Link_buf的資料結構如圖：

當用戶在log buffer的start_lsn-end_lsn間寫下redo log時，會標記Link_buf相應的位置，即將m_link[start_lsn%m_capacity]賦值為為end_lsn-start_lsn。

redo log記錄到log buffer的過程如下：

1.首先，各使用者執行緒寫redo log時，先根據redo log長度，向系統全域性原子變數log_sys.sn獲取本次redo log日誌的start_lsn,end_lsn。原子變數sn能保證各執行緒獲得的start_lsn-end_lsn區間連續無空洞；

2.使用者執行緒申請到start_lsn-end_lsn區間後，需要先等待到Link_buf推進到自己可以使用的位置。

如圖所示，start_lsn0-end_lsn0,start_lsn2-end_lsn2,start_lsn3-end_lsn3為三個使用者執行緒新申請的lsn區間；start_lsn1-end_lsn1對應的區間已經標記到link_buf上；start_lsn3-end_lsn3距離tail太遠，需要等待link_buf推進才能使用；

3.寫入log buffer後，再將start_lsn->end_lsn的範圍標記到link_buf（注意：因為只在start_lsn%capacity的位置標記link_buf，所以即使end_lsn超過(m_tail,m_tail+m_capacity)也不影響）；

4.使用者執行緒提交事務時設定事件log_sys.writer_event，觸發log_writer執行緒將日誌從redo log buffer寫到系統快取（log_writer執行緒自己也會輪詢link_buf判斷是否寫入了新的日誌）；

5.log_writer執行緒推進m_tail，並將m_tail前的log buffer落盤。

redo log 的落盤及通知

前面簡述了redo log是如何提交的，在redo log提交以及落盤時，涉及多個執行緒，他們的關係如下：

使用者執行緒在讀寫事務提交時，會產生一些redo log，並隨著mtr提交而記錄到redo log buffer中，隨後使用者執行緒嘗試設定writer_event觸發log_writer執行緒寫日誌，並監聽屬於自己的flush_events[i]事件；

log_writer執行緒推進Link_buf.m_tail，將最大連續lsn前的redo log寫入系統快取，並設定flusher_event觸發log_flusher執行緒；

log_flusher執行緒將已寫入系統快取的日誌刷盤，並設定flush_notifier_event觸發log_flush_notifier執行緒通知使用者；

log_flush_notifier根據已刷盤的lsn換算出需要觸發的事件，通知使用者執行緒。

具體實現時，通過log_sys中的幾個成員變數，跟進redo log的寫入情況。其中log_sys.recent_writtern.m_tail表示log buffer最大連續範圍；log_sys.write_lsn表示寫入到系統快取的位置；log_sys.flushed_to_disk_lsn表示已落盤的位置。各標記的推進過程如下：

通知使用者執行緒

使用者提交事務時，會根據innodb_flush_log_at_trx_commit引數，呼叫log_wait_for_write或log_wait_for_flush，來等待redo log寫入到系統快取或刷到硬碟。使用者執行緒的通知是通過log_sys.flush_events事件陣列來實現的，為了避免一次通知的flush_events過多，flush_events會像桶一樣劃分給不同的使用者執行緒：redo log是以一個個log block劃分的，假設log_sys.flush_events陣列長度為m，則第n個log block的刷盤，由flush_events[n%m]事件監聽。當log buffer的第L1個log block到第L2個log block被刷盤時，會設定L1-L2之間的log block所屬的flush_events，從而redo log在L1-L2之間的使用者執行緒都會收到通知。

總結

mysql8.0通過redo log無鎖化，解決了使用者執行緒寫redo log時競爭鎖帶來的效能影響。同時將redo log寫檔案、redo log刷盤從使用者執行緒中剝離出來，抽成單獨的執行緒，使用者執行緒只負責將redo log寫入到log buffer，不再關心redo log的落盤細節，只需等待log_writer執行緒或log_flusher執行緒的通知。

往期推薦

淺析 InnoDB Redo Log

特惠體驗雲資料庫 

點選享受騰訊雲MySQL優惠活動