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