今天深入理解一下零拷貝技術~?

數(shù)據(jù)的四次拷貝與四次上下文切換

很多應用程序在面臨客戶端請求時，可以等價為進行如下的系統(tǒng)調用：

• File.read(file, buf, len);
• Socket.send(socket, buf, len);

例如消息中間件 Kafka 就是這個應用場景，從磁盤中讀取一批消息后原封不動地寫入網(wǎng)卡（NIC，Network interface controller）進行發(fā)送。

在沒有任何優(yōu)化技術使用的背景下，操作系統(tǒng)為此會進行 4 次數(shù)據(jù)拷貝，以及 4 次上下文切換，如下圖所示：

如果沒有優(yōu)化，讀取磁盤數(shù)據(jù)，再通過網(wǎng)卡傳輸?shù)膱鼍靶阅鼙容^差：

4 次 copy：

• CPU 負責將數(shù)據(jù)從磁盤搬運到內核空間的 Page Cache 中；
• CPU 負責將數(shù)據(jù)從內核空間的 Socket 緩沖區(qū)搬運到的網(wǎng)絡中；
• CPU 負責將數(shù)據(jù)從內核空間的 Page Cache 搬運到用戶空間的緩沖區(qū)；
• CPU 負責將數(shù)據(jù)從用戶空間的緩沖區(qū)搬運到內核空間的 Socket 緩沖區(qū)中。

4 次上下文切換：

• read 系統(tǒng)調用時：用戶態(tài)切換到內核態(tài)；
• read 系統(tǒng)調用完畢：內核態(tài)切換回用戶態(tài)；
• write 系統(tǒng)調用時：用戶態(tài)切換到內核態(tài)；
• write 系統(tǒng)調用完畢：內核態(tài)切換回用戶態(tài)。

我們不免發(fā)出抱怨：

• CPU 全程負責內存內的數(shù)據(jù)拷貝還可以接受，因為效率還算可以接受，但是如果要全程負責內存與磁盤、網(wǎng)絡的數(shù)據(jù)拷貝，這將難以接受，因為磁盤、網(wǎng)卡的速度遠小于內存，內存又遠遠小于 CPU；
• 4 次 copy 太多了，4 次上下文切換也太頻繁了。

DMA 參與下的數(shù)據(jù)四次拷貝

DMA 技術很容易理解，本質上，DMA 技術就是我們在主板上放一塊獨立的芯片。在進行內存和 I/O 設備的數(shù)據(jù)傳輸?shù)臅r候，我們不再通過 CPU 來控制數(shù)據(jù)傳輸，而直接通過 DMA 控制器（DMA Controller，簡稱 DMAC）。這塊芯片，我們可以認為它其實就是一個協(xié)處理器（Co-Processor）。

DMAC 最有價值的地方體現(xiàn)在，當我們要傳輸?shù)臄?shù)據(jù)特別大、速度特別快，或者傳輸?shù)臄?shù)據(jù)特別小、速度特別慢的時候。

比如說，我們用千兆網(wǎng)卡或者硬盤傳輸大量數(shù)據(jù)的時候，如果都用 CPU 來搬運的話，肯定忙不過來，所以可以選擇 DMAC。而當數(shù)據(jù)傳輸很慢的時候，DMAC 可以等數(shù)據(jù)到齊了，再發(fā)送信號，給到 CPU 去處理，而不是讓 CPU 在那里忙等待。

注意，這里面的“協(xié)”字。DMAC 是在“協(xié)助”CPU，完成對應的數(shù)據(jù)傳輸工作。在 DMAC 控制數(shù)據(jù)傳輸?shù)倪^程中，我們還是需要 CPU 的進行控制，但是具體數(shù)據(jù)的拷貝不再由 CPU 來完成。

原本，計算機所有組件之間的數(shù)據(jù)拷貝（流動）必須經(jīng)過 CPU，如下圖所示：

