日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
MySQL的零拷貝技術(shù)

原文：https://spongecaptain.cool/post/mysql/zerocopyofmysql

1.先需要了解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ù)預讀到緩存中，寫進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 機制;當然，在很多場合下 Buffer 與 Cache 有著相同的語義，因此我們可以認為緩沖區(qū)既用于提高讀寫速度，又用于數(shù)據(jù)共享與同步。

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

深入理解零拷貝技術(shù)

2. 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)通過緩存以及預讀機制對文件系統(tǒng)中的 block 基于 page 進行緩存管理;

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

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

3. 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ù)用于控制以下兩個特性之間的平衡：

  • 嚴格的事務(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 活動可能會導致日志刷新更頻繁。另一方面，由于事務(wù)調(diào)度問題，刷新頻率甚至會降低。

刷新頻率默認為 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 方式打開文件意味著文件的每一次寫操作都直接導致將數(shù)據(jù)本身以及元數(shù)據(jù)刷新到磁盤上。

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

首先，我們需要理解更新操作落盤分為兩個具體的子步驟：①文件數(shù)據(jù)更新落盤②文件元數(shù)據(jù)更新落盤。O_DIRECT 的在部分操作系統(tǒng)中會導致文件元數(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ù)的丟失可能會導致 MySQL 運行錯誤。

4. MySQL 日志的刷新策略

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

  • sync_binlog=0：MySQL 應(yīng)用將完全不負責日志同步到磁盤，將緩存中的日志數(shù)據(jù)刷新到磁盤全權(quán)交給操作系統(tǒng)來完成;
  • sync_binlog=1：MySQL 應(yīng)用在事務(wù)提交前將緩存區(qū)的日志刷新到磁盤;
  • sync_binlog=N：當 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 刷新到磁盤上。

5. 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，并且每次寫操作導致的文件數(shù)據(jù)(包括文件元數(shù)據(jù))都通過 fsync 系統(tǒng)調(diào)用刷新到磁盤;

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

  • 日志寫入 Redo Log buffer;志寫入 Redo Log buffer;
  • 日志寫入 Page Cache;
  • 通過系統(tǒng)調(diào)用 fsync 將 Page Cache 中的臟頁刷新到磁盤;
  • 日志提交;

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

  • 更新后的數(shù)據(jù)寫于 InnoDB Buffer Pool;
  • 定時進行如下邏輯(異步進行)：

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

文件的 write 方法直接導致數(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?


網(wǎng)頁題目：MySQL的零拷貝技術(shù)
文章出自：http://www.5511xx.com/article/cdechio.html