前言

好久沒有分享文件 IO 的小技巧了，依稀記得上次分享還是在上次。

第二屆云原生編程挑戰(zhàn)賽正在火熱進(jìn)行中，Kirito 也在做《針對冷熱讀寫場景的RocketMQ存儲系統(tǒng)設(shè)計》這個題目，不過參與的是內(nèi)部賽道，沒法跟外部的小伙伴們一起排名了。

眾所周知，存儲設(shè)計離不開文件 IO，將數(shù)據(jù)存儲到文件中進(jìn)行持久化，是大多數(shù)消息隊列、數(shù)據(jù)庫系統(tǒng)的常規(guī)操作。在比賽中，為了更貼近實際的生產(chǎn)場景，往往也會引入正確性檢測階段，以避免讓選手設(shè)計一些僅僅支持內(nèi)存行為的代碼邏輯。試想一下，RocketMQ 或者 Mysql 在宕機之后因為索引丟失，而導(dǎo)致數(shù)據(jù)無法查詢，這該是多么可怕的一件事！

正確性檢測要求我們寫入的數(shù)據(jù)能夠被查詢出來，沒有丟失，按照我個人的參賽經(jīng)驗，通常分為三種級別

• 進(jìn)程正常退出或者進(jìn)程被 kill -15 中斷
• 進(jìn)程被 kill -9 中斷
• 系統(tǒng)掉電

第一個級別，進(jìn)程正常退出或者進(jìn)程被 kill -15 中斷，該場景沒有什么好講的，一般評測程序會留出 destroy 、close 等回調(diào)接口，用于顯式關(guān)閉，或者在 Java 中使用 JVM 提供的 ShutdownHook 監(jiān)聽 -15 信號，這是最簡單的一種場景，一般不需要考慮數(shù)據(jù)一致性的問題。在實際生產(chǎn)中，對應(yīng)我們優(yōu)雅退出、手動關(guān)機的流程。

第二個級別，進(jìn)程被 kill -9 中斷。這意味著，我們使用內(nèi)存去聚合一些數(shù)據(jù)可能是受限的，但我們?nèi)匀豢梢岳貌僮飨到y(tǒng)的一些特性，例如 PageCache 去做緩存。畢竟進(jìn)程掛了，機器可沒掛。在實際生產(chǎn)中，對應(yīng)我們遇到一些內(nèi)存溢出、FullGC 重啟進(jìn)程等暴力退出程序的場景。

第三個級別，系統(tǒng)掉電。這也是我這篇文章的主角，同時也是數(shù)據(jù)一致性要求最高的級別。系統(tǒng)掉電意味著我們甚至連 PageCache 都不能直接利用，必須嚴(yán)格保證數(shù)據(jù)落到磁盤當(dāng)中。在實際生產(chǎn)中，對應(yīng)主機宕機，機房斷電等場景。

可以發(fā)現(xiàn)，任何一個級別，都有他們實際應(yīng)用的場景，越是一致性要求高的級別，通常性能就越差，能夠利用的手段也越少，系統(tǒng)也就越難設(shè)計。

而這次比賽的正確性描述

1. 寫入若干條數(shù)據(jù)。
2. 重啟機器
3. 再讀出來，必須嚴(yán)格等于之前寫入的數(shù)據(jù)

其中的重啟機器環(huán)節(jié)，恰恰是模擬的掉電。

如何理解數(shù)據(jù)不丟失

在介紹 Java 文件 IO 中保證掉電不丟失的手段之前，我還需要做一個概念的介紹，這樣方便我們更好的理解文章后續(xù)的觀點。

很多同學(xué)可能有疑惑，如果一個數(shù)據(jù)寫到一半，發(fā)生了掉電，那評測程序怎么知道這條數(shù)據(jù)落盤了沒有呢？評測程序會不會讀取這條數(shù)據(jù)呢？其實，對于”執(zhí)行到一半“這種邏輯，誰都沒有辦法保證，正如系統(tǒng)真正掉電時，他可不會跟你商量。所以，在一般的評測中，去驗證選手的數(shù)據(jù)一致性時，通常采取的做法是：當(dāng)一個方法同步返回時，就應(yīng)該認(rèn)為這個數(shù)據(jù)落盤了，即使返回后立刻斷電，也應(yīng)該可以在重啟之后，查詢到這條數(shù)據(jù)。