現(xiàn)在，DMA 代替了 CPU 負責內存與磁盤以及內存與網(wǎng)卡之間的數(shù)據(jù)搬運，CPU 作為 DMA 的控制者，如下圖所示：

但是 DMA 有其局限性，DMA 僅僅能用于設備之間交換數(shù)據(jù)時進行數(shù)據(jù)拷貝，但是設備內部的數(shù)據(jù)拷貝還需要 CPU 進行，例如 CPU 需要負責內核空間數(shù)據(jù)與用戶空間數(shù)據(jù)之間的拷貝（內存內部的拷貝），如下圖所示：

上圖中的 read buffer 也就是 page cache，socket buffer 也就是 Socket 緩沖區(qū)。

零拷貝技術

什么是零拷貝技術？

零拷貝技術是一個思想，指的是指計算機執(zhí)行操作時，CPU 不需要先將數(shù)據(jù)從某處內存復制到另一個特定區(qū)域。

可見，零拷貝的特點是 CPU 不全程負責內存中的數(shù)據(jù)寫入其他組件，CPU 僅僅起到管理的作用。但注意，零拷貝不是不進行拷貝，而是 CPU 不再全程負責數(shù)據(jù)拷貝時的搬運工作。如果數(shù)據(jù)本身不在內存中，那么必須先通過某種方式拷貝到內存中（這個過程 CPU 可以不參與），因為數(shù)據(jù)只有在內存中，才能被轉移，才能被 CPU 直接讀取計算。

零拷貝技術的具體實現(xiàn)方式有很多，例如：

• sendfile
• mmap
• splice
• 直接 Direct I/O

不同的零拷貝技術適用于不同的應用場景，下面依次進行 sendfile、mmap、Direct I/O 的分析。

不過出于總結性的目的，我們在這里先對下面的技術做一個前瞻性的總結。

• DMA 技術回顧：DMA 負責內存與其他組件之間的數(shù)據(jù)拷貝，CPU 僅需負責管理，而無需負責全程的數(shù)據(jù)拷貝；
• 使用 page cache 的 zero copy：

sendfile：一次代替 read/write 系統(tǒng)調用，通過使用 DMA 技術以及傳遞文件描述符，實現(xiàn)了 zero copy

mmap：僅代替 read 系統(tǒng)調用，將內核空間地址映射為用戶空間地址，write 操作直接作用于內核空間。通過 DMA 技術以及地址映射技術，用戶空間與內核空間無須數(shù)據(jù)拷貝，實現(xiàn)了 zero copy

• 不使用 page cache 的 Direct I/O：讀寫操作直接在磁盤上進行，不使用 page cache 機制，通常結合用戶空間的用戶緩存使用。通過 DMA 技術直接與磁盤/網(wǎng)卡進行數(shù)據(jù)交互，實現(xiàn)了 zero copy

sendfile

snedfile 的應用場景是：用戶從磁盤讀取一些文件數(shù)據(jù)后不需要經(jīng)過任何計算與處理就通過網(wǎng)絡傳輸出去。此場景的典型應用是消息隊列。

在傳統(tǒng) I/O 下，正如第一節(jié)所示，上述應用場景的一次數(shù)據(jù)傳輸需要四次 CPU 全權負責的拷貝與四次上下文切換，正如本文第一節(jié)所述。

sendfile 主要使用到了兩個技術：

• DMA 技術；
• 傳遞文件描述符代替數(shù)據(jù)拷貝。

下面依次講解這兩個技術的作用。

利用 DMA 技術

sendfile 依賴于 DMA 技術，將四次 CPU 全程負責的拷貝與四次上下文切換減少到兩次，如下圖所示：

利用 DMA 技術減少 2 次 CPU 全程參與的拷貝

DMA 負責磁盤到內核空間中的 Page cache（read buffer）的數(shù)據(jù)拷貝以及從內核空間中的 socket buffer 到網(wǎng)卡的數(shù)據(jù)拷貝。

