資訊專欄INFORMATION COLUMN
摘要：而每個文件系統(tǒng)又可以設(shè)置不同的調(diào)度算法，另外，還有虛擬內(nèi)存缺頁中斷帶來的性能毛刺良心的提供了調(diào)優(yōu)的腳本，這點做的不錯跑題了。測試環(huán)境核線程內(nèi)存磁盤讀寫左右虛擬內(nèi)存未關(guān)閉，大小測試注意點為了防止緩存的影響，每次都生成一個新的文件進行讀取。
前言
Java 在 JDK 1.4 引入了 ByteBuffer 等 NIO 相關(guān)的類，使得 Java 程序員可以拋棄基于 Stream ，從而使用基于 Block 的方式讀寫文件，另外，JDK 還引入了 IO 性能優(yōu)化之王—— 零拷貝 sendFile 和 mmap。但他們的性能究竟怎么樣？ 和 RandomAccessFile 比起來，快多少？ 什么情況下快？到底是 FileChannel 快還是 MappedByteBuffer 快......
(零拷貝參考 Zero Copy I: User-Mode Perspective)
天啊，問題太多了！?。。。?！
讓我們慢慢分析。
看看善于利用 IO 零拷貝的 MQ 們我們知道，Java 世界有很多 MQ：ActiveMQ，kafka，RocketMQ，去哪兒 MQ，而他們則是 Java 世界使用 NIO 零拷貝的大戶。
然而，他們的性能卻大相同，拋開其他的因素，例如網(wǎng)絡(luò)傳輸方式，數(shù)據(jù)結(jié)構(gòu)設(shè)計，文件存儲方式，我們僅僅討論 Broker 端對文件的讀寫，看看他們有什么不同。
下圖是樓主查看源碼總結(jié)的各個 MQ 使用的文件讀寫方式。
kafka：record 的讀寫都是基于 FileChannel。index 讀寫基于 MMAP（廝大提示）。
RocketMQ：讀盤基于 MMAP，寫盤默認使用 MMAP，可通過修改配置，配置成 FileChannel，原因是作者想避免 PageCache 的鎖競爭，通過兩層架構(gòu)實現(xiàn)讀寫分離。
QMQ： 去哪兒 MQ，讀盤使用 MMAP，寫盤使用 FileChannel。
ActiveMQ 5.15： 讀寫全部都是基于 RandomAccessFile，這也是我們拋棄 ActiveMQ 的原因。
那么，到底是 MMAP 強，還是 FileChannel 強？
MMAP 眾所周知，基于 OS 的 mmap 的內(nèi)存映射技術(shù)，通過 MMU 映射文件，使隨機讀寫文件和讀寫內(nèi)存相似的速度。
那 FileChannel 呢？是零拷貝嗎？很遺憾，不是。FileChannel 快，只是因為他是基于 block 的。
接下來，benchmark everything —— 徐媽.
Benchmark ？如何 Benchmark？ Benchmark 哪些？
既然是讀寫文件，自然就要看讀寫性能，這是最基本的。但，注意，通常 MQ 會使用定時刷盤，防止數(shù)據(jù)丟失，MMAP 和 FileChannel 都有 force 方法，用于將 pageCache 的數(shù)據(jù)刷到硬盤上。force 會影響性能嗎？ 答案是會。影響到什么程度呢？ 不知道。每次寫入的數(shù)據(jù)大小會影響性能嗎，毫無疑問會，但規(guī)則是什么呢？FileOutputStream 真的一無是處嗎？答案是不一定。
一直以來，文件調(diào)優(yōu)都是藝術(shù)，因為影響性能的因素太多，首先，SSD 的出現(xiàn)，已經(jīng)讓傳統(tǒng)基于 B+ tree 的樹形結(jié)構(gòu)產(chǎn)生了自我疑問，第二，每個文件系統(tǒng)的性能不同，Linux ext3 和 ext4 性能天壤之別（刪除文件的性能差距在 20 倍左右）。而 Max OS 的 HFS+ 系統(tǒng)被 Linus 稱之為“有史以來最垃圾的文件系統(tǒng)”，幸運的是，蘋果終于在 2017 年推送了 macOS High Sierra 和 iOS 10.3 系統(tǒng)，這個兩個系統(tǒng)都拋棄了 HFS+，換成了性能更高的 APFS。而每個文件系統(tǒng)又可以設(shè)置不同的調(diào)度算法，另外，還有虛擬內(nèi)存缺頁中斷帶來的性能毛刺.......
（tips：良心的 RocketMQ 提供了 Linux IO 調(diào)優(yōu)的腳本，這點做的不錯 ：）
跑題了。
樓主寫了一個小項目，用于測試 Java MappedByteBuffer & FileChannel & RandomAccessFile & FileXXXputStream 的讀寫性能。大家也可以在自己的機器上跑跑看。
測試環(huán)境CPU：intel i7 4核8線程 4.2GHz
內(nèi)存：40GB DDR4
磁盤：SSD 讀寫 2GB/s 左右
JDK1.8
OS：Mac OS 10.13.6
虛擬內(nèi)存： 未關(guān)閉，大小 9GB
測試注意點：
為了防止 PageCache 緩存的影響，每次都生成一個新的文件進行讀取。
為了測試不同數(shù)據(jù)包對性能的影響，需要使用不同大小的數(shù)據(jù)包進行多次測試。
force 對性能影響很大，應(yīng)該多帶帶測試。
使用 1GB 文件進行測試（小文件沒有參考意義，大文件 mmap 無法映射）
純粹讀測試1GB 文件：
測試 MappedByteBuffer & FileChannel & RandomAccessFile & FileInputStream.
從這張圖里，我們看到，mmap 性能完勝，特別是在小數(shù)據(jù)量的情況下。其他的流，只有在4kb 的情況下，才開始反殺 mmap。因此，讀 4kb 以下的數(shù)據(jù)，請使用 mmap。
再放大看看 mmap 和 FileChannel 的比較：
根據(jù)上圖，我們看到，在寫入數(shù)據(jù)包大于 4kb 以上的情況下，F(xiàn)ileChannel 等一眾非零拷貝，基本完勝 mmap，除了那個一次讀 1G 文件的 BT 測試。
因此，如果你的數(shù)據(jù)包大于 4kb，請使用 FileChannel。
純粹寫測試1GB 文件：
測試 MappedByteBuffer & FileChannel & RandomAccessFile & FileInputStream.
從上圖，我們可以看出，mmap 性能還是一樣的穩(wěn)定。FileChannel 也不差，但是在 32 字節(jié)數(shù)據(jù)量的情況下，還差點意思。
再看縮略圖：
我們看到，64字節(jié) 是 FileChannel 和 mmap 性能的分水嶺，從 64字節(jié)開始，F(xiàn)ileChannel 一路反殺，直到 BT 1GB 文件稍稍輸了一丟丟。
因此，我們建議：如果你的數(shù)據(jù)包大小在 64 字節(jié)以上，請使用 FileChannel 寫入。
異步 force 測試我們知道，RocketMQ 使用異步刷盤，那么異步 force 對性能有沒有影響呢？benchmark everything。我們使用異步線程，每 16kb 刷盤一次，看看性能如何。
mmap 一直落后，且性能很差，除了在 2048 字節(jié)那里有一點點抖動，基本維持 在 4000 左右，而沒有 force 的情況下，則在 1500 左右。而 FileChannel 則完全不受 force 的影響。在我的測試中，1GB 的文件，一次 force 需要 800 毫秒左右。buffer 越大，時間越多，反之則越小。
說個題外話，Kafka 一直不建議使用 force，大概也有這個原因。當然，Kafka 還有自己的多副本策略保證數(shù)據(jù)安全。
這里，我們得出結(jié)論，如果你需要經(jīng)常執(zhí)行 force，即使是異步的，也請一定不要使用 mmap，請使用 FileChannel。
總結(jié)。基于以上測試，我們得出一張圖表：
假設(shè)，我們的系統(tǒng)的數(shù)據(jù)包在 1024 - 2048 左右，我們應(yīng)該使用什么策略？
答：讀使用 mmap，僅僅寫使用 FileChannel。
再回過頭看看 MQ 的實現(xiàn)者們，似乎只有 QMQ 是 這么做的。當然，RocketMQ 也提供了 FileChannel 的寫選項。但默認 mmap 寫加異步刷盤，應(yīng)該是 broker busy 的元兇吧。
而 Kafka，因為默認不 force，也是使用 FileChannel 進行寫入的，為什么使用 FileChannel 讀呢？大概是因為消息的大小在 4kb 以上吧。
這樣一揣測，這些 MQ 的設(shè)計似乎都非常合理。
最后，能不用 force 就別用 force。如果要用 force ，就請使用 FileChannel。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/77634.html
摘要：與此同時，因新冠疫情的影響使得用戶對移動應(yīng)用程序的需求激增。調(diào)查報告顯示年移動應(yīng)用程序已經(jīng)產(chǎn)生了億美元的收入，預(yù)計到年將產(chǎn)生億美元的收入。 引言 計劃在2021年進...
摘要：關(guān)于中順序的基本操作關(guān)于中順序的基本操作寫在前面最近研究一下中的順序，在網(wǎng)絡(luò)上找了一會兒，發(fā)現(xiàn)少有詳細的介紹，顧此在此處說說順序，才學疏淺，如有不對，望賜教。上述代碼中標記位置中，返回下一次操作時的位置。關(guān)于JAVA中順序IO的基本操作 寫在前面 最近研究一下JAVA中的順序IO，在網(wǎng)絡(luò)上找了一會兒，發(fā)現(xiàn)少有詳細的介紹，顧此在此處說說順序IO，才學疏淺，如有不對，望賜...
摘要：此處補充說明下，不論是還是都不提供指定區(qū)間的刷盤策略，只提供一個方法，所以無法精確控制落盤數(shù)據(jù)的大小。一、概述由前文可知，RocketMQ有幾個非常重要的概念：broker 服務(wù)端，負責存儲、收發(fā)消息producer 客戶端1，負責產(chǎn)生消息consumer 客服端2，負責消費消息既然是消息隊列，那消息的存儲的重要程度不言而喻，本節(jié)我們聚焦broker服務(wù)端，看下消息在broker端是如何存儲...
摘要：前言從字面意思理解就是數(shù)據(jù)不需要來回的拷貝，大大提升了系統(tǒng)的性能這個詞我們也經(jīng)常在，，，等框架中聽到，經(jīng)常作為其提升性能的一大亮點下面從的幾個概念開始，進而在分析零拷貝。 前言 從字面意思理解就是數(shù)據(jù)不需要來回的拷貝，大大提升了系統(tǒng)的性能；這個詞我們也經(jīng)常在java nio，netty，kafka，RocketMQ等框架中聽到，經(jīng)常作為其提升性能的一大亮點；下面從I/O的幾個概念開始，...
摘要：壓縮文件從秒到秒的優(yōu)化過程有一個需求需要將前端傳過來的張照片，然后后端進行處理以后壓縮成一個壓縮包通過網(wǎng)絡(luò)流傳輸出去。源碼如下使用映射文件開始時間內(nèi)存中的映射文件打印如下可以看到速度和使用的速度差不多的。 壓縮20M文件從30秒到1秒的優(yōu)化過程 有一個需求需要將前端傳過來的10張照片，然后后端進行處理以后壓縮成一個壓縮包通過網(wǎng)絡(luò)流傳輸出去。之前沒有接觸過用Java壓縮文件的，所以就直接...
閱讀 2013·2021-11-15 18:09
閱讀 908·2021-09-06 15:13
閱讀 2646·2021-08-23 09:43
閱讀 2030·2019-08-30 15:54
閱讀 2225·2019-08-30 13:56
閱讀 2489·2019-08-26 11:31
閱讀 3088·2019-08-26 10:56
閱讀 711·2019-08-26 10:28
