這篇文章主要介紹InnoDB IO路徑源碼的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

網(wǎng)站建設哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、重慶小程序開發(fā)公司、集團企業(yè)網(wǎng)站建設等服務項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了臨澧免費建站歡迎大家使用！

InnoDB實現(xiàn)IO Flush通過“os_file_flush”宏收斂，macro展開后為”os_file_flush_func”。

接下來，我們重點看一下，還有其它哪些場景會調用到這個os_file_flush_func函數(shù)：

1. buf_dblwr_init_or_load_pages中，在double buffer 做crash恢復時，如果設置了reset_space_ids為”true”

2. fil_create_new_single_table_tablespace中，創(chuàng)建表數(shù)據(jù)文件時

3. fil_user_tablespace_restore_page中，從double writer buffer中copy page時

4. fil_tablespace_iterate中，如果iterate page失敗時，會做一次sync

5. os_file_set_size中，在文件新創(chuàng)建時初始化文件大小時

從上面可以看出，直接調用os_file_flush_func還是非常少的。那么系統(tǒng)中還有一些是調用os_file_flush_func的上層函數(shù)fil_flush：

1. buf_dblwr_flush_buffered_writes中，flush double write buffer到disk

2. buf_dblwr_write_single_page中，單頁flush到disk中

3. buf_flush_write_block_low中，flush block到disk中，一般在調double write buffer“buf_dblwr_flush_buffered_writes“之后調用

4. buf_LRU_remove_pages中，delete某個tablespace中的page時，做sync調用

5. fil_rename_tablespace中，rename一個tablespace時調用

6. fil_extend_space_to_desired_size中，extend space時

7. fil_flush_file_spaces中，flush 批量tablespace的page時，被ha_innodb的force checkpoint時調用，shutdown DB時調用等

8. log_io_complete中，log io完成時，checkpoint write以及其它，是否調用受sync方式影響，非commit依賴

9. log_write_up_to中，commit事務時，這個是重點，innodb 的log file都會調用，而且是同步

10. create_log_files_rename中，rename log file時

11. innobase_start_or_create_for_MySQL中，創(chuàng)建新的文件時

在fil_flush函數(shù)中，所有文件的flush cache行為受fil_system->mutex保護。因此不管是data file還是log file，文件級別的flush是串化的。那么具體是怎么來控制的呢？

1. 檢查file node中的n_pending_flushes，如果大于“0”就一直retry

2. 如果為“0”，進入flush階段，在正式開始flush之前，先將n_pending_flushe加“1”，這個操作受上文提到的“fil->mutex“保護

3. 調用“os_file_flush“ flush完成之后，n_pending_flushes減“1”，也同樣由“fil->mutex“保護

下面是MySQL中retry的代碼：

下面是MySQL中flush的代碼：

上面提到的邏輯，對于log file也同樣處理。Log file的tablespace為log space。對于log file，還受到log_sys->mutex的保護，在log_write_up_to函數(shù)中。

Log file的flush行為收斂到“l(fā)og_write_up_to”函數(shù)體中，再調用fil_flush，最終走到os_file_flush_func。

MySQL在commit的時候，如果”innodb_flush_log_at_trx_commit=1”時，調用兩次同步的log_write_up_to，一次是innobase log file 的flush，一次是bin log的flush。

如果關掉bin log，則在ordered_commit函數(shù)中，不會走sync_blog分支。以下是關掉和不關掉時，innobase flush log file的執(zhí)行路徑。

不帶binlog時的Innobase 的pstack如下：

帶Binlog的flush pstack如下：

從上面大致的調用來看，log_write_up_to()和log_io_complete()將是重點，因為這些flush在file級別是串行的，commit時的rt主要由這些串化帶來。

接下來我們看一下log_write_up_to的調用者都有那些：

1. buf_flush_write_block_low，在force flush中調用，保證日志必須先于數(shù)據(jù)落地，刷臟頁時，由page_cleaner_do_flush_batch()發(fā)起調用到此函數(shù)

2. innobase_flush_logs，在commit時調用，主要由flush binlog分支調用

3. trx_flush_log_if_needed_low，在commit時調用，主要由flush innodb log file時調用

4. log_buffer_flush_to_disk，log buffer刷日志到disk

5. log_buffer_sync_in_background，后臺線程同步log buffer到disk，由srv_master_thread 線程調srv_sync_log_buffer_in_background()調用到，每秒一次

6. log_flush_margin，主要為騰挪log buffer空間時調用

7. log_checkpoint，主要在做checkpoint時調用到，由srv_master線程調用srv_master_do_idle_tasks()，每秒做一次

log_io_complete()函數(shù)的調用情況：

1. fil_aio_wait，aio wait中如果是log io將會調用此方法

從上面分析可以看到，主要影響RT比較嚴重的還是因為刷臟頁導致的log_sys->mutex爭用。另外，log_buffer_sync_in_background和log_checkpoint，這兩個都是由后臺srv_master_thread線程每隔一秒調用到。

但是這兩個方法不一定會執(zhí)行fil_flush，所以不是影響的主因。gdb掛上去后，大致會走到fil_flush爭用的pstack如下：

因此，總結起來，應該是commit做的兩次fsync加上一次page cleaner做的log_write_up_to()。另外，還有一個fil_aio_wait完成時，如果是log io，就會做一次log_io_complete()。

這四次fsync都會對用戶的rt有影響，commit的兩次無可避免，后面兩次最多也就是調整頻率。另外是否可以改變fsync的方式？這個讀者可以思考。

比oracle實現(xiàn)差，oracle不會作強制的，我記得是給一個標記，策略還是按redo自己的策略來做。oracle的實現(xiàn)應該是考慮到這一點了.

以上是“InnoDB IO路徑源碼的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關知識，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道！