傳遞文件描述符代替數(shù)據(jù)拷貝

傳遞文件描述可以代替數(shù)據(jù)拷貝，這是由于兩個原因：

• page cache 以及 socket buffer 都在內核空間中；
• 數(shù)據(jù)傳輸過程前后沒有任何寫操作。

利用傳遞文件描述符代替內核中的數(shù)據(jù)拷貝

注意事項：只有網(wǎng)卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技術才可以通過傳遞文件描述符的方式避免內核空間內的一次 CPU 拷貝。這意味著此優(yōu)化取決于 Linux 系統(tǒng)的物理網(wǎng)卡是否支持（Linux 在內核 2.4 版本里引入了 DMA 的 scatter/gather -- 分散/收集功能，只要確保 Linux 版本高于 2.4 即可）。

一次系統(tǒng)調用代替兩次系統(tǒng)調用

由于 sendfile 僅僅對應一次系統(tǒng)調用，而傳統(tǒng)文件操作則需要使用 read 以及 write 兩個系統(tǒng)調用。

正因為如此，sendfile 能夠將用戶態(tài)與內核態(tài)之間的上下文切換從 4 次講到 2 次。

sendfile 系統(tǒng)調用僅僅需要兩次上下文切換

另一方面，我們需要注意 sendfile 系統(tǒng)調用的局限性。如果應用程序需要對從磁盤讀取的數(shù)據(jù)進行寫操作，例如解密或加密，那么 sendfile 系統(tǒng)調用就完全沒法用。這是因為用戶線程根本就不能夠通過 sendfile 系統(tǒng)調用得到傳輸?shù)臄?shù)據(jù)。

mmap

mmap 技術在這篇文章[1]中單獨展開，請移步閱讀。

Direct I/O

Direct I/O 即直接 I/O。其名字中的“直接”二字用于區(qū)分使用 page cache 機制的緩存 I/O。

• 緩存文件 I/O：用戶空間要讀寫一個文件并不直接與磁盤交互，而是中間夾了一層緩存，即 page cache；
• 直接文件 I/O：用戶空間讀取的文件直接與磁盤交互，沒有中間 page cache 層。

“直接”在這里還有另一層語義：其他所有技術中，數(shù)據(jù)至少需要在內核空間存儲一份，但是在 Direct I/O 技術中，數(shù)據(jù)直接存儲在用戶空間中，繞過了內核。

Direct I/O 模式如下圖所示：

Direct I/O 示意圖

此時用戶空間直接通過 DMA 的方式與磁盤以及網(wǎng)卡進行數(shù)據(jù)拷貝。

Direct I/O 的讀寫非常有特點：

• Write 操作：由于其不使用 page cache，所以其進行寫文件，如果返回成功，數(shù)據(jù)就真的落盤了（不考慮磁盤自帶的緩存）；
• Read 操作：由于其不使用 page cache，每次讀操作是真的從磁盤中讀取，不會從文件系統(tǒng)的緩存中讀取。

事實上，即使 Direct I/O 還是可能需要使用操作系統(tǒng)的 fsync 系統(tǒng)調用。為什么？

這是因為雖然文件的數(shù)據(jù)本身沒有使用任何緩存，但是文件的元數(shù)據(jù)仍然需要緩存，包括 VFS 中的 inode cache 和 dentry cache 等。

在部分操作系統(tǒng)中，在 Direct I/O 模式下進行 write 系統(tǒng)調用能夠確保文件數(shù)據(jù)落盤，但是文件元數(shù)據(jù)不一定落盤。如果在此類操作系統(tǒng)上，那么還需要執(zhí)行一次 fsync 系統(tǒng)調用確保文件元數(shù)據(jù)也落盤。否則，可能會導致文件異常、元數(shù)據(jù)確實等情況。MySQL 的 O_DIRECT 與 O_DIRECT_NO_FSYNC 配置是一個具體案例。

