背景
現在主流的數據庫系統的故障恢復邏輯都是基於經典的ARIES協議，也就是基於undo日志+redo日志的來進行故障恢復。redo日志是物理日志，一般采用WAL(Write-Ahead-Logging)機制，所以也稱redo日志為wal日志，redo日志記錄了所有數據的變更，undo日志是邏輯日志，記錄了所有操作的前鏡像，方便異常時進行回滾。用戶在提交事務時，只要確保寫redo日志成功即可，並不需要對應的數據頁也實時落盤，這套機制的基本思想是利用空間換時間，用戶事務的更新實際上在數據頁和redo日志中記錄了兩份，傳統的數據庫存儲引擎都是基於B+Tree來組織數據頁，因此刷數據頁是離散小塊IO，而寫redo是順序IO，對磁盤介質更友好，而且OLTP場景下，業務對RT(ResponseTime)也比較敏感，所以這套機制非常流行。
redo日志是保證數據不丟的關鍵因素，而且每個事務在提交時，都需要寫redo日志，可想而知這塊資源競爭是非常激烈的。這個問題是所有基於WAL機制的數據庫系統個的共性問題，下文的討論以MySQL為例，並以此說明MySQL8.0在這塊的優化。
最初的redo日志機制
在MySQL的日志系統中，這里討論的是InnoDB引擎，mtr(mini-transaction)是最小事務單位，一個用戶事務會對應若干個mtr，mtr保證內部操作的原子性，比如B+Tree分裂操作，必需在一個mtr中。用戶執行操作時，會同時更新數據頁和寫redo日志，mtr是redo日志的載體，存在每個會話的私有變量中。mtr提交時，會將本地redo日志拷貝到全局的log_buffer中，為了保證日志有序性，需要加鎖來訪問log_buffer，這把鎖就是log_sys_t::mutex，所以這個鎖競爭非常激烈。在這個鎖保護下，除了要將本地日志拷貝到全局buffer，還需要將數據頁加入了flush_list，供后台線程刷臟，輔助數據庫檢查點持續往前推進。檢查點一方面能控制全局的redo日志文件大小，讓日志具備循環復用的能力；另一方面，也能提高故障恢復速度。因為故障恢復的本質就是利用落盤的redo日志來恢復沒有落盤的數據頁。所以最開始(MySQL5.1)只有一把鎖，大並發場景下，這個鎖競爭非常激烈，MySQL在多核系統下也無法提升性能。
拆分log_sys_t::mutex
既然鎖競爭壓力大，那么最直觀的想法就是拆鎖。首先按功能拆分，剛剛說到，在mutex保護下，做了兩件事，一件是拷貝本地日志到全局log_buffer；另一件事是將事務修改的page加入到flush_list。日志系統將這兩件事解耦，引入了log_sys_t::flush_order_mutex，減少log_sys_t::mutex的持鎖時間。將本地日志拷貝到log_buffer后，就可以釋放log_sys_t::mutex，這樣拷貝日志的線程和處理flush_list的線程就可以並發起來。
除了這個，日志系統還引入了雙log_buffer機制，這個主要是為了解決全局log_buffer的讀寫並發問題。一個buffer用於拷貝日志到log_buffer，另一個log_buffer則用於讀取，寫入到日志文件。當需要讀log_buffer時，則可以切換log_buffer的角色，這樣就消除了寫日志文件帶來的訪問log_buffer鎖競爭。
但是，拆分完鎖后，多個用戶線程仍然需要在log_sys_t::mutex保護下，串行寫log_buffer，由於memcpy操作比較重，所以這個鎖競爭仍然非常激烈，需要優化。
消除log_sys_t::mutex
為了解決log_sys_t::mutex並發問題，MySQL 8.0引入了新的log_buffer機制，借助於lock_free的link_buf數據結構，利用原子變量來進行預占位，這樣多個線程就能並發寫redo，這種機制帶來了一個空洞問題，因為寫日志速度不一樣，可能導致后占位(lsn較大)的線程先寫完。但是我們寫日志線程肯定是不能將帶有空洞的buffer寫到日志文件，因此會維護一個滑動窗口，即最小的連續的lsn：buf_ready_for_write_lsn。寫日志線程會不斷的檢查 link_buf變量recent_written，然后寫日志，推進buf_ready_for_write_lsn。
前面我們提到了系統中有兩把鎖，log_sys_t::mutex和log_sys_t::flush_order_mutex，通過占位方式，解決了寫log_buffer的問題，那么如何解決將臟頁有序加入到flush_list的問題呢？MySQL 8.0實現中仍然借助於link_buf數據結構，原來要求是加入flush_list的數據頁的oldest_modification_lsn一定是遞增的。這里順便說下oldest_modification_lsn的含義，oldest_modification_lsn是指page第一次被修改后，mtr在log_sys_t中分配的lsn，即使這個page在flush下去之前，又在內存中被修改過N次，仍然以第一次修改的lsn為准，這樣做的目的是，確保數據頁內存的修改與檢查點推進能對應上，避免檢查點推進了，但對應的臟頁可能還未刷盤，造成數據丟失問題。
由於是並發亂序寫log_buffer，那么無法保證按lsn遞增有序加入到flush_list，也就無法推進檢查點。MySQL 8.0通過限制大於一定閥值L的lsn加入到flush_list做為權衡，假設當前flush_list的lsn最大值為M，那么只有在M值與當前線程lsn相差范圍在L以內時，才將臟頁寫入flush_list。同樣的，推進M，也依賴於link_buf變量recent_closed。這種策略本質上放寬了之前對於flush_list中對於LSN全局有序的限制到L范圍內的有序。
除了日志系統變成lock free，MySQL8.0還將寫日志線程從用戶線程中拆分出來，有單獨的log writer線程和log flusher后台線程來處理寫日志和sync日志。原來的寫日志方式是，大家隨機group-commit，由一個線程負責write/flush日志，其它線程等待，這種模式下group的大小比較隨機。拆分后，處理更靈活，batch大小也更好控制，而且對於flush_log_at_trx_commit!=1的場景，只需要等log writer的通知即可。
總結
從MySQL日志系統優化的演進過程來看，始終是圍繞鎖log_sys_t::mutex展開。 從最初的按功能拆分出log_sys_t::flush_order_mutex，到按讀寫拆分實現為雙log_buffer，以及最新的MySQL 8.0利用無鎖機制徹底去掉這把鎖，顯然MySQL的並發能力是越來越強的。這種優化“套路”其實是比較朴素通用的，對於一個新的系統，通過一把大鎖能簡化並發邏輯，優先保證正確性。在系統慢慢演進過程中，我們可以按功能拆分鎖，緩解鎖沖突壓力；如果某把鎖處於核心鏈路，而且又成為瓶頸，那么再想辦法繼續拆，或者實現為無鎖，徹底解決並發沖突問題，目的只有一個就是充分利用多核CPU資源，然線程多干活，減少響應時間的同時，拉高吞吐量，而不是都等待空閑着。文章中並沒有涉及更多關於MySQL8.0日志系統優化的細節，官方文檔已經寫地足夠好，大家可以詳細看看。
參考文檔
https://mysqlserverteam.com/mysql-8-0-new-lock-free-scalable-wal-design/