本文討論了零拷貝在優化數據傳輸效率方面的局限性。儘管零拷貝技術在減少數據傳輸過程中的記憶體拷貝次數方面有很大的優勢，但它並非適用於所有情況。文章介紹了一些其他的優化方法，如非同步I/O和直接I/O的組合、根據文件大小選擇不同的優化方式。至此，我們的電腦基礎專欄就結束了，不知道大家有沒有發現，操作系統底... ...
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將繼續使用零拷貝技術，以減少數據拷貝次數，提高傳輸速度。
總結
至此，我們的電腦基礎專欄就結束了，不知道大家有沒有發現，操作系統底層提供了豐富的解決方案來支持應用程式的複雜性和可擴展性。對於任何工作中遇到的問題，我們都可以從操作系統的角度尋找解決方法。
今天這一篇其實就是來打破零拷貝的方案神話的，沒有一種技術是最好的，只有最合適的方法。我們需要根據具體的需求和情況來選擇適合的解決方案，以提高應用程式的性能和可擴展性。謝謝大家的閱讀和關註，希望這個專欄能對大家有所啟發和幫助！
也請期待我的下一個專欄：【電腦網路篇】
