零拷貝并非萬能解決方案：重新定義數(shù)據(jù)傳輸?shù)男蕵O限
/ PageCache 有什么作用？ /
在我們前面講解零拷貝的內(nèi)容時，我們了解到一個重要的概念，即內(nèi)核緩沖區(qū)。那么，你可能會好奇內(nèi)核緩沖區(qū)到底是什么？這個專有名詞就是 PageCache，也被稱為磁盤高速緩存。也可以看下 windows 下的緩存區(qū)：如圖所示：
圖片
零拷貝進一步提升性能的原因在于 PageCache 技術的使用。接下來，我們將詳細探討 PageCache 技術是如何實現(xiàn)這一目標的。
讀寫磁盤相比讀寫內(nèi)存的速度慢太多了，但我們可以采取一種方法來改善這個問題，即將磁盤數(shù)據(jù)部分緩存到內(nèi)核中，也就是將其存儲在 PageCache 緩存區(qū)中。這個過程實際上是通過 DMA（直接內(nèi)存訪問）控制器將磁盤數(shù)據(jù)拷貝到內(nèi)核緩沖區(qū)中。
然而，需要注意的是，由于內(nèi)存空間較磁盤空間有限，因此存在一系列算法來確保 pageCache 占用的內(nèi)存空間不過大。我們在程序運行時都知道存在一種「局部性」，即剛剛被訪問的數(shù)據(jù)在短時間內(nèi)很可能再次被訪問到，概率很高。因此，pageCache 被用作緩存最近訪問的數(shù)據(jù)。可以將 pageCache 看作是 Redis，而磁盤則類似于 MySQL。此外，pageCache 還使用了內(nèi)存淘汰機制，在內(nèi)存空間不足時，會淘汰最近最久未被訪問的緩存。
當在項目中使用 Redis 時，你一定知道如何使用它。和 Redis 類似， PageCache 的工作原理也是一樣的。在進程需要訪問數(shù)據(jù)時，它會首先檢查 PageCache 是否已經(jīng)存儲了所需的數(shù)據(jù)。如果數(shù)據(jù)已經(jīng)存在于 PageCache 中，內(nèi)核會直接返回數(shù)據(jù)；如果數(shù)據(jù)未被緩存，則會從磁盤讀取并將數(shù)據(jù)緩存到 PageCache 中，以備下次查詢時使用。這種方式可以有效提高訪問效率。
然而，pageCache 還具有另一個優(yōu)點，即預讀功能。當訪問并讀取磁盤數(shù)據(jù)時，實際上需要定位磁盤中的位置。對于機械硬盤而言，這意味著磁頭必須旋轉(zhuǎn)到數(shù)據(jù)所在的扇區(qū)位置，然后開始順序讀取數(shù)據(jù)。然而，旋轉(zhuǎn)磁頭這種物理操作對計算機而言非常耗時。為了降低其影響，就出現(xiàn)了預讀功能。通過預讀功能，可以提前預讀下一扇區(qū)的數(shù)據(jù)，減少等待磁頭旋轉(zhuǎn)的時間。
比如 read 方法需要讀取 32KB 的字節(jié)的數(shù)據(jù)，使其在讀取 32KB 字節(jié)數(shù)據(jù)后，繼續(xù)讀取后面的 32-64KB，并將這一塊數(shù)據(jù)一起緩存到 pageCache 緩沖區(qū)。這樣做的好處在于，如果后續(xù)讀取需要的數(shù)據(jù)在這塊緩存中命中，那么讀取成本會大幅降低。可以類比于 redis 中提前緩存一部分分布式唯一 id 用于插入數(shù)據(jù)庫時的分配操作，這樣就無需每次插入前都去獲取一遍 id。然而，一般情況下，為了避免可能出現(xiàn)的"毛刺"現(xiàn)象，我們通常會使用雙緩存機制來處理。這個雙緩存機制可以進一步優(yōu)化讀取操作的效果。
因此，PageCache 的優(yōu)點主要包括兩個方面：首先，它能夠?qū)?shù)據(jù)緩存到 PageCache 中；其次，它還利用了數(shù)據(jù)的預讀功能。這兩個操作極大地增強了讀寫磁盤時的性能。
但是，你可以想象一下如果你在傳輸大文件時比如好幾個 G 的文件，如果還是使用零拷貝技術，內(nèi)核還是會把他們放入 pageCache 緩存區(qū)，那這樣不就產(chǎn)生問題了嗎？你也可以想一下如果你往 redis 緩存中放了一個還幾個 G 大小的 value，而且還知道緩存了也沒用，那不就相當于 redis 形同虛設了嗎？把其他熱點數(shù)據(jù)也弄沒了，所以 pageCache 也有這樣的一個問題，一是大文件搶占了 pageCache 的內(nèi)存大小，這樣做會導致其他熱點數(shù)據(jù)無法存儲在 pageCache 緩沖區(qū)中，從而降低磁盤的讀寫性能。此外，由于 pageCache 無法享受到緩存的好處，還會產(chǎn)生一個 DMA 數(shù)據(jù)拷貝的過程。
因此，最佳的優(yōu)化方法是針對大文件傳輸時不使用 pageCache，也就是不使用零拷貝技術。這是因為零拷貝技術會占用大量的內(nèi)存空間，影響其他熱點數(shù)據(jù)的訪問優(yōu)化。在高并發(fā)環(huán)境下，這幾乎肯定會導致嚴重的性能問題。
/ 大文件傳輸用什么方式實現(xiàn)？ /
那針對大文件的傳輸，我們應該使用什么方式呢？
讓我們首先來觀察最初的示例。當調(diào)用 read 方法讀取文件時，進程實際上會被阻塞在 read 方法的調(diào)用處，因為它需要等待磁盤數(shù)據(jù)的返回。如下圖所示：
圖片
在沒有使用零拷貝技術的情況下，我們的用戶進程使用同步 IO 的方式，它會一直阻塞等待系統(tǒng)調(diào)用返回數(shù)據(jù)。讓我們回顧一下之前的具體流程：
- 應用程序發(fā)起 read 系統(tǒng)調(diào)用，用戶進程開始進行阻塞等待結(jié)果返回。
- 此時內(nèi)核會向磁盤發(fā)起 I/O 請求，磁盤收到請求后，開始尋址。當磁盤數(shù)據(jù)準備好后，就會向內(nèi)核發(fā)起 I/O 中斷，告知內(nèi)核磁盤數(shù)據(jù)已經(jīng)準備好。
- 內(nèi)核收到中斷信號后，將數(shù)據(jù)從磁盤控制器緩存區(qū)拷貝到 pageCache 緩沖區(qū)。
- 最后，內(nèi)核會將 pageCache 中的數(shù)據(jù)再次拷貝到用戶緩沖區(qū)，也就是用戶態(tài)的內(nèi)存中，然后 read 調(diào)用返回。
我們知道，既然有同步 IO，就一定有異步 IO 來解決阻塞的問題。異步 IO 的工作方式如下圖所示：
圖片
它將讀操作分為兩個部分：
- 第一部分是用戶進程發(fā)起 IO 請求給內(nèi)核，然后進程就不再關心該 IO 操作，而是繼續(xù)處理其他任務。
- 第二部分是當內(nèi)核接收到中斷信號后，將數(shù)據(jù)直接拷貝到用戶緩沖區(qū)，并通知用戶進程操作成功。然后用戶進程開始處理數(shù)據(jù)。
我們發(fā)現(xiàn)在這個過程中，并沒有涉及到將數(shù)據(jù)拷貝到 pageCache 中，因此使用異步方式繞開了 pageCache。直接 IO 是指繞過 pageCache 的 IO 請求，而緩存 IO 是指使用 pageCache 的 IO 請求。通常，對于磁盤而言，異步 IO 只支持直接 IO。
正如前面所提到的，對于大文件的傳輸，不應該使用 PageCache，因為這可能會導致 PageCache 被大文件占據(jù)，從而使得"熱點"小文件無法充分利用 PageCache 的優(yōu)勢。
因此，在高并發(fā)的場景下，對于大文件傳輸，我們應該采用"異步 I/O + 直接 I/O"的方式來代替零拷貝技術。
直接 I/O 有兩種常見的應用場景：
- 首先，如果應用程序已經(jīng)實現(xiàn)了磁盤數(shù)據(jù)的緩存，就不需要再次使用 PageCache 進行緩存，這樣可以減少額外的性能損耗。例如，在 MySQL 數(shù)據(jù)庫中，可以通過參數(shù)設置來開啟直接 I/O，避免重復的緩存操作，默認情況下是不開啟的。
- 其次，在傳輸大文件時，由于大文件很難命中 PageCache 的緩存，而且會占滿 PageCache 導致"熱點"文件無法充分利用緩存，增加了性能開銷。因此，在這種情況下，應該使用直接 I/O 來繞過 PageCache 的緩存，以提高性能。
需要注意的是，直接 I/O 繞過了 PageCache，因此無法享受內(nèi)核的兩項優(yōu)化。
- 首先，內(nèi)核的 I/O 調(diào)度算法會在 PageCache 中緩存盡可能多的 I/O 請求，然后將它們合并成一個更大的 I/O 請求發(fā)送給磁盤，以減少磁盤的尋址操作。
- 其次，內(nèi)核會預讀后續(xù)的 I/O 請求并將其放入 PageCache 中，同樣是為了減少對磁盤的操作。這些優(yōu)化在直接 I/O 中無法享受到。
于是，當我們需要傳輸大文件時，我們可以利用異步 I/O 和直接 I/O 的組合來實現(xiàn)無阻塞的文件讀取。這種方式可以有效避免 PageCache 的影響，提高文件傳輸?shù)男省?/p>
因此，在文件傳輸過程中，我們可以根據(jù)文件的大小來選擇不同的優(yōu)化方式，以提高傳輸效率。對于大文件，使用異步 I/O 和直接 I/O 可以避免 PageCache 的影響；而對于小文件，則可以使用零拷貝技術來減少數(shù)據(jù)拷貝次數(shù)，提高傳輸速度。
在 Nginx 中，我們可以通過以下配置來根據(jù)文件的大小選擇不同的優(yōu)化方式：
location /video/ {
sendfile on;
aio on;
directio 1024m;
}在這個配置中，我們開啟了 sendfile 選項，這允許 Nginx 使用零拷貝技術來傳輸文件。同時，我們也啟用了 aio 選項，這使得 Nginx 可以使用異步 I/O 來提高文件傳輸?shù)男省?/p>
而通過設置 directio 參數(shù)為 1024m，我們告訴 Nginx 當文件大小超過 1024MB 時，使用直接 I/O 來進行文件傳輸。這意味著在傳輸大文件時，Nginx 將使用異步 I/O 和直接 I/O 的組合來實現(xiàn)無阻塞的文件讀取，避免了 PageCache 的影響。而對于小文件，Nginx 將繼續(xù)使用零拷貝技術，以減少數(shù)據(jù)拷貝次數(shù)，提高傳輸速度。
/ 總結(jié) /
至此，我們的計算機基礎專欄就結(jié)束了，不知道大家有沒有發(fā)現(xiàn)，操作系統(tǒng)底層提供了豐富的解決方案來支持應用程序的復雜性和可擴展性。對于任何工作中遇到的問題，我們都可以從操作系統(tǒng)的角度尋找解決方法。
今天這一篇其實就是來打破零拷貝的方案神話的，沒有一種技術是最好的，只有最合適的方法。我們需要根據(jù)具體的需求和情況來選擇適合的解決方案，以提高應用程序的性能和可擴展性。謝謝大家的閱讀和關注，希望這個專欄能對大家有所啟發(fā)和幫助！
