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