重新深入理解零拷贝技术
點擊上方“朱小廝的博客”，選擇“設為星標”
后臺回復"書"，獲取
后臺回復“k8s”，可領取k8s資料
注意事項：除了 Direct I/O，與磁盤相關的文件讀寫操作都有使用到 page cache 技術。
數據的四次拷貝與四次上下文切換
很多應用程序在面臨客戶端請求時，可以等價為進行如下的系統調用：
File.read(file, buf, len);
Socket.send(socket, buf, len);
例如消息中間件 Kafka 就是這個應用場景，從磁盤中讀取一批消息后原封不動地寫入網卡（NIC，Network interface controller）進行發送。
在沒有任何優化技術使用的背景下，操作系統為此會進行 4 次數據拷貝，以及 4 次上下文切換，如下圖所示：
如果沒有優化，讀取磁盤數據，再通過網卡傳輸的場景性能比較差：
4 次 copy：
CPU 負責將數據從磁盤搬運到內核空間的 Page Cache 中；
CPU 負責將數據從內核空間的 Socket 緩沖區搬運到的網絡中；
CPU 負責將數據從內核空間的 Page Cache 搬運到用戶空間的緩沖區；
CPU 負責將數據從用戶空間的緩沖區搬運到內核空間的 Socket 緩沖區中。
4 次上下文切換：
read 系統調用時：用戶態切換到內核態；
read 系統調用完畢：內核態切換回用戶態；
write 系統調用時：用戶態切換到內核態；
write 系統調用完畢：內核態切換回用戶態。
我們不免發出抱怨：
CPU 全程負責內存內的數據拷貝還可以接受，因為效率還算可以接受，但是如果要全程負責內存與磁盤、網絡的數據拷貝，這將難以接受，因為磁盤、網卡的速度遠小于內存，內存又遠遠小于 CPU；
4 次 copy 太多了，4 次上下文切換也太頻繁了。
DMA 參與下的數據四次拷貝
DMA 技術很容易理解，本質上，DMA 技術就是我們在主板上放一塊獨立的芯片。在進行內存和 I/O 設備的數據傳輸的時候，我們不再通過 CPU 來控制數據傳輸，而直接通過 DMA 控制器（DMA Controller，簡稱 DMAC）。這塊芯片，我們可以認為它其實就是一個協處理器（Co-Processor）。
DMAC 最有價值的地方體現在，當我們要傳輸的數據特別大、速度特別快，或者傳輸的數據特別小、速度特別慢的時候。
比如說，我們用千兆網卡或者硬盤傳輸大量數據的時候，如果都用 CPU 來搬運的話，肯定忙不過來，所以可以選擇 DMAC。而當數據傳輸很慢的時候，DMAC 可以等數據到齊了，再發送信號，給到 CPU 去處理，而不是讓 CPU 在那里忙等待。
注意，這里面的“協”字。DMAC 是在“協助”CPU，完成對應的數據傳輸工作。在 DMAC 控制數據傳輸的過程中，我們還是需要 CPU 的進行控制，但是具體數據的拷貝不再由 CPU 來完成。
原本，計算機所有組件之間的數據拷貝（流動）必須經過 CPU，如下圖所示：
現在，DMA 代替了 CPU 負責內存與磁盤以及內存與網卡之間的數據搬運，CPU 作為 DMA 的控制者，如下圖所示：
但是 DMA 有其局限性，DMA 僅僅能用于設備之間交換數據時進行數據拷貝，但是設備內部的數據拷貝還需要 CPU 進行，例如 CPU 需要負責內核空間數據與用戶空間數據之間的拷貝（內存內部的拷貝），如下圖所示：
上圖中的 read buffer 也就是 page cache，socket buffer 也就是 Socket 緩沖區。
零拷貝技術
什么是零拷貝技術？
零拷貝技術是一個思想，指的是指計算機執行操作時，CPU 不需要先將數據從某處內存復制到另一個特定區域。
可見，零拷貝的特點是 CPU 不全程負責內存中的數據寫入其他組件，CPU 僅僅起到管理的作用。但注意，零拷貝不是不進行拷貝，而是 CPU 不再全程負責數據拷貝時的搬運工作。如果數據本身不在內存中，那么必須先通過某種方式拷貝到內存中（這個過程 CPU 可以不參與），因為數據只有在內存中，才能被轉移，才能被 CPU 直接讀取計算。
零拷貝技術的具體實現方式有很多，例如：
sendfile
mmap
splice
直接 Direct I/O
不同的零拷貝技術適用于不同的應用場景，下面依次進行 sendfile、mmap、Direct I/O 的分析。
不過出于總結性的目的，我們在這里先對下面的技術做一個前瞻性的總結。
DMA 技術回顧：DMA 負責內存與其他組件之間的數據拷貝，CPU 僅需負責管理，而無需負責全程的數據拷貝；
使用 page cache 的 zero copy：
sendfile：一次代替 read/write 系統調用，通過使用 DMA 技術以及傳遞文件描述符，實現了 zero copy
mmap：僅代替 read 系統調用，將內核空間地址映射為用戶空間地址，write 操作直接作用于內核空間。通過 DMA 技術以及地址映射技術，用戶空間與內核空間無須數據拷貝，實現了 zero copy
不使用 page cache 的 Direct I/O：讀寫操作直接在磁盤上進行，不使用 page cache 機制，通常結合用戶空間的用戶緩存使用。通過 DMA 技術直接與磁盤/網卡進行數據交互，實現了 zero copy
sendfile
snedfile 的應用場景是：用戶從磁盤讀取一些文件數據后不需要經過任何計算與處理就通過網絡傳輸出去。此場景的典型應用是消息隊列。
在傳統 I/O 下，正如第一節所示，上述應用場景的一次數據傳輸需要四次 CPU 全權負責的拷貝與四次上下文切換，正如本文第一節所述。
sendfile 主要使用到了兩個技術：
DMA 技術；
傳遞文件描述符代替數據拷貝。
下面依次講解這兩個技術的作用。
利用 DMA 技術
sendfile 依賴于 DMA 技術，將四次 CPU 全程負責的拷貝與四次上下文切換減少到兩次，如下圖所示：
利用 DMA 技術減少 2 次 CPU 全程參與的拷貝
DMA 負責磁盤到內核空間中的 Page cache（read buffer）的數據拷貝以及從內核空間中的 socket buffer 到網卡的數據拷貝。
傳遞文件描述符代替數據拷貝
傳遞文件描述可以代替數據拷貝，這是由于兩個原因：
page cache 以及 socket buffer 都在內核空間中；
數據傳輸過程前后沒有任何寫操作。
利用傳遞文件描述符代替內核中的數據拷貝
注意事項：只有網卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技術才可以通過傳遞文件描述符的方式避免內核空間內的一次 CPU 拷貝。這意味著此優化取決于 Linux 系統的物理網卡是否支持（Linux 在內核 2.4 版本里引入了 DMA 的 scatter/gather -- 分散/收集功能，只要確保 Linux 版本高于 2.4 即可）。
一次系統調用代替兩次系統調用
由于 sendfile 僅僅對應一次系統調用，而傳統文件操作則需要使用 read 以及 write 兩個系統調用。
正因為如此，sendfile 能夠將用戶態與內核態之間的上下文切換從 4 次講到 2 次。
sendfile 系統調用僅僅需要兩次上下文切換
另一方面，我們需要注意 sendfile 系統調用的局限性。如果應用程序需要對從磁盤讀取的數據進行寫操作，例如解密或加密，那么 sendfile 系統調用就完全沒法用。這是因為用戶線程根本就不能夠通過 sendfile 系統調用得到傳輸的數據。
mmap
mmap 技術在這篇文章[1]中單獨展開，請移步閱讀。
Direct I/O
Direct I/O 即直接 I/O。其名字中的“直接”二字用于區分使用 page cache 機制的緩存 I/O。
緩存文件 I/O：用戶空間要讀寫一個文件并不直接與磁盤交互，而是中間夾了一層緩存，即 page cache；
直接文件 I/O：用戶空間讀取的文件直接與磁盤交互，沒有中間 page cache 層。
“直接”在這里還有另一層語義：其他所有技術中，數據至少需要在內核空間存儲一份，但是在 Direct I/O 技術中，數據直接存儲在用戶空間中，繞過了內核。
Direct I/O 模式如下圖所示：
Direct I/O 示意圖
此時用戶空間直接通過 DMA 的方式與磁盤以及網卡進行數據拷貝。
Direct I/O 的讀寫非常有特點：
Write 操作：由于其不使用 page cache，所以其進行寫文件，如果返回成功，數據就真的落盤了（不考慮磁盤自帶的緩存）；
Read 操作：由于其不使用 page cache，每次讀操作是真的從磁盤中讀取，不會從文件系統的緩存中讀取。
事實上，即使 Direct I/O 還是可能需要使用操作系統的 fsync 系統調用。為什么？
這是因為雖然文件的數據本身沒有使用任何緩存，但是文件的元數據仍然需要緩存，包括 VFS 中的 inode cache 和 dentry cache 等。
在部分操作系統中，在 Direct I/O 模式下進行 write 系統調用能夠確保文件數據落盤，但是文件元數據不一定落盤。如果在此類操作系統上，那么還需要執行一次 fsync 系統調用確保文件元數據也落盤。否則，可能會導致文件異常、元數據確實等情況。MySQL 的 O_DIRECT 與 O_DIRECT_NO_FSYNC 配置是一個具體案例。
Direct I/O 的優缺點：
優點：
Linux 中的直接 I/O 技術省略掉緩存 I/O 技術中操作系統內核緩沖區的使用，數據直接在應用程序地址空間和磁盤之間進行傳輸，從而使得自緩存應用程序可以省略掉復雜的系統級別的緩存結構，而執行程序自己定義的數據讀寫管理，從而降低系統級別的管理對應用程序訪問數據的影響。
與其他零拷貝技術一樣，避免了內核空間到用戶空間的數據拷貝，如果要傳輸的數據量很大，使用直接 I/O 的方式進行數據傳輸，而不需要操作系統內核地址空間拷貝數據操作的參與，這將會大大提高性能。
缺點：
由于設備之間的數據傳輸是通過 DMA 完成的，因此用戶空間的數據緩沖區內存頁必須進行 page pinning（頁鎖定），這是為了防止其物理頁框地址被交換到磁盤或者被移動到新的地址而導致 DMA 去拷貝數據的時候在指定的地址找不到內存頁從而引發缺頁錯誤，而頁鎖定的開銷并不比 CPU 拷貝小，所以為了避免頻繁的頁鎖定系統調用，應用程序必須分配和注冊一個持久的內存池，用于數據緩沖。
如果訪問的數據不在應用程序緩存中，那么每次數據都會直接從磁盤進行加載，這種直接加載會非常緩慢。
在應用層引入直接 I/O 需要應用層自己管理，這帶來了額外的系統復雜性。
誰會使用 Direct I/O？
IBM的一篇文章[2]指出，自緩存應用程序（ self-caching applications）可以選擇使用 Direct I/O。
自緩存應用程序
對于某些應用程序來說，它會有它自己的數據緩存機制，比如，它會將數據緩存在應用程序地址空間，這類應用程序完全不需要使用操作系統內核中的高速緩沖存儲器，這類應用程序就被稱作是自緩存應用程序（ self-caching applications ）。
例如，應用內部維護一個緩存空間，當有讀操作時，首先讀取應用層的緩存數據，如果沒有，那么就通過 Direct I/O 直接通過磁盤 I/O 來讀取數據。緩存仍然在應用，只不過應用覺得自己實現一個緩存比操作系統的緩存更高效。
數據庫管理系統是這類應用程序的一個代表。自緩存應用程序傾向于使用數據的邏輯表達方式，而非物理表達方式；當系統內存較低的時候，自緩存應用程序會讓這種數據的邏輯緩存被換出，而并非是磁盤上實際的數據被換出。自緩存應用程序對要操作的數據的語義了如指掌，所以它可以采用更加高效的緩存替換算法。自緩存應用程序有可能會在多臺主機之間共享一塊內存，那么自緩存應用程序就需要提供一種能夠有效地將用戶地址空間的緩存數據置為無效的機制，從而確保應用程序地址空間緩存數據的一致性。
另一方面，目前 Linux 上的異步 IO 庫，其依賴于文件使用 O_DIRECT 模式打開，它們通常一起配合使用。
如何使用 Direct I/O？
用戶應用需要實現用戶空間內的緩存區，讀/寫操作應當盡量通過此緩存區提供。如果有性能上的考慮，那么盡量避免頻繁地基于 Direct I/O 進行讀/寫操作。
典型案例
Kakfa
Kafka 作為一個消息隊列，涉及到磁盤 I/O 主要有兩個操作：
Provider 向 Kakfa 發送消息，Kakfa 負責將消息以日志的方式持久化落盤；
Consumer 向 Kakfa 進行拉取消息，Kafka 負責從磁盤中讀取一批日志消息，然后再通過網卡發送。
Kakfa 服務端接收 Provider 的消息并持久化的場景下使用 mmap 機制，能夠基于順序磁盤 I/O 提供高效的持久化能力，使用的 Java 類為 java.nio.MappedByteBuffer。
Kakfa 服務端向 Consumer 發送消息的場景下使用 sendfile 機制，這種機制主要兩個好處：
sendfile 避免了內核空間到用戶空間的 CPU 全程負責的數據移動；
sendfile 基于 Page Cache 實現，因此如果有多個 Consumer 在同時消費一個主題的消息，那么由于消息一直在 page cache 中進行了緩存，因此只需一次磁盤 I/O，就可以服務于多個 Consumer。
使用 mmap 來對接收到的數據進行持久化，使用 sendfile 從持久化介質中讀取數據然后對外發送是一對常用的組合。但是注意，你無法利用 sendfile 來持久化數據，利用 mmap 來實現 CPU 全程不參與數據搬運的數據拷貝。MySQL
MySQL 的具體實現比 Kakfa 復雜很多，這是因為支持 SQL 查詢的數據庫本身比消息隊列對復雜很多。
MySQL
的零拷貝技術使用方式請移步我的另一篇文章[3]。
總結
DMA 技術的推出使得內存與其他組件，例如磁盤、網卡進行數據拷貝時，CPU 僅僅需要發出控制信號，而拷貝數據的過程則由 DMA 負責完成。
Linux 的零拷貝技術有多種實現策略，但根據策略可以分為如下幾種類型：
減少甚至避免用戶空間和內核空間之間的數據拷貝：在一些場景下，用戶進程在數據傳輸過程中并不需要對數據進行訪問和處理，那么數據在 Linux 的 Page Cache 和用戶進程的緩沖區之間的傳輸就完全可以避免，讓數據拷貝完全在內核里進行，甚至可以通過更巧妙的方式避免在內核里的數據拷貝。這一類實現一般是是通過增加新的系統調用來完成的，比如 Linux 中的 mmap()，sendfile() 以及 splice() 等。
繞過內核的直接 I/O：允許在用戶態進程繞過內核直接和硬件進行數據傳輸，內核在傳輸過程中只負責一些管理和輔助的工作。這種方式其實和第一種有點類似，也是試圖避免用戶空間和內核空間之間的數據傳輸，只是第一種方式是把數據傳輸過程放在內核態完成，而這種方式則是直接繞過內核和硬件通信，效果類似但原理完全不同。
內核緩沖區和用戶緩沖區之間的傳輸優化：這種方式側重于在用戶進程的緩沖區和操作系統的頁緩存之間的 CPU 拷貝的優化。這種方法延續了以往那種傳統的通信方式，但更靈活。
相關鏈接：
https://spongecaptain.cool/SimpleClearFileIO/3.%20mmap.html
https://www.ibm.com/developerworks/cn/linux/l-cn-directio/
https://spongecaptain.cool/zerocopyofmysql
ClickHouse到底是什么？為什么如此牛逼！
原來ElasticSearch還可以這么理解
面試官：InnoDB中一棵B+樹可以存放多少行數據？
架構之道：分離業務邏輯和技術細節
星巴克不使用兩階段提交
面試官：Redis新版本開始引入多線程，談談你的看法？
喜馬拉雅自研網關架構演進過程
收藏：存儲知識全面總結
微博千萬級規模高性能高并發的網絡架構設計
總結
以上是生活随笔為你收集整理的重新深入理解零拷贝技术的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 今日推荐：如何设计一个支撑数亿用户的系统
- 下一篇： 空降进阿里的 P10 都是什么人