更新時(shí)間:2021-05-07 來(lái)源:黑馬程序員 瀏覽量:
Redis 提供了兩種持久化的方式,分別是RDB(Redis DataBase)和AOF(Append Only File)。
RDB,簡(jiǎn)而言之,就是在不同的時(shí)間點(diǎn),將Redis 存儲(chǔ)的數(shù)據(jù)生成快照并存儲(chǔ)到磁盤(pán)等介質(zhì)上。
AOF,則是換了一個(gè)角度來(lái)實(shí)現(xiàn)持久化,那就是將Redis 執(zhí)行過(guò)的所有寫(xiě)指令記錄下來(lái),在下次Redis 重新啟動(dòng)時(shí),只要把這些寫(xiě)指令從前到后再重復(fù)執(zhí)行一遍,就可以實(shí)現(xiàn)數(shù)據(jù)恢復(fù)了。
RDB 和AOF 兩種方式也可以同時(shí)使用,在這種情況下,如果Redis 重啟的話(huà),則會(huì)優(yōu)先采用AOF 方式來(lái)進(jìn)行數(shù)據(jù)恢復(fù),這是因?yàn)锳OF 方式的數(shù)據(jù)恢復(fù)完整度更高。
RDB持久化方式,是將Redis某一時(shí)刻的數(shù)據(jù)持久化到磁盤(pán)中,是一種快照式的持久化方法。
RDB持久化方式:Redis在進(jìn)行數(shù)據(jù)持久化的過(guò)程中,會(huì)先將數(shù)據(jù)寫(xiě)入到一個(gè)臨時(shí)文件中,待持久化過(guò)程都結(jié)束了,才會(huì)用這個(gè)臨時(shí)文件替換上次持久化好的文件。正是這種特性,讓我們可以隨時(shí)來(lái)進(jìn)行備份,因?yàn)榭煺瘴募偸峭暾捎玫摹?/p>
對(duì)于RDB 方式,Redis 會(huì)單獨(dú)創(chuàng)建一個(gè)子進(jìn)程來(lái)進(jìn)行持久化,而主進(jìn)程是不會(huì)進(jìn)行任何IO 操作的,這樣就確保了Redis 極高的性能。
RDB優(yōu)點(diǎn):如果需要進(jìn)行大規(guī)模數(shù)據(jù)的恢復(fù),且對(duì)于數(shù)據(jù)恢復(fù)的完整性不是非常敏感,那RDB 方式要比AOF 方式更加的高效。
RDB缺點(diǎn):如果你對(duì)數(shù)據(jù)的完整性非常敏感,那么RDB 方式就不太適合你,因?yàn)榧词鼓忝? 分鐘都持久化一次,當(dāng)Redis 故障時(shí),仍然會(huì)有近5 分鐘的數(shù)據(jù)丟失。所以,Redis 還提供了另一種持久化方式,那就是AOF。
AOF方式是將執(zhí)行過(guò)的寫(xiě)指令記錄下來(lái),在數(shù)據(jù)恢復(fù)時(shí)按照從前到后的順序再將指令都執(zhí)行一遍。
實(shí)現(xiàn)方式:我們通過(guò)配置Redis.conf 中的appendonly yes 就可以打開(kāi)AOF功能。如果有寫(xiě)操作(如SET 等),Redis 就會(huì)被追加到AOF 文件的末尾。
AOF 持久化的方式:默認(rèn)的AOF 持久化策略是每秒鐘fsync 一次(fsync是指把緩存中的寫(xiě)指令記錄到磁盤(pán)中),因?yàn)樵谶@種情況下,Redis 仍然可以保持很好的處理性能,即使Redis 故障,也只會(huì)丟失最近1 秒鐘的數(shù)據(jù)。
如果在追加日志時(shí),恰好遇到磁盤(pán)空間滿(mǎn)或斷電等情況導(dǎo)致日志寫(xiě)入不完整,也沒(méi)有關(guān)系,Redis 提供了Redis-check-aof 工具,可以用來(lái)進(jìn)行日志修復(fù)。
因?yàn)椴捎昧俗芳臃绞剑绻蛔鋈魏翁幚淼脑?huà),AOF 文件會(huì)變得越來(lái)越大,為此,Redis 提供了AOF 文件重寫(xiě)(rewrite)機(jī)制,即當(dāng)AOF 文件的大小超過(guò)所設(shè)定的閾值時(shí),Redis 就會(huì)啟動(dòng)AOF 文件的內(nèi)容壓縮,只保留可以恢復(fù)數(shù)據(jù)的最小指令集。舉個(gè)例子或許更形象,假如我們調(diào)用了100 次INCR 指令,在AOF 文件中就要存儲(chǔ)100 條指令,但這明顯是很低效的,完全可以把這100條指令合并成一條SET 指令,這就是重寫(xiě)機(jī)制的原理。
AOF 優(yōu)點(diǎn):我們通過(guò)一個(gè)場(chǎng)景再現(xiàn)來(lái)說(shuō)明。某同學(xué)在操作Redis 時(shí),不小心執(zhí)行了FLUSHALL,導(dǎo)致Redis 內(nèi)存中的數(shù)據(jù)全部被清空了,這是很悲劇的事情。不過(guò)這也不是世界末日,只要Redis 配置了AOF 持久化方式,且AOF文件還沒(méi)有被重寫(xiě)(rewrite),我們就可以用最快的速度暫停Redis 并編輯AOF文件,將最后一行的FLUSHALL 命令刪除,然后重啟Redis,就可以恢復(fù)Redis的所有數(shù)據(jù)到FLUSHALL 之前的狀態(tài)了。是不是很神奇,這就是AOF 持久化方式的好處之一。但是如果AOF 文件已經(jīng)被重寫(xiě)了,那就無(wú)法通過(guò)這種方法來(lái)恢復(fù)數(shù)據(jù)了。
AOF缺點(diǎn):比如在同樣數(shù)據(jù)規(guī)模的情況下,AOF文件要比RDB文件的體積大。而且,AOF 方式的恢復(fù)速度也要慢于RDB 方式。
如果你直接執(zhí)行BGREWRITEAOF 命令,那么Redis 會(huì)生成一個(gè)全新的AOF文件,其中便包括了可以恢復(fù)現(xiàn)有數(shù)據(jù)的最少的命令集。
如果運(yùn)氣比較差,AOF 文件出現(xiàn)了被寫(xiě)壞的情況,也不必過(guò)分擔(dān)憂(yōu),Redis并不會(huì)貿(mào)然加載這個(gè)有問(wèn)題的AOF 文件,而是報(bào)錯(cuò)退出。這時(shí)可以通過(guò)以下步驟來(lái)修復(fù)出錯(cuò)的文件:
1.備份被寫(xiě)壞的AOF 文件。
2.運(yùn)行Redis-check-aof –fix 進(jìn)行修復(fù)。
3.用diff -u 來(lái)看下兩個(gè)文件的差異,確認(rèn)問(wèn)題點(diǎn)。
4.重啟Redis,加載修復(fù)后的AOF 文件。
猜你喜歡: