本會(huì)從以下幾個(gè)方面介紹磁盤的IO技術(shù)：
DMA之前的IO方式
直接內(nèi)存訪問——DMA技術(shù)。
DMA文件傳輸存在的問題。
如何提高文件傳輸?shù)男阅堋?/p>
零拷貝實(shí)現(xiàn)原理分析。
PageCache有什么用。
大文件傳輸用什么方式實(shí)現(xiàn)。
在沒有DMA技術(shù)之前，操作系統(tǒng)的從磁盤讀取數(shù)據(jù)的IO過程如下所示（以read()接口為例）：
read(file, tmp_buf, len);
用戶程序需要讀取數(shù)據(jù)，調(diào)用read方法，把讀取數(shù)據(jù)的指令交給CPU執(zhí)行，線程進(jìn)入阻塞狀態(tài)。
CPU發(fā)出指令給磁盤控制器，告訴磁盤控制器需要讀取哪些數(shù)據(jù)，然后返回；
磁盤控制器接收到指令后，把指定的數(shù)據(jù)放入磁盤內(nèi)部的緩存區(qū)，然后用中斷的方式通知CPU；
CPU收到中斷信號(hào)之后，開始一個(gè)字節(jié)一個(gè)字節(jié)的把數(shù)據(jù)讀取到PageCache緩存區(qū)；
CPU再一個(gè)字節(jié)一個(gè)字節(jié)把數(shù)據(jù)從PageCache緩存區(qū)讀取到用戶緩存區(qū)；
用戶程序從內(nèi)存中讀取到數(shù)據(jù)，可以繼續(xù)執(zhí)行后續(xù)邏輯。
可以看到，整個(gè)數(shù)據(jù)的傳輸過程，都要需要CPU親自參與搬運(yùn)數(shù)據(jù)的過程，而且這個(gè)過程，CPU是不能做其他事情的。簡(jiǎn)單的搬運(yùn)幾個(gè)字符數(shù)據(jù)那沒問題，但是如果我們用千兆網(wǎng)卡或者硬盤傳輸大量數(shù)據(jù)的時(shí)候，都用CPU來搬運(yùn)的話，肯定忙不過來。計(jì)算機(jī)科學(xué)家們發(fā)現(xiàn)了事情的嚴(yán)重性后，于是就發(fā)明了 DMA 技術(shù)，也就是直接內(nèi)存訪問（Direct Memory Access） 技術(shù)。
什么是 DMA 技術(shù)？簡(jiǎn)單理解就是，在進(jìn)行 I/O 設(shè)備和內(nèi)存的數(shù)據(jù)傳輸?shù)臅r(shí)候，數(shù)據(jù)搬運(yùn)的工作全部交給 DMA 控制器，而 CPU 不再參與任何與數(shù)據(jù)搬運(yùn)相關(guān)的事情，這樣 CPU 就可以去處理別的事務(wù)。
那使用 DMA 控制器進(jìn)行數(shù)據(jù)傳輸?shù)倪^程究竟是什么樣的呢？下面我們來具體看看。
read(file, tmp_buf, len);
用戶程序需要讀取數(shù)據(jù)，調(diào)用read方法，把讀取數(shù)據(jù)的指令交給CPU執(zhí)行。
CPU發(fā)出指令給DMA，告訴DMA需要讀取磁盤的哪些數(shù)據(jù)，然后返回，線程進(jìn)入阻塞狀態(tài)
DMA向磁盤控制器發(fā)出IO請(qǐng)求，告訴磁盤控制器需要讀取哪些數(shù)據(jù)，然后返回；
磁盤控制器收到IO請(qǐng)求之后，把數(shù)據(jù)讀取到磁盤緩存區(qū)，當(dāng)磁盤緩存讀取完成之后，中斷DMA；
DMA收到磁盤的中斷信號(hào)，將磁盤緩存區(qū)的數(shù)據(jù)讀取到PageCache緩存區(qū)，然后中斷CPU；
CPU響應(yīng)DMA中斷信號(hào)，知道數(shù)據(jù)讀取完成，然后將PageCache緩存區(qū)中的數(shù)據(jù)讀取到用戶緩存中；
用戶程序從內(nèi)存中讀取到數(shù)據(jù)，可以繼續(xù)執(zhí)行后續(xù)邏輯。
可以看到， 整個(gè)數(shù)據(jù)傳輸?shù)倪^程，CPU不再參與磁盤數(shù)據(jù)搬運(yùn)的工作，而是全程由DMA完成，但是CPU在這個(gè)過程中也是必不可少的，因?yàn)閭鬏斒裁磾?shù)據(jù)，從哪里傳輸?shù)侥睦?，都需要CPU來告訴DMA控制器。
早期DMA只存在在主板上，如今由于I/O設(shè)備越來越多，數(shù)據(jù)傳輸?shù)男枨笠膊槐M相同，所以每個(gè)I/O設(shè)備里面都有自己的DMA控制器。
如果服務(wù)端要提供文件傳輸?shù)墓δ?，我們能想到的最?jiǎn)單的方式是：將磁盤上的文件讀取出來，然后通過網(wǎng)絡(luò)協(xié)議發(fā)送給客戶端。
傳統(tǒng) I/O 的工作方式是，數(shù)據(jù)讀取和寫入是從用戶空間到內(nèi)核空間來回復(fù)制，而內(nèi)核空間的數(shù)據(jù)是通過操作系統(tǒng)層面的 I/O 接口從磁盤讀取或?qū)懭搿?/p>
代碼通常如下，一般會(huì)需要以下兩個(gè)系統(tǒng)調(diào)用，代碼很簡(jiǎn)單，雖然就兩行代碼，但是這里面發(fā)生了不少的事情。
read(file, tmp_buf, len); write(socket, tmp_buf, len);
用戶程序需要讀取數(shù)據(jù)，調(diào)用read方法，把讀取數(shù)據(jù)的指令交給CPU執(zhí)行，線程進(jìn)入阻塞狀態(tài)。
CPU發(fā)出指令給磁盤DMA，告訴磁盤DMA需要讀取磁盤的哪些數(shù)據(jù)，然后返回；
磁盤DMA向磁盤控制器發(fā)出IO請(qǐng)求，告訴磁盤控制器需要讀取哪些數(shù)據(jù)，然后返回；
磁盤控制器收到IO請(qǐng)求之后，把數(shù)據(jù)讀取到磁盤緩存區(qū)，當(dāng)磁盤緩存讀取完成之后，中斷DMA；
DMA收到磁盤的中斷信號(hào)，將磁盤緩存區(qū)的數(shù)據(jù)讀取到PageCache緩存區(qū)，然后中斷CPU；
CPU響應(yīng)DMA中斷信號(hào)，知道數(shù)據(jù)讀取完成，然后將PageCache緩存區(qū)中的數(shù)據(jù)讀取到用戶緩存中；
用戶程序從內(nèi)存中讀取到數(shù)據(jù)，可以繼續(xù)執(zhí)行后續(xù)寫網(wǎng)卡數(shù)據(jù)操作；
用戶需要向網(wǎng)卡設(shè)備寫入數(shù)據(jù)，調(diào)用write方法，把寫數(shù)據(jù)指令交給CPU執(zhí)行，線程進(jìn)入阻塞；
CPU將用戶緩存區(qū)的數(shù)據(jù)寫入PageCache緩存區(qū)，然后通知網(wǎng)卡DMA寫數(shù)據(jù)；
網(wǎng)卡DMA將數(shù)據(jù)從PageCache緩存區(qū)復(fù)制到網(wǎng)卡，交給網(wǎng)卡處理數(shù)據(jù)。
網(wǎng)卡開始處理數(shù)據(jù)，網(wǎng)卡處理完成數(shù)據(jù)之后中斷網(wǎng)卡DMA；
網(wǎng)卡DMA處理中斷，知道數(shù)據(jù)處理完成，向CPU發(fā)出中斷；
CPU響應(yīng)DMA中斷信號(hào)，知道數(shù)據(jù)處理完成，喚醒用戶線程；
用戶程序執(zhí)行后續(xù)邏輯。
這個(gè)過程比較復(fù)雜，其中主要存在以下問題：
發(fā)生了4次用戶態(tài)與內(nèi)核態(tài)的上下文切換，因?yàn)榘l(fā)生了兩次系統(tǒng)調(diào)用，一次是read() ，一次是write()，每次系統(tǒng)調(diào)用都得先從用戶態(tài)切換到內(nèi)核態(tài)，等內(nèi)核完成任務(wù)后，再從內(nèi)核態(tài)切換回用戶態(tài)。上下文切換到成本并不小，一次切換需要耗時(shí)幾十納秒到幾微秒，雖然時(shí)間看上去很短，但是在高并發(fā)的場(chǎng)景下，這類時(shí)間容易被累積和放大，從而影響系統(tǒng)的性能。
發(fā)生了4次數(shù)據(jù)拷貝，其中兩次是 DMA 的拷貝，另外兩次則是通過 CPU 拷貝的，下面說一下這個(gè)過程：第一次拷貝，把磁盤上的數(shù)據(jù)拷貝到操作系統(tǒng)內(nèi)核的緩沖區(qū)里，這個(gè)拷貝的過程是通過 DMA 搬運(yùn)的。第二次拷貝，把內(nèi)核緩沖區(qū)的數(shù)據(jù)拷貝到用戶的緩沖區(qū)里，于是我們應(yīng)用程序就可以使用這部分?jǐn)?shù)據(jù)了，這個(gè)拷貝到過程是由 CPU 完成的。第三次拷貝，把剛才拷貝到用戶的緩沖區(qū)里的數(shù)據(jù)，再拷貝到內(nèi)核的 socket 的緩沖區(qū)里，這個(gè)過程依然還是由 CPU 搬運(yùn)的。第四次拷貝，把內(nèi)核的 socket 緩沖區(qū)里的數(shù)據(jù)，拷貝到網(wǎng)卡的緩沖區(qū)里，這個(gè)過程又是由 DMA 搬運(yùn)的。
我們回過頭看這個(gè)文件傳輸?shù)倪^程，我們只是搬運(yùn)一份數(shù)據(jù)，結(jié)果卻搬運(yùn)了 4 次，過多的數(shù)據(jù)拷貝無疑會(huì)消耗 CPU 資源，大大降低了系統(tǒng)性能。
這種簡(jiǎn)單又傳統(tǒng)的文件傳輸方式，存在冗余的上文切換和數(shù)據(jù)拷貝，在高并發(fā)系統(tǒng)里是非常糟糕的，多了很多不必要的開銷，會(huì)嚴(yán)重影響系統(tǒng)性能。
所以，要想提高文件傳輸?shù)男阅?，就需要減少「用戶態(tài)與內(nèi)核態(tài)的上下文切換」和「內(nèi)存拷貝」的次數(shù)。
讀取磁盤數(shù)據(jù)的時(shí)候，之所以要發(fā)生上下文切換，這是因?yàn)橛脩艨臻g沒有權(quán)限操作磁盤或網(wǎng)卡，內(nèi)核的權(quán)限最高，這些操作設(shè)備的過程都需要交由操作系統(tǒng)內(nèi)核來完成，所以一般要通過內(nèi)核去完成某些任務(wù)的時(shí)候，就需要使用操作系統(tǒng)提供的系統(tǒng)調(diào)用函數(shù)。
而一次系統(tǒng)調(diào)用必然會(huì)發(fā)生 2 次上下文切換：首先從用戶態(tài)切換到內(nèi)核態(tài)，當(dāng)內(nèi)核執(zhí)行完任務(wù)后，再切換回用戶態(tài)交由進(jìn)程代碼執(zhí)行。
所以，要想減少上下文切換到次數(shù)，就要減少系統(tǒng)調(diào)用的次數(shù)。
在前面我們知道了，傳統(tǒng)的文件傳輸方式會(huì)歷經(jīng) 4 次數(shù)據(jù)拷貝，而且這里面，「從內(nèi)核的讀緩沖區(qū)拷貝到用戶的緩沖區(qū)里，再從用戶的緩沖區(qū)里拷貝到 socket 的緩沖區(qū)里」，這個(gè)過程是沒有必要的。
因?yàn)槲募鬏數(shù)膽?yīng)用場(chǎng)景中，在用戶空間我們并不會(huì)對(duì)數(shù)據(jù)「再加工」，所以數(shù)據(jù)實(shí)際上可以不用搬運(yùn)到用戶空間，因此用戶的緩沖區(qū)是沒有必要存在的。
零拷貝技術(shù)實(shí)現(xiàn)的方式通常有 2 種：
mmap + write
sendfile
下面就談一談，它們是如何減少「上下文切換」和「數(shù)據(jù)拷貝」的次數(shù)。
在前面我們知道，read()系統(tǒng)調(diào)用的過程中會(huì)把內(nèi)核緩沖區(qū)的數(shù)據(jù)拷貝到用戶的緩沖區(qū)里，于是為了減少這一步開銷，我們可以用 mmap()替換read()系統(tǒng)調(diào)用函數(shù)。
buf = mmap(file, len); write(sockfd, buf, len);
mmap() 系統(tǒng)調(diào)用函數(shù)會(huì)直接把內(nèi)核緩沖區(qū)里的數(shù)據(jù)「映射」到用戶空間，這樣，操作系統(tǒng)內(nèi)核與用戶空間就不需要再進(jìn)行任何的數(shù)據(jù)拷貝操作。
具體過程如下：
應(yīng)用進(jìn)程調(diào)用了mmap()后，DMA會(huì)把磁盤的數(shù)據(jù)拷貝到內(nèi)核的緩沖區(qū)里。接著，應(yīng)用進(jìn)程跟操作系統(tǒng)內(nèi)核「共享」這個(gè)緩沖區(qū)；
應(yīng)用進(jìn)程再調(diào)用write()，操作系統(tǒng)直接將內(nèi)核緩沖區(qū)的數(shù)據(jù)拷貝到socket緩沖區(qū)中，這一切都發(fā)生在內(nèi)核態(tài)，由CPU來搬運(yùn)數(shù)據(jù)；
最后，把內(nèi)核的socket緩沖區(qū)里的數(shù)據(jù)，拷貝到網(wǎng)卡的緩沖區(qū)里，這個(gè)過程是由DMA搬運(yùn)的。
我們可以得知，通過使用mmap()來代替read()， 可以減少一次數(shù)據(jù)拷貝的過程。
但這還不是最理想的零拷貝，因?yàn)槿匀恍枰ㄟ^CPU把內(nèi)核緩沖區(qū)的數(shù)據(jù)拷貝到socket緩沖區(qū)里，而且仍然需要4次上下文切換，因?yàn)橄到y(tǒng)調(diào)用還是2次。
在 Linux 內(nèi)核版本 2.1 中，提供了一個(gè)專門發(fā)送文件的系統(tǒng)調(diào)用函數(shù) sendfile()，函數(shù)形式如下：
#includessize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
它的前兩個(gè)參數(shù)分別是目的端和源端的文件描述符，后面兩個(gè)參數(shù)是源端的偏移量和復(fù)制數(shù)據(jù)的長(zhǎng)度，返回值是實(shí)際復(fù)制數(shù)據(jù)的長(zhǎng)度。
首先，它可以替代前面的 read() 和 write() 這兩個(gè)系統(tǒng)調(diào)用，這樣就可以減少一次系統(tǒng)調(diào)用，也就減少了 2 次上下文切換的開銷。
其次，該系統(tǒng)調(diào)用，可以直接把內(nèi)核緩沖區(qū)里的數(shù)據(jù)拷貝到 socket 緩沖區(qū)里，不再拷貝到用戶態(tài)，這樣就只有 2 次上下文切換，和 3 次數(shù)據(jù)拷貝。如下圖：
但是這還不是真正的零拷貝技術(shù)，如果網(wǎng)卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技術(shù)（和普通的 DMA 有所不同），我們可以進(jìn)一步減少通過 CPU 把內(nèi)核緩沖區(qū)里的數(shù)據(jù)拷貝到 socket 緩沖區(qū)的過程。
你可以在你的 Linux 系統(tǒng)通過下面這個(gè)命令，查看網(wǎng)卡是否支持 scatter-gather 特性：
$ ethtool -k eth0 | grep scatter-gather scatter-gather: on
于是，從 Linux 內(nèi)核 2.4 版本開始起，對(duì)于支持網(wǎng)卡支持 SG-DMA 技術(shù)的情況下， sendfile() 系統(tǒng)調(diào)用的過程發(fā)生了點(diǎn)變化，具體過程如下：
通過 DMA 將磁盤上的數(shù)據(jù)拷貝到內(nèi)核緩沖區(qū)里；
緩沖區(qū)描述符和數(shù)據(jù)長(zhǎng)度傳到 socket 緩沖區(qū)，這樣網(wǎng)卡的 SG-DMA 控制器就可以直接將內(nèi)核緩存中的數(shù)據(jù)拷貝到網(wǎng)卡的緩沖區(qū)里，此過程不需要將數(shù)據(jù)從操作系統(tǒng)內(nèi)核緩沖區(qū)拷貝到 socket 緩沖區(qū)中，這樣就減少了一次數(shù)據(jù)拷貝；
所以，這個(gè)過程之中，只進(jìn)行了 2 次數(shù)據(jù)拷貝，如下圖：
這就是所謂的零拷貝（Zero-copy）技術(shù)，因?yàn)槲覀儧]有在內(nèi)存層面去拷貝數(shù)據(jù)，也就是說全程沒有通過 CPU 來搬運(yùn)數(shù)據(jù)，所有的數(shù)據(jù)都是通過 DMA 來進(jìn)行傳輸?shù)?。?/p>
零拷貝技術(shù)的文件傳輸方式相比傳統(tǒng)文件傳輸?shù)姆绞?，減少了 2 次上下文切換和數(shù)據(jù)拷貝次數(shù)，只需要 2 次上下文切換和數(shù)據(jù)拷貝次數(shù)，就可以完成文件的傳輸，而且 2 次的數(shù)據(jù)拷貝過程，都不需要通過 CPU，2 次都是由 DMA 來搬運(yùn)。
所以，總體來看，零拷貝技術(shù)可以把文件傳輸?shù)男阅芴岣咧辽僖槐兑陨稀?/p>
事實(shí)上，Kafka這個(gè)開源項(xiàng)目，就利用了「零拷貝」技術(shù)，從而大幅提升了I/O的吞吐率，這也是Kafka在處理海量數(shù)據(jù)為什么這么快的原因之一。
如果你追溯Kafka文件傳輸?shù)拇a，你會(huì)發(fā)現(xiàn)，最終它調(diào)用了Java NIO庫里的transferTo方法：
@Override
public long transferFrom(FileChannel fileChannel, long position, long count) throws IOException {
return fileChannel.transferTo(position, count, socketChannel);
}如果Linux系統(tǒng)支持sendfile()系統(tǒng)調(diào)用，那么transferTo()實(shí)際上最后就會(huì)使用到sendfile()系統(tǒng)調(diào)用函數(shù)。
曾經(jīng)有大佬專門寫過程序測(cè)試過，在同樣的硬件條件下，傳統(tǒng)文件傳輸和零拷拷貝文件傳輸?shù)男阅懿町?，你可以看到下面這張測(cè)試數(shù)據(jù)圖，使用了零拷貝能夠縮短 65% 的時(shí)間，大幅度提升了機(jī)器傳輸數(shù)據(jù)的吞吐量。
另外，Nginx 也支持零拷貝技術(shù)，一般默認(rèn)是開啟零拷貝技術(shù)，這樣有利于提高文件傳輸?shù)男?，是否開啟零拷貝技術(shù)的配置如下：
http {
...
sendfile on
...
}sendfile 配置的具體意思:
設(shè)置為 on 表示，使用零拷貝技術(shù)來傳輸文件：sendfile ，這樣只需要 2 次上下文切換，和 2 次數(shù)據(jù)拷貝。
設(shè)置為 off 表示，使用傳統(tǒng)的文件傳輸技術(shù)：read + write，這時(shí)就需要 4 次上下文切換，和 4 次數(shù)據(jù)拷貝。
當(dāng)然，要使用 sendfile，Linux 內(nèi)核版本必須要 2.1 以上的版本。
回顧前面說道文件傳輸過程，其中第一步都是先需要先把磁盤文件數(shù)據(jù)拷貝「內(nèi)核緩沖區(qū)」里，這個(gè)「內(nèi)核緩沖區(qū)」實(shí)際上是磁盤高速緩存（PageCache）。
由于零拷貝使用了 PageCache 技術(shù)，可以使得零拷貝進(jìn)一步提升了性能，我們接下來看看 PageCache 是如何做到這一點(diǎn)的。
讀寫磁盤相比讀寫內(nèi)存的速度慢太多了，所以我們應(yīng)該想辦法把「讀寫磁盤」替換成「讀寫內(nèi)存」。于是，我們會(huì)通過 DMA 把磁盤里的數(shù)據(jù)搬運(yùn)到內(nèi)存里，這樣就可以用讀內(nèi)存替換讀磁盤。
但是，內(nèi)存空間遠(yuǎn)比磁盤要小，內(nèi)存注定只能拷貝磁盤里的一小部分?jǐn)?shù)據(jù)。
那問題來了，選擇哪些磁盤數(shù)據(jù)拷貝到內(nèi)存呢？
我們都知道程序運(yùn)行的時(shí)候，具有「局部性」，所以通常，剛被訪問的數(shù)據(jù)在短時(shí)間內(nèi)再次被訪問的概率很高，于是我們可以用 PageCache 來緩存最近被訪問的數(shù)據(jù)，當(dāng)空間不足時(shí)淘汰最久未被訪問的緩存。
所以，讀磁盤數(shù)據(jù)的時(shí)候，優(yōu)先在 PageCache 找，如果數(shù)據(jù)存在則可以直接返回；如果沒有，則從磁盤中讀取，然后緩存 PageCache 中。
還有一點(diǎn)，讀取磁盤數(shù)據(jù)的時(shí)候，需要找到數(shù)據(jù)所在的位置，但是對(duì)于機(jī)械磁盤來說，就是通過磁頭旋轉(zhuǎn)到數(shù)據(jù)所在的扇區(qū)，再開始「順序」讀取數(shù)據(jù)，但是旋轉(zhuǎn)磁頭這個(gè)物理動(dòng)作是非常耗時(shí)的，為了降低它的影響，PageCache 使用了「預(yù)讀功能」。
比如，假設(shè) read 方法每次只會(huì)讀 32 KB 的字節(jié)，雖然 read 剛開始只會(huì)讀 0 ～ 32 KB 的字節(jié)，但內(nèi)核會(huì)把其后面的 32～64 KB 也讀取到 PageCache，這樣后面讀取 32～64 KB 的成本就很低，如果在 32～64 KB 淘汰出 PageCache 前，進(jìn)程讀取到它了，收益就非常大。
所以，PageCache 的優(yōu)點(diǎn)主要是兩個(gè)：
緩存最近被訪問的數(shù)據(jù)；
預(yù)讀功能；
這兩個(gè)做法，將大大提高讀寫磁盤的性能。
但是，在傳輸大文件（GB 級(jí)別的文件）的時(shí)候，PageCache 會(huì)不起作用，那就白白浪費(fèi) DMA 多做的一次數(shù)據(jù)拷貝，造成性能的降低，即使使用了 PageCache 的零拷貝也會(huì)損失性能
這是因?yàn)槿绻阌泻芏?GB 級(jí)別文件需要傳輸，每當(dāng)用戶訪問這些大文件的時(shí)候，內(nèi)核就會(huì)把它們載入 PageCache 中，于是 PageCache 空間很快被這些大文件占滿。
另外，由于文件太大，可能某些部分的文件數(shù)據(jù)被再次訪問的概率比較低，這樣就會(huì)帶來 2 個(gè)問題：
PageCache 由于長(zhǎng)時(shí)間被大文件占據(jù)，其他「熱點(diǎn)」的小文件可能就無法充分使用到 PageCache，于是這樣磁盤讀寫的性能就會(huì)下降了；
PageCache 中的大文件數(shù)據(jù)，由于沒有享受到緩存帶來的好處，但卻耗費(fèi)DMA多拷貝到PageCache一次；
所以，針對(duì)大文件的傳輸，不應(yīng)該使用PageCache，也就是說不應(yīng)該使用零拷貝技術(shù)，因?yàn)榭赡苡捎赑ageCache被大文件占據(jù)，而導(dǎo)致「熱點(diǎn)」小文件無法利用到PageCache，這樣在高并發(fā)的環(huán)境下，會(huì)帶來嚴(yán)重的性能問題。
繞開 PageCache 的 I/O 叫直接 I/O，使用 PageCache 的 I/O 則叫緩存 I/O。通常，對(duì)于磁盤，異步 I/O 只支持直接 I/O。
前面也提到，大文件的傳輸不應(yīng)該使用 PageCache，因?yàn)榭赡苡捎?PageCache 被大文件占據(jù)，而導(dǎo)致「熱點(diǎn)」小文件無法利用到 PageCache。
于是，在高并發(fā)的場(chǎng)景下，針對(duì)大文件的傳輸?shù)姆绞?，?yīng)該使用「異步 I/O + 直接 I/O」來替代零拷貝技術(shù)。
直接 I/O 應(yīng)用場(chǎng)景常見的兩種：
應(yīng)用程序已經(jīng)實(shí)現(xiàn)了磁盤數(shù)據(jù)的緩存，那么可以不需要 PageCache 再次緩存，減少額外的性能損耗。在 MySQL 數(shù)據(jù)庫中，可以通過參數(shù)設(shè)置開啟直接 I/O，默認(rèn)是不開啟；
傳輸大文件的時(shí)候，由于大文件難以命中 PageCache 緩存，而且會(huì)占滿 PageCache 導(dǎo)致「熱點(diǎn)」文件無法充分利用緩存，從而增大了性能開銷，因此，這時(shí)應(yīng)該使用直接 I/O。
另外，由于直接 I/O 繞過了 PageCache，就無法享受內(nèi)核的這兩點(diǎn)的優(yōu)化：
內(nèi)核的 I/O 調(diào)度算法會(huì)緩存盡可能多的 I/O 請(qǐng)求在 PageCache 中，最后「合并」成一個(gè)更大的 I/O 請(qǐng)求再發(fā)給磁盤，這樣做是為了減少磁盤的尋址操作；
內(nèi)核也會(huì)「預(yù)讀」后續(xù)的 I/O 請(qǐng)求放在 PageCache 中，一樣是為了減少對(duì)磁盤的操作；
于是，傳輸大文件的時(shí)候，使用「異步 I/O + 直接 I/O」了，就可以無阻塞地讀取文件了。
所以，傳輸文件的時(shí)候，我們要根據(jù)文件的大小來使用不同的方式：
傳輸大文件的時(shí)候，使用「異步 I/O + 直接 I/O」；
傳輸小文件的時(shí)候，則使用「零拷貝技術(shù)」；
在 nginx 中，我們可以用如下配置，來根據(jù)文件的大小來使用不同的方式：
location /video/ {
sendfile on;
aio on;
directio 1024m;
}當(dāng)文件大小大于directio值后，使用「異步I/O+直接I/O」，否則使用「零拷貝技術(shù)」。
早期 I/O 操作，內(nèi)存與磁盤的數(shù)據(jù)傳輸?shù)墓ぷ鞫际怯?CPU 完成的，而此時(shí) CPU 不能執(zhí)行其他任務(wù)，會(huì)特別浪費(fèi) CPU 資源。
于是，為了解決這一問題，DMA 技術(shù)就出現(xiàn)了，每個(gè) I/O 設(shè)備都有自己的 DMA 控制器，通過這個(gè) DMA 控制器，CPU 只需要告訴 DMA 控制器，我們要傳輸什么數(shù)據(jù)，從哪里來，到哪里去，就可以放心離開了。后續(xù)的實(shí)際數(shù)據(jù)傳輸工作，都會(huì)由 DMA 控制器來完成，CPU 不需要參與數(shù)據(jù)傳輸?shù)墓ぷ鳌?/p>
傳統(tǒng) IO 的工作方式，從硬盤讀取數(shù)據(jù)，然后再通過網(wǎng)卡向外發(fā)送，我們需要進(jìn)行 4 上下文切換，和 4 次數(shù)據(jù)拷貝，其中 2 次數(shù)據(jù)拷貝發(fā)生在內(nèi)存里的緩沖區(qū)和對(duì)應(yīng)的硬件設(shè)備之間，這個(gè)是由 DMA 完成，另外 2 次則發(fā)生在內(nèi)核態(tài)和用戶態(tài)之間，這個(gè)數(shù)據(jù)搬移工作是由 CPU 完成的。
為了提高文件傳輸?shù)男阅?，于是就出現(xiàn)了零拷貝技術(shù)，它通過一次系統(tǒng)調(diào)用（sendfile 方法）合并了磁盤讀取與網(wǎng)絡(luò)發(fā)送兩個(gè)操作，降低了上下文切換次數(shù)。另外，拷貝數(shù)據(jù)都是發(fā)生在內(nèi)核中的，天然就降低了數(shù)據(jù)拷貝的次數(shù)。
Kafka 和 Nginx 都有實(shí)現(xiàn)零拷貝技術(shù)，這將大大提高文件傳輸?shù)男阅堋?/p>
零拷貝技術(shù)是基于 PageCache 的，PageCache 會(huì)緩存最近訪問的數(shù)據(jù)，提升了訪問緩存數(shù)據(jù)的性能，同時(shí)，為了解決機(jī)械硬盤尋址慢的問題，它還協(xié)助 I/O 調(diào)度算法實(shí)現(xiàn)了 IO 合并與預(yù)讀，這也是順序讀比隨機(jī)讀性能好的原因。這些優(yōu)勢(shì)，進(jìn)一步提升了零拷貝的性能。
需要注意的是，零拷貝技術(shù)是不允許進(jìn)程對(duì)文件內(nèi)容作進(jìn)一步的加工的，比如壓縮數(shù)據(jù)再發(fā)送。
另外，當(dāng)傳輸大文件時(shí)，不能使用零拷貝，因?yàn)榭赡苡捎?PageCache 被大文件占據(jù)，而導(dǎo)致「熱點(diǎn)」小文件無法利用到 PageCache，并且大文件的緩存命中率不高，這時(shí)就需要使用「異步 IO + 直接 IO 」的方式。
在 Nginx 里，可以通過配置，設(shè)定一個(gè)文件大小閾值，針對(duì)大文件使用異步 IO 和直接 IO，而對(duì)小文件使用零拷貝。
聯(lián)系客服
