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

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

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

在硬件這一層看，Buffer應該為內存，Cache為CPU集成的告訴緩存。

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

Cache是為了提高讀取速度，將經常或馬上需要的數(shù)據預讀到緩存中，寫進Cache的數(shù)據是為了其他設備從中去讀取。

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

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

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

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

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

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

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

關于零拷貝深入理解：

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

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

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

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

應用層：

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

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

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

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

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

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

三。 Write Through/Back 與 Direct I/O

Write Through 與 Write Back 指的是在使用內存空間作為緩存的應用在處理寫操作時是否直接落盤：

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

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

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

（1）innodb_flush_log_at_trx_commit

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

嚴格的事務管理機制；

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

innodb_flush_log_at_trx_commit 有三個可選配置值：

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

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

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

注意事項：配置 0 與 2 并不能保證 100% 每間隔一秒刷新到磁盤一次，這是因為 DDL 的修改以及 InnoDB 活動可能會導致日志刷新更頻繁。另一方面，由于事務調度問題，刷新頻率甚至會降低。

刷新頻率默認為 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 在內存中的緩存區(qū)， log files 是磁盤上的 Redo Log 文件；

data files：innodb buffer pool 是 data files 在內存中的緩存區(qū)，data files 是磁盤上的數(shù)據文件（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 僅僅用于內部性能測試，并不建議使用。

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

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

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

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

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

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

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

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

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

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

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

四。 MySQL 日志的刷新策略

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

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

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

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

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

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

五。 MySQL 的典型配置

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

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

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

日志寫入 Redo Log buffer；

日志寫入 Page Cache；

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

日志提交；

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

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

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

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

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

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

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？

原文標題：MySQL 的零拷貝技術

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