<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          文件 IO 中如何保證掉電不丟失數(shù)據(jù)?

          共 2715字,需瀏覽 6分鐘

           ·

          2021-09-22 12:18

          前言

          好久沒(méi)有分享文件 IO 的小技巧了,依稀記得上次分享還是在上次。

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

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

          正確性檢測(cè)要求我們寫入的數(shù)據(jù)能夠被查詢出來(lái),沒(méi)有丟失,按照我個(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 中斷,該場(chǎng)景沒(méi)有什么好講的,一般評(píng)測(cè)程序會(huì)留出 destroyclose 等回調(diào)接口,用于顯式關(guān)閉,或者在 Java 中使用 JVM 提供的 ShutdownHook 監(jiān)聽 -15 信號(hào),這是最簡(jiǎn)單的一種場(chǎng)景,一般不需要考慮數(shù)據(jù)一致性的問(wèn)題。在實(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ī)器可沒(méi)掛。在實(shí)際生產(chǎn)中,對(duì)應(yīng)我們遇到一些內(nèi)存溢出、FullGC 重啟進(jìn)程等暴力退出程序的場(chǎng)景。

          第三個(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ī)房斷電等場(chǎng)景。

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

          而這次比賽的正確性描述

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

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

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

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

          很多同學(xué)可能有疑惑,如果一個(gè)數(shù)據(jù)寫到一半,發(fā)生了掉電,那評(píng)測(cè)程序怎么知道這條數(shù)據(jù)落盤了沒(méi)有呢?評(píng)測(cè)程序會(huì)不會(huì)讀取這條數(shù)據(jù)呢?其實(shí),對(duì)于”執(zhí)行到一半“這種邏輯,誰(shuí)都沒(méi)有辦法保證,正如系統(tǒng)真正掉電時(shí),他可不會(huì)跟你商量。所以,在一般的評(píng)測(cè)中,去驗(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)場(chǎng)景的認(rèn)知:

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

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

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

          PageCache

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

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

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

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

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

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

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

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

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

          鑒于比賽還在進(jìn)行中,我就不過(guò)多聊詳細(xì)設(shè)計(jì)了,懂的應(yīng)該看到上面這段話都懂了,還算是比較基礎(chǔ)的優(yōu)化。我在優(yōu)化過(guò)后,可以保證在 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)  方案

          今天對(duì)文件 IO 的理解有沒(méi)有多一點(diǎn)點(diǎn)呢,如果你愿意多花點(diǎn)時(shí)間閱讀這篇文章的話,你就會(huì)發(fā)現(xiàn)多花了點(diǎn)時(shí)間。對(duì)了,這次比賽,我有拉一個(gè)小群,歡迎對(duì)比賽感興趣的同學(xué)加我微信 xiayimiaoshenghua 進(jìn)群交流,或者留言討論哦。

          END -

          「技術(shù)分享」某種程度上,是讓作者和讀者,不那么孤獨(dú)的東西。歡迎關(guān)注我的微信公眾號(hào):「Kirito的技術(shù)分享」

          瀏覽 46
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          評(píng)論
          圖片
          表情
          推薦
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  AV网子 | 日韩乱伦影片 | 无码影视在线观看 | 一级操逼片 | 99精品视频在线观看免费播放 |