Direct I/O 的優(yōu)缺點：

優(yōu)點：

• Linux 中的直接 I/O 技術省略掉緩存 I/O 技術中操作系統(tǒng)內核緩沖區(qū)的使用，數(shù)據(jù)直接在應用程序地址空間和磁盤之間進行傳輸，從而使得自緩存應用程序可以省略掉復雜的系統(tǒng)級別的緩存結構，而執(zhí)行程序自己定義的數(shù)據(jù)讀寫管理，從而降低系統(tǒng)級別的管理對應用程序訪問數(shù)據(jù)的影響。
• 與其他零拷貝技術一樣，避免了內核空間到用戶空間的數(shù)據(jù)拷貝，如果要傳輸?shù)臄?shù)據(jù)量很大，使用直接 I/O 的方式進行數(shù)據(jù)傳輸，而不需要操作系統(tǒng)內核地址空間拷貝數(shù)據(jù)操作的參與，這將會大大提高性能。

缺點：

• 由于設備之間的數(shù)據(jù)傳輸是通過 DMA 完成的，因此用戶空間的數(shù)據(jù)緩沖區(qū)內存頁必須進行 page pinning（頁鎖定），這是為了防止其物理頁框地址被交換到磁盤或者被移動到新的地址而導致 DMA 去拷貝數(shù)據(jù)的時候在指定的地址找不到內存頁從而引發(fā)缺頁錯誤，而頁鎖定的開銷并不比 CPU 拷貝小，所以為了避免頻繁的頁鎖定系統(tǒng)調用，應用程序必須分配和注冊一個持久的內存池，用于數(shù)據(jù)緩沖。
• 如果訪問的數(shù)據(jù)不在應用程序緩存中，那么每次數(shù)據(jù)都會直接從磁盤進行加載，這種直接加載會非常緩慢。
• 在應用層引入直接 I/O 需要應用層自己管理，這帶來了額外的系統(tǒng)復雜性。

誰會使用 Direct I/O？

IBM的一篇文章[2]指出，自緩存應用程序（ self-caching applications）可以選擇使用 Direct I/O。

自緩存應用程序

對于某些應用程序來說，它會有它自己的數(shù)據(jù)緩存機制，比如，它會將數(shù)據(jù)緩存在應用程序地址空間，這類應用程序完全不需要使用操作系統(tǒng)內核中的高速緩沖存儲器，這類應用程序就被稱作是自緩存應用程序（ self-caching applications ）。

例如，應用內部維護一個緩存空間，當有讀操作時，首先讀取應用層的緩存數(shù)據(jù)，如果沒有，那么就通過 Direct I/O 直接通過磁盤 I/O 來讀取數(shù)據(jù)。緩存仍然在應用，只不過應用覺得自己實現(xiàn)一個緩存比操作系統(tǒng)的緩存更高效。

數(shù)據(jù)庫管理系統(tǒng)是這類應用程序的一個代表。自緩存應用程序傾向于使用數(shù)據(jù)的邏輯表達方式，而非物理表達方式；當系統(tǒng)內存較低的時候，自緩存應用程序會讓這種數(shù)據(jù)的邏輯緩存被換出，而并非是磁盤上實際的數(shù)據(jù)被換出。自緩存應用程序對要操作的數(shù)據(jù)的語義了如指掌，所以它可以采用更加高效的緩存替換算法。自緩存應用程序有可能會在多臺主機之間共享一塊內存，那么自緩存應用程序就需要提供一種能夠有效地將用戶地址空間的緩存數(shù)據(jù)置為無效的機制，從而確保應用程序地址空間緩存數(shù)據(jù)的一致性。

另一方面，目前 Linux 上的異步 IO 庫，其依賴于文件使用 O_DIRECT 模式打開，它們通常一起配合使用。

如何使用 Direct I/O？