這符合我們在實際開發(fā)/生產(chǎn)場景的認(rèn)知：

• 對于同步方法，其實隱含了 ack 的契約，即拿到返回值的那一瞬間，認(rèn)為對方處理完畢了。
• 對于異步方法，我們才需要增加回調(diào)或者輪詢 ack 的機制。

Java 文件 IO 保障掉電不丟數(shù)據(jù)

在《文件 IO 操作的一些最佳實踐》一文中，我其實已經(jīng)介紹了，Java 中無非就一個 FileChannel 是最常用的文件操作類。FileChannel 的 write 方法看似是一個同步方法，將內(nèi)存數(shù)據(jù)寫入了磁盤，但其實它和磁盤之間還隔著一層 PageCache。

盡管操作系統(tǒng)可能很快就將 PageCache 刷入到了磁盤，但這個過程仍然是一個異步的過程。就以這次比賽而言，如果你僅僅數(shù)據(jù)寫入到 PageCache 就不管不問了，肯定是無法通過正確性檢測的。

解決方法也很簡單，調(diào)用 FileChannel#force(boolean meta) 方法即可，該方法會強制操作系統(tǒng)將 PageCache 刷盤。

force 的入?yún)⑹且粋€ boolean 值，代表是否將元數(shù)據(jù)也刷盤，這塊網(wǎng)上資料比較少，我也沒有詳細(xì)的依據(jù)。按照我個人的理解，元數(shù)據(jù)包含了大小和時間戳信息，可能會影響文件的實際長度，所以 force(true) 可能更穩(wěn)妥一些。

結(jié)合第二節(jié)中介紹的內(nèi)容，我們只需要保證在每次寫入操作返回之前，調(diào)用 force，即可實現(xiàn)掉電數(shù)據(jù)不丟失的效果。

那么，代價是什么呢？意味著我們完全喪失了操作系統(tǒng)給文件 IO 設(shè)置的一道緩存。在沒有緩存又沒有 4kb 對齊的情況下，寫入放大問題將會非常明顯。

這里用一份數(shù)據(jù)說話，根據(jù)官方給出的數(shù)據(jù)，這次評測使用的 SSD 吞吐可達(dá)到 320MiB/s，而我實測在不經(jīng)過優(yōu)化的場景下使用 force，僅僅能達(dá)到 50 Mib/s，直接會導(dǎo)致評測超時。

force 是掉電的拯救者，也可能是性能的毀滅者。

force 下可能的優(yōu)化方案

在實際場景中，消息的生產(chǎn)者可能會同步地連續(xù)地發(fā)送多條消息，也有可能會有多個生產(chǎn)者一起在發(fā)送消息，盡管消息的投遞是同步的，但我們?nèi)匀豢梢栽诙鄠€不同生產(chǎn)者的消息之間做一些文章，在保證 force 的同時，減少寫入放大的問題。

鑒于比賽還在進(jìn)行中，我就不過多聊詳細(xì)設(shè)計了，懂的應(yīng)該看到上面這段話都懂了，還算是比較基礎(chǔ)的優(yōu)化。我在優(yōu)化過后，可以保證在 force 的前提下，將吞吐量從 50 Mib/s 提升到 275 Mib/s，盡管離理論值還是有所差距，但已經(jīng)足夠出一個 baseline 了。

RocketMQ 中的實際應(yīng)用

以 RocketMQ 為例，聊聊其是如何保障數(shù)據(jù)不丟失的。RocketMQ 在 Broker 側(cè)保障數(shù)據(jù)不丟失主要有兩種機制：

1. RocketMQ 支持配置同步雙寫，保障消息在主節(jié)點之外，還在一個從節(jié)點有備份
2. RocketMQ 支持同步刷盤策略，即本文介紹的 FileChannel#force(boolean meta) ?方案