前言

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

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

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

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

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

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

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

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

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

而這次比賽的正確性描述

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

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

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

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

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

這符合我們?cè)趯?shí)際開發(fā)/生產(chǎn)場景的認(rèn)知：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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