- Buffer 與 cache 的區別？
- Bbuffer 與 Cache 非常類似，因爲它們都用於存儲數據數據，被應用層讀取字節數據。在很多場合它們有着相同的概念，但是特定場合也有一定的區別[1]。
Buffer 與 Cache 的用途有所不一定：
Buffer 的主要目的是在不同應用、線程、進程之間共享字節數據，例如爲了讓不同速度的設備能夠進行數據同步，就會使用共享 Buffer；
Cache 的主要目的是提高字節數據的讀取/寫入速度，例如根據時間局部性、地址局部性操作系統提供 page cache 機制；
當然，在很多場合下 Buffer 與 Cache 有着相同的語義，因此我們可以認爲緩衝區既用於提高讀寫速度，又用於數據共享與同步。
- MySQL 緩衝區設計
MySQL 的緩衝區設計如下圖所示：
Figure1.MySQL 的緩衝區設計
如上圖所示，MySQL 在不同層次使用了與緩存機制不同的配套技術。其中有：
應用層：
Redo Log Buffer：對寫操作進行緩存，用於實現 MySQL InnoDB 的事務性；
InnoDB Buffer Pool：用於對 MySQL table 的數據進行緩存。讀內存而不是磁盤，通過減少磁盤讀操的方式提高讀操作性能；寫內存而不是磁盤，通過減少磁盤寫操的方式提高寫操作性能；
操作系統的 VFS（Virtual file system，虛擬文件系統）層：
Page Cache：操作系統通過緩存以及預讀機制對文件系統中的 block 基於 page 進行緩存管理；
Direct Buffer：當使用 Direct I/O 提供的相關 API 時，操作系統不再提供基於 Page Cache 機制的緩存，而是直接使用 Direct Buffer；
磁盤的 Disk Buffer：磁盤也可以提供磁盤緩存，通常在 MySQL 中會關閉磁盤緩存，我們僅僅需要了解有 Disk Buffer 這一概念即可。
- Write Through/Back 與 Direct I/O
Write Through 與 Write Back 指的是在使用內存空間作爲緩存的應用在處理寫操作時是否直接落盤：
Write Through：寫操作"穿過"緩存區直接落盤，這種策略能夠確保數據不會因爲宕機而丟失內存緩衝區的數據；
Write Back：一次寫操作僅僅更新了內存緩存區中的數據，數據落盤通常通過間隔一個時間進行落盤一次；
MySQL 爲此提供了一些參數來控制 Page Cache 數據落盤的具體行爲，例如：
（1）innodb_flush_log_at_trx_commit
innodb_flush_log_at_trx_commit 參數用於控制基於 Page Cache 的 Redo Log Buffer 的數據落盤機制[2]。此參數用於控制以下兩個特性之間的平衡：
嚴格的事務管理機制；
事務提交 commit 操作執行時的高性能；
innodb_flush_log_at_trx_commit 有三個可選配置值：
1（默認值）：每次事務提交時都日誌必須刷新到磁盤上，提供了最可靠的事務性保證；
0：日誌每間隔 1 秒刷新到磁盤上，這意味着在緩存中還沒有來得及刷新到磁盤上的數據在宕機時會丟失；
2：日誌在事務提交後以及每間隔 1 秒刷新到磁盤上，這意味着在緩存中還沒有來得及刷新到磁盤上的數據在宕機時會丟失；
注意事項：配置 0 與 2 並不能保證 100% 每間隔一秒刷新到磁盤一次，這是因爲 DDL 的修改以及 InnoDB 活動可能會導致日誌刷新更頻繁。另一方面，由於事務調度問題，刷新頻率甚至會降低。
刷新頻率默認爲 1 s，由參數 innodb_flush_log_at_timeout 進行配置。
（2）innodb_flush_method
innodb_flush_method 參數同時控制 redo log buffer 和 innodb buffer pool 緩衝區刷新策略，其中：
log files：redo log buffer 是 log files 在內存中的緩存區， log files 是磁盤上的 Redo Log 文件；
data files：innodb buffer pool 是 data files 在內存中的緩存區，data files 是磁盤上的數據文件（B+tree）；
innodb_flush_method 參數目前有 6 種可選配置值[3]：
fdatasync； O_DSYNC O_DIRECT O_DIRECT_NO_FSYNC littlesync nosync
這裏只討論 Unix-like 操作系統，而不討論 Windows 系統。
其中，littlesync 與 nosync 僅僅用於內部性能測試，並不建議使用。
fdatasync，即取值 0，這是默認配置值。對 log files 以及 data files 都採用 fsync 的方式進行同步；
O_DSYNC，即取值 1。對 log files 使用 O_SYNC 打開與刷新日誌文件，使用 fsync 來刷新 data files 中的數據；
O_DIRECT，即取值 4。利用 Direct I/O 的方式打開 data file，並且每次寫操作都通過執行 fsync 系統調用的方式落盤；
O_DIRECT_NO_FSYNC，即取值 5。利用 Direct I/O 的方式打開 data files，但是每次寫操作並不會調用 fsync 系統調用進行落盤；
補充說明：以 O_SYNC 方式打開文件意味着文件的每一次寫操作都直接導致將數據本身以及元數據刷新到磁盤上。
爲什麼有 O_DIRECT 與 O_DIRECT_NO_FSYNC 配置的區別？
首先，我們需要理解更新操作落盤分爲兩個具體的子步驟：①文件數據更新落盤②文件元數據更新落盤。O_DIRECT 的在部分操作系統中會導致文件元數據不落盤，除非主動調用 fsync，爲此，MySQL 提供了 O_DIRECT 以及 O_DIRECT_NO_FSYNC 這兩個配置[5]。
如果你確定在自己的操作系統上，即使不進行 fsync 調用，也能夠確保文件元數據落盤，那麼請使用 O_DIRECT_NO_FSYNC 配置，這對 MySQL 性能略有幫助。否則，請使用 O_DIRECT，不然文件元數據的丟失可能會導致 MySQL 運行錯誤。
- MySQL 日誌的刷新策略
MySQL 日誌刷新策略通過 sync_binlog 參數進行配置，其有 3 個可選配置：
sync_binlog=0：MySQL 應用將完全不負責日誌同步到磁盤，將緩存中的日誌數據刷新到磁盤全權交給操作系統來完成；
sync_binlog=1：MySQL 應用在事務提交前將緩存區的日誌刷新到磁盤；
sync_binlog=N：當 N 不爲 0 與 1 時，MySQL 在收集到 N 個日誌提交後，纔會將緩存區的日誌同步到磁盤。
事實上，這個參數也用於控制日誌是通過 Write Through 還是 Write Back 策略刷新到磁盤上。
注意事項：使用 Page Cache 機制的數據刷盤機制，即使基於同步策略，即每次寫操作都要求數據直接落盤，但在數據落盤之前，數據總是先要寫於 Page Cache 中，再將 Page Cache 中的具體 Page 刷新到磁盤上。
- MySQL 的典型配置
innodb_flush_log_at_trx_commit 參數配置爲 1：Redo Log 走 Page Cache，並且每次寫操作的日誌在事務提交前都通過 fsync 刷新到磁盤；
innodb_flush_method 參數配置爲 O_DIRECT：InnoDB Buffer Pool 走 Direct I/O，並且每次寫操作導致的文件數據（包括文件元數據）都通過 fsync 系統調用刷新到磁盤；
寫一條 redo log 涉及到的步驟有：
日誌寫入 Redo Log buffer；
日誌寫入 Page Cache；
通過系統調用 fsync 將 Page Cache 中的髒頁刷新到磁盤；
日誌提交；
修改表的一行記錄涉及到的步驟有：
更新後的數據寫於 InnoDB Buffer Pool；
定時進行如下邏輯（異步進行）：
InnoDB Buffer Pool 髒數據進行刷新，通過文件的 write 方法進行；
文件的 write 方法直接導致數據寫於磁盤上；
定時進行文件的 fysnc 調用，確保文件元數據寫於磁盤上；
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?
