一。 先需要了解Buffer 與 cache 的區(qū)別

Bbuffer 與 Cache 非常類似，因為它們都用于存儲數(shù)據(jù)數(shù)據(jù)，被應(yīng)用層讀取字節(jié)數(shù)據(jù)。在很多場合它們有著相同的概念：

首先從翻譯上，Buffer應(yīng)該翻譯為“緩沖”，Cache應(yīng)該翻譯為“緩存”，兩個完全不是一個東西。

在硬件這一層看，Buffer應(yīng)該為內(nèi)存，Cache為CPU集成的告訴緩存。

Buffer為了讓不同速度的設(shè)備能夠同步，建立的一個緩沖區(qū)域，寫進Buffer的數(shù)據(jù)是為了從中拿出寫入其他設(shè)備。

Cache是為了提高讀取速度，將經(jīng)?；蝰R上需要的數(shù)據(jù)預(yù)讀到緩存中，寫進Cache的數(shù)據(jù)是為了其他設(shè)備從中去讀取。

從軟件這一層來說，Buffer是塊設(shè)備的緩沖，Cache是文件系統(tǒng)的緩存。以Linux為例，Buffer（Buffer Cache）以塊形式緩沖了塊設(shè)備的操作，定時或手動的同步到硬盤，它是為了緩沖寫操作然后一次性將很多改動寫入硬盤，避免頻繁寫硬盤，提高寫入效率。

Cache（Page Cache）以頁面形式緩存了文件系統(tǒng)的文件，給需要使用的程序讀取，它是為了給讀操作提供緩沖，避免頻繁讀硬盤，提高讀取效率。

總而言之，Buffer里面的東西是為了寫到別處去，Cache里面的東西是為了給別處讀。

Buffer 與 Cache 的用途有所不一定：

Buffer 的主要目的是在不同應(yīng)用、線程、進程之間共享字節(jié)數(shù)據(jù)，例如為了讓不同速度的設(shè)備能夠進行數(shù)據(jù)同步，就會使用共享 Buffer；

Cache 的主要目的是提高字節(jié)數(shù)據(jù)的讀取/寫入速度，例如根據(jù)時間局部性、地址局部性操作系統(tǒng)提供 page cache 機制；

當(dāng)然，在很多場合下 Buffer 與 Cache 有著相同的語義，因此我們可以認為緩沖區(qū)既用于提高讀寫速度，又用于數(shù)據(jù)共享與同步。

關(guān)于零拷貝深入理解：

二。 MySQL 緩沖區(qū)設(shè)計

MySQL 的緩沖區(qū)設(shè)計如下圖所示：

Figure1.MySQL 的緩沖區(qū)設(shè)計

如上圖所示，MySQL 在不同層次使用了與緩存機制不同的配套技術(shù)。其中有：

應(yīng)用層：

Redo Log Buffer：對寫操作進行緩存，用于實現(xiàn) MySQL InnoDB 的事務(wù)性；

InnoDB Buffer Pool：用于對 MySQL table 的數(shù)據(jù)進行緩存。讀內(nèi)存而不是磁盤，通過減少磁盤讀操的方式提高讀操作性能；寫內(nèi)存而不是磁盤，通過減少磁盤寫操的方式提高寫操作性能；

操作系統(tǒng)的 VFS（Virtual file system，虛擬文件系統(tǒng)）層：

Page Cache：操作系統(tǒng)通過緩存以及預(yù)讀機制對文件系統(tǒng)中的 block 基于 page 進行緩存管理；

Direct Buffer：當(dāng)使用 Direct I/O 提供的相關(guān) API 時，操作系統(tǒng)不再提供基于 Page Cache 機制的緩存，而是直接使用 Direct Buffer；

磁盤的 Disk Buffer：磁盤也可以提供磁盤緩存，通常在 MySQL 中會關(guān)閉磁盤緩存，我們僅僅需要了解有 Disk Buffer 這一概念即可。

三。 Write Through/Back 與 Direct I/O

