Redis持久化方式RDB和AOF的優(yōu)缺點(diǎn)

Redis 提供了兩種持久化的方式，分別是RDB(Redis DataBase)和AOF(Append Only File)。

RDB，簡而言之，就是在不同的時(shí)間點(diǎn)，將Redis 存儲(chǔ)的數(shù)據(jù)生成快照并存儲(chǔ)到磁盤等介質(zhì)上。

AOF，則是換了一個(gè)角度來實(shí)現(xiàn)持久化，那就是將Redis 執(zhí)行過的所有寫指令記錄下來，在下次Redis 重新啟動(dòng)時(shí)，只要把這些寫指令從前到后再重復(fù)執(zhí)行一遍，就可以實(shí)現(xiàn)數(shù)據(jù)恢復(fù)了。

RDB 和AOF 兩種方式也可以同時(shí)使用，在這種情況下，如果Redis 重啟的話，則會(huì)優(yōu)先采用AOF 方式來進(jìn)行數(shù)據(jù)恢復(fù)，這是因?yàn)锳OF 方式的數(shù)據(jù)恢復(fù)完整度更高。

RDB

RDB持久化方式，是將Redis某一時(shí)刻的數(shù)據(jù)持久化到磁盤中，是一種快照式的持久化方法。

RDB持久化方式：Redis在進(jìn)行數(shù)據(jù)持久化的過程中，會(huì)先將數(shù)據(jù)寫入到一個(gè)臨時(shí)文件中，待持久化過程都結(jié)束了，才會(huì)用這個(gè)臨時(shí)文件替換上次持久化好的文件。正是這種特性，讓我們可以隨時(shí)來進(jìn)行備份，因?yàn)榭煺瘴募偸峭暾捎玫摹?/p>

對于RDB 方式，Redis 會(huì)單獨(dú)創(chuàng)建一個(gè)子進(jìn)程來進(jìn)行持久化，而主進(jìn)程是不會(huì)進(jìn)行任何IO 操作的，這樣就確保了Redis 極高的性能。

RDB優(yōu)點(diǎn)：如果需要進(jìn)行大規(guī)模數(shù)據(jù)的恢復(fù)，且對于數(shù)據(jù)恢復(fù)的完整性不是非常敏感，那RDB 方式要比AOF 方式更加的高效。

RDB缺點(diǎn)：如果你對數(shù)據(jù)的完整性非常敏感，那么RDB 方式就不太適合你，因?yàn)榧词鼓忝? 分鐘都持久化一次，當(dāng)Redis 故障時(shí)，仍然會(huì)有近5 分鐘的數(shù)據(jù)丟失。所以，Redis 還提供了另一種持久化方式，那就是AOF。

AOF

AOF方式是將執(zhí)行過的寫指令記錄下來，在數(shù)據(jù)恢復(fù)時(shí)按照從前到后的順序再將指令都執(zhí)行一遍。

實(shí)現(xiàn)方式：我們通過配置Redis.conf 中的appendonly yes 就可以打開AOF功能。如果有寫操作(如SET 等)，Redis 就會(huì)被追加到AOF 文件的末尾。

AOF 持久化的方式：默認(rèn)的AOF 持久化策略是每秒鐘fsync 一次(fsync是指把緩存中的寫指令記錄到磁盤中)，因?yàn)樵谶@種情況下，Redis 仍然可以保持很好的處理性能，即使Redis 故障，也只會(huì)丟失最近1 秒鐘的數(shù)據(jù)。

如果在追加日志時(shí)，恰好遇到磁盤空間滿或斷電等情況導(dǎo)致日志寫入不完整，也沒有關(guān)系，Redis 提供了Redis-check-aof 工具，可以用來進(jìn)行日志修復(fù)。

因?yàn)椴捎昧俗芳臃绞剑绻蛔鋈魏翁幚淼脑?，AOF 文件會(huì)變得越來越大，為此，Redis 提供了AOF 文件重寫(rewrite)機(jī)制，即當(dāng)AOF 文件的大小超過所設(shè)定的閾值時(shí)，Redis 就會(huì)啟動(dòng)AOF 文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集。舉個(gè)例子或許更形象，假如我們調(diào)用了100 次INCR 指令，在AOF 文件中就要存儲(chǔ)100 條指令，但這明顯是很低效的，完全可以把這100條指令合并成一條SET 指令，這就是重寫機(jī)制的原理。

AOF 優(yōu)點(diǎn)：我們通過一個(gè)場景再現(xiàn)來說明。某同學(xué)在操作Redis 時(shí)，不小心執(zhí)行了FLUSHALL，導(dǎo)致Redis 內(nèi)存中的數(shù)據(jù)全部被清空了，這是很悲劇的事情。不過這也不是世界末日，只要Redis 配置了AOF 持久化方式，且AOF文件還沒有被重寫(rewrite)，我們就可以用最快的速度暫停Redis 并編輯AOF文件，將最后一行的FLUSHALL 命令刪除，然后重啟Redis，就可以恢復(fù)Redis的所有數(shù)據(jù)到FLUSHALL 之前的狀態(tài)了。是不是很神奇，這就是AOF 持久化方式的好處之一。但是如果AOF 文件已經(jīng)被重寫了，那就無法通過這種方法來恢復(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)了被寫壞的情況，也不必過分擔(dān)憂，Redis并不會(huì)貿(mào)然加載這個(gè)有問題的AOF 文件，而是報(bào)錯(cuò)退出。這時(shí)可以通過以下步驟來修復(fù)出錯(cuò)的文件：

1.備份被寫壞的AOF 文件。

2.運(yùn)行Redis-check-aof –fix 進(jìn)行修復(fù)。

3.用diff -u 來看下兩個(gè)文件的差異，確認(rèn)問題點(diǎn)。

4.重啟Redis，加載修復(fù)后的AOF 文件。