用戶應用需要實現(xiàn)用戶空間內的緩存區(qū)，讀/寫操作應當盡量通過此緩存區(qū)提供。如果有性能上的考慮，那么盡量避免頻繁地基于 Direct I/O 進行讀/寫操作。

典型案例

Kakfa

• Kafka 作為一個消息隊列，涉及到磁盤 I/O 主要有兩個操作：
• Provider 向 Kakfa 發(fā)送消息，Kakfa 負責將消息以日志的方式持久化落盤；

Consumer 向 Kakfa 進行拉取消息，Kafka 負責從磁盤中讀取一批日志消息，然后再通過網(wǎng)卡發(fā)送。

Kakfa 服務端接收 Provider 的消息并持久化的場景下使用 mmap 機制，能夠基于順序磁盤 I/O 提供高效的持久化能力，使用的 Java 類為 java.nio.MappedByteBuffer。

Kakfa 服務端向 Consumer 發(fā)送消息的場景下使用 sendfile 機制，這種機制主要兩個好處：

• sendfile 避免了內核空間到用戶空間的 CPU 全程負責的數(shù)據(jù)移動；
• sendfile 基于 Page Cache 實現(xiàn)，因此如果有多個 Consumer 在同時消費一個主題的消息，那么由于消息一直在 page cache 中進行了緩存，因此只需一次磁盤 I/O，就可以服務于多個 Consumer。

使用 mmap 來對接收到的數(shù)據(jù)進行持久化，使用 sendfile 從持久化介質中讀取數(shù)據(jù)然后對外發(fā)送是一對常用的組合。但是注意，你無法利用 sendfile 來持久化數(shù)據(jù)，利用 mmap 來實現(xiàn) CPU 全程不參與數(shù)據(jù)搬運的數(shù)據(jù)拷貝。MySQL

MySQL 的具體實現(xiàn)比 Kakfa 復雜很多，這是因為支持 SQL 查詢的數(shù)據(jù)庫本身比消息隊列對復雜很多。

總結

DMA 技術的推出使得內存與其他組件，例如磁盤、網(wǎng)卡進行數(shù)據(jù)拷貝時，CPU 僅僅需要發(fā)出控制信號，而拷貝數(shù)據(jù)的過程則由 DMA 負責完成。

Linux 的零拷貝技術有多種實現(xiàn)策略，但根據(jù)策略可以分為如下幾種類型：

減少甚至避免用戶空間和內核空間之間的數(shù)據(jù)拷貝：在一些場景下，用戶進程在數(shù)據(jù)傳輸過程中并不需要對數(shù)據(jù)進行訪問和處理，那么數(shù)據(jù)在 Linux 的 Page Cache 和用戶進程的緩沖區(qū)之間的傳輸就完全可以避免，讓數(shù)據(jù)拷貝完全在內核里進行，甚至可以通過更巧妙的方式避免在內核里的數(shù)據(jù)拷貝。這一類實現(xiàn)一般是是通過增加新的系統(tǒng)調用來完成的，比如 Linux 中的 mmap()，sendfile() 以及 splice() 等。

繞過內核的直接 I/O：允許在用戶態(tài)進程繞過內核直接和硬件進行數(shù)據(jù)傳輸，內核在傳輸過程中只負責一些管理和輔助的工作。這種方式其實和第一種有點類似，也是試圖避免用戶空間和內核空間之間的數(shù)據(jù)傳輸，只是第一種方式是把數(shù)據(jù)傳輸過程放在內核態(tài)完成，而這種方式則是直接繞過內核和硬件通信，效果類似但原理完全不同。

內核緩沖區(qū)和用戶緩沖區(qū)之間的傳輸優(yōu)化：這種方式側重于在用戶進程的緩沖區(qū)和操作系統(tǒng)的頁緩存之間的 CPU 拷貝的優(yōu)化。這種方法延續(xù)了以往那種傳統(tǒng)的通信方式，但更靈活。