Write Through 與 Write Back 指的是在使用內(nèi)存空間作為緩存的應(yīng)用在處理寫操作時是否直接落盤：

Write Through：寫操作“穿過”緩存區(qū)直接落盤，這種策略能夠確保數(shù)據(jù)不會因為宕機而丟失內(nèi)存緩沖區(qū)的數(shù)據(jù)；

Write Back：一次寫操作僅僅更新了內(nèi)存緩存區(qū)中的數(shù)據(jù)，數(shù)據(jù)落盤通常通過間隔一個時間進行落盤一次；

MySQL 為此提供了一些參數(shù)來控制 Page Cache 數(shù)據(jù)落盤的具體行為，例如：

（1）innodb_flush_log_at_trx_commit

innodb_flush_log_at_trx_commit 參數(shù)用于控制基于 Page Cache 的 Redo Log Buffer 的數(shù)據(jù)落盤機制［2］。此參數(shù)用于控制以下兩個特性之間的平衡：

嚴(yán)格的事務(wù)管理機制；

事務(wù)提交 commit 操作執(zhí)行時的高性能；

innodb_flush_log_at_trx_commit 有三個可選配置值：

1（默認值）：每次事務(wù)提交時都日志必須刷新到磁盤上，提供了最可靠的事務(wù)性保證；

0：日志每間隔 1 秒刷新到磁盤上，這意味著在緩存中還沒有來得及刷新到磁盤上的數(shù)據(jù)在宕機時會丟失；

2：日志在事務(wù)提交后以及每間隔 1 秒刷新到磁盤上，這意味著在緩存中還沒有來得及刷新到磁盤上的數(shù)據(jù)在宕機時會丟失；

注意事項：配置 0 與 2 并不能保證 100% 每間隔一秒刷新到磁盤一次，這是因為 DDL 的修改以及 InnoDB 活動可能會導(dǎo)致日志刷新更頻繁。另一方面，由于事務(wù)調(diào)度問題，刷新頻率甚至?xí)档汀?/p>

刷新頻率默認為 1 s，由參數(shù) innodb_flush_log_at_timeout 進行配置。

（2）innodb_flush_method

innodb_flush_method 參數(shù)同時控制 redo log buffer 和 innodb buffer pool 緩沖區(qū)刷新策略，其中：

log files：redo log buffer 是 log files 在內(nèi)存中的緩存區(qū)， log files 是磁盤上的 Redo Log 文件；

data files：innodb buffer pool 是 data files 在內(nèi)存中的緩存區(qū)，data files 是磁盤上的數(shù)據(jù)文件（B+tree）；

innodb_flush_method 參數(shù)目前有 6 種可選配置值［3］：

fdatasync；

O_DSYNC

O_DIRECT

O_DIRECT_NO_FSYNC

littlesync

nosync

這里只討論 Unix-like 操作系統(tǒng)，而不討論 Windows 系統(tǒng)。

其中，littlesync 與 nosync 僅僅用于內(nèi)部性能測試，并不建議使用。

fdatasync，即取值 0，這是默認配置值。對 log files 以及 data files 都采用 fsync 的方式進行同步；

O_DSYNC，即取值 1。對 log files 使用 O_SYNC 打開與刷新日志文件，使用 fsync 來刷新 data files 中的數(shù)據(jù)；

O_DIRECT，即取值 4。利用 Direct I/O 的方式打開 data file，并且每次寫操作都通過執(zhí)行 fsync 系統(tǒng)調(diào)用的方式落盤；

O_DIRECT_NO_FSYNC，即取值 5。利用 Direct I/O 的方式打開 data files，但是每次寫操作并不會調(diào)用 fsync 系統(tǒng)調(diào)用進行落盤；

補充說明：以 O_SYNC 方式打開文件意味著文件的每一次寫操作都直接導(dǎo)致將數(shù)據(jù)本身以及元數(shù)據(jù)刷新到磁盤上。

為什么有 O_DIRECT 與 O_DIRECT_NO_FSYNC 配置的區(qū)別？

