對標蘋果的靈動島 華為帶來實況窗功能
繼蘋果的靈動島之后，華為也在今天正式推出了“實況窗”功能。據今天鴻蒙OS 4.0的現場演示顯示，華為的實況窗可以更高效的展現出實時通知，比如鎖屏上就能看到外賣、打車、銀行
在我們前面講解零拷貝的內容時，我們了解到一個重要的概念，即內核緩沖區。那么，你可能會好奇內核緩沖區到底是什么？這個專有名詞就是 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 的工作方式如下圖所示：
圖片
它將讀操作分為兩個部分：
我們發現在這個過程中，并沒有涉及到將數據拷貝到 pageCache 中，因此使用異步方式繞開了 pageCache。直接 IO 是指繞過 pageCache 的 IO 請求，而緩存 IO 是指使用 pageCache 的 IO 請求。通常，對于磁盤而言，異步 IO 只支持直接 IO。
正如前面所提到的，對于大文件的傳輸，不應該使用 PageCache，因為這可能會導致 PageCache 被大文件占據，從而使得"熱點"小文件無法充分利用 PageCache 的優勢。
因此，在高并發的場景下，對于大文件傳輸，我們應該采用"異步 I/O + 直接 I/O"的方式來代替零拷貝技術。
直接 I/O 有兩種常見的應用場景：
需要注意的是，直接 I/O 繞過了 PageCache，因此無法享受內核的兩項優化。
于是，當我們需要傳輸大文件時，我們可以利用異步 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 將繼續使用零拷貝技術，以減少數據拷貝次數，提高傳輸速度。
至此，我們的計算機基礎專欄就結束了，不知道大家有沒有發現，操作系統底層提供了豐富的解決方案來支持應用程序的復雜性和可擴展性。對于任何工作中遇到的問題，我們都可以從操作系統的角度尋找解決方法。
今天這一篇其實就是來打破零拷貝的方案神話的，沒有一種技術是最好的，只有最合適的方法。我們需要根據具體的需求和情況來選擇適合的解決方案，以提高應用程序的性能和可擴展性。謝謝大家的閱讀和關注，希望這個專欄能對大家有所啟發和幫助！
本文鏈接：http://www.www897cc.com/showinfo-26-10483-0.html零拷貝并非萬能解決方案：重新定義數據傳輸的效率極限
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號