首先，我們需要理解更新操作落盤分為兩個具體的子步驟：

①文件數(shù)據(jù)更新落盤

②文件元數(shù)據(jù)更新落盤。

O_DIRECT 的在部分操作系統(tǒng)中會導(dǎo)致文件元數(shù)據(jù)不落盤，除非主動調(diào)用 fsync，為此，MySQL 提供了 O_DIRECT 以及 O_DIRECT_NO_FSYNC 這兩個配置［5］。

如果你確定在自己的操作系統(tǒng)上，即使不進行 fsync 調(diào)用，也能夠確保文件元數(shù)據(jù)落盤，那么請使用 O_DIRECT_NO_FSYNC 配置，這對 MySQL 性能略有幫助。否則，請使用 O_DIRECT，不然文件元數(shù)據(jù)的丟失可能會導(dǎo)致 MySQL 運行錯誤。

四。 MySQL 日志的刷新策略

MySQL 日志刷新策略通過 sync_binlog 參數(shù)進行配置，其有 3 個可選配置：

sync_binlog=0：MySQL 應(yīng)用將完全不負責(zé)日志同步到磁盤，將緩存中的日志數(shù)據(jù)刷新到磁盤全權(quán)交給操作系統(tǒng)來完成；

sync_binlog=1：MySQL 應(yīng)用在事務(wù)提交前將緩存區(qū)的日志刷新到磁盤；

sync_binlog=N：當(dāng) N 不為 0 與 1 時，MySQL 在收集到 N 個日志提交后，才會將緩存區(qū)的日志同步到磁盤。

事實上，這個參數(shù)也用于控制日志是通過 Write Through 還是 Write Back 策略刷新到磁盤上。

注意事項：使用 Page Cache 機制的數(shù)據(jù)刷盤機制，即使基于同步策略，即每次寫操作都要求數(shù)據(jù)直接落盤，但在數(shù)據(jù)落盤之前，數(shù)據(jù)總是先要寫于 Page Cache 中，再將 Page Cache 中的具體 Page 刷新到磁盤上。

五。 MySQL 的典型配置

innodb_flush_log_at_trx_commit 參數(shù)配置為 1：Redo Log 走 Page Cache，并且每次寫操作的日志在事務(wù)提交前都通過 fsync 刷新到磁盤；

innodb_flush_method 參數(shù)配置為 O_DIRECT：InnoDB Buffer Pool 走 Direct I/O，并且每次寫操作導(dǎo)致的文件數(shù)據(jù)（包括文件元數(shù)據(jù)）都通過 fsync 系統(tǒng)調(diào)用刷新到磁盤；

寫一條 redo log 涉及到的步驟有：

日志寫入 Redo Log buffer；

日志寫入 Page Cache；

通過系統(tǒng)調(diào)用 fsync 將 Page Cache 中的臟頁刷新到磁盤；

日志提交；

修改表的一行記錄涉及到的步驟有：

更新后的數(shù)據(jù)寫于 InnoDB Buffer Pool；

定時進行如下邏輯（異步進行）：

InnoDB Buffer Pool 臟數(shù)據(jù)進行刷新，通過文件的 write 方法進行；

文件的 write 方法直接導(dǎo)致數(shù)據(jù)寫于磁盤上；

定時進行文件的 fysnc 調(diào)用，確保文件元數(shù)據(jù)寫于磁盤上；

REFERENCE

［1］Buffer與Cache

［2］MySQL ：： MySQL 8.0 Reference Manual ：： 15.14 InnoDB Startup Options and System Variables

［3］MySQL 8.0 innodb_flush_method

［4］MySQL ：： MySQL 8.0 Reference Manual ：： 17.1.6.4 Binary Logging Options and Variables

［5］ Why MYSQL still use fsync（） to flush the data when the option is O_DIRECT？

原文標(biāo)題：MySQL 的零拷貝技術(shù)

文章出處：【微信公眾號：Linux愛好者】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。