本文主要針對Redis 有兩種持久化方案RDB和AOF做了詳細(xì)的分析，希望我們整理的內(nèi)容能夠幫助大家對這個兩種方案有更加深入的理解。

Redis 有兩種持久化方案，RDB （Redis DataBase）和 AOF （Append Only File）。如果你想快速了解和使用RDB和AOF，可以直接跳到文章底部看總結(jié)。本章節(jié)通過配置文件，觸發(fā)快照的方式，恢復(fù)數(shù)據(jù)的操作，命令操作演示，優(yōu)缺點(diǎn)來學(xué)習(xí) Redis 的重點(diǎn)知識持久化。

RDB 詳解

RDB 是 Redis 默認(rèn)的持久化方案。在指定的時間間隔內(nèi)，執(zhí)行指定次數(shù)的寫操作，則會將內(nèi)存中的數(shù)據(jù)寫入到磁盤中。即在指定目錄下生成一個dump.rdb文件。Redis 重啟會通過加載dump.rdb文件恢復(fù)數(shù)據(jù)。

從配置文件了解RDB

打開 redis.conf 文件，找到 SNAPSHOTTING 對應(yīng)內(nèi)容
1 RDB核心規(guī)則配置（重點(diǎn)）

save seconds> changes>
# save ""
save 900 1
save 300 10
save 60 10000

解說：save 指定時間間隔> 執(zhí)行指定次數(shù)更新操作>，滿足條件就將內(nèi)存中的數(shù)據(jù)同步到硬盤中。官方出廠配置默認(rèn)是 900秒內(nèi)有1個更改，300秒內(nèi)有10個更改以及60秒內(nèi)有10000個更改，則將內(nèi)存中的數(shù)據(jù)快照寫入磁盤。

若不想用RDB方案，可以把 save "" 的注釋打開，下面三個注釋。

2 指定本地數(shù)據(jù)庫文件名，一般采用默認(rèn)的 dump.rdb

dbfilename dump.rdb

3 指定本地數(shù)據(jù)庫存放目錄，一般也用默認(rèn)配置

dir ./

4 默認(rèn)開啟數(shù)據(jù)壓縮

rdbcompression yes

解說：配置存儲至本地數(shù)據(jù)庫時是否壓縮數(shù)據(jù)，默認(rèn)為yes。Redis采用LZF壓縮方式，但占用了一點(diǎn)CPU的時間。若關(guān)閉該選項，但會導(dǎo)致數(shù)據(jù)庫文件變的巨大。建議開啟。

觸發(fā)RDB快照

1 在指定的時間間隔內(nèi)，執(zhí)行指定次數(shù)的寫操作

2 執(zhí)行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （異步）命令

3 執(zhí)行flushall 命令，清空數(shù)據(jù)庫所有數(shù)據(jù)，意義不大。

4 執(zhí)行shutdown 命令，保證服務(wù)器正常關(guān)閉且不丟失任何數(shù)據(jù)，意義...也不大。

通過RDB文件恢復(fù)數(shù)據(jù)

將dump.rdb 文件拷貝到redis的安裝目錄的bin目錄下，重啟redis服務(wù)即可。在實(shí)際開發(fā)中，一般會考慮到物理機(jī)硬盤損壞情況，選擇備份dump.rdb 。可以從下面的操作演示中可以體會到。

RDB 的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

1 適合大規(guī)模的數(shù)據(jù)恢復(fù)。

2 如果業(yè)務(wù)對數(shù)據(jù)完整性和一致性要求不高，RDB是很好的選擇。

缺點(diǎn)：

1 數(shù)據(jù)的完整性和一致性不高，因為RDB可能在最后一次備份時宕機(jī)了。

2 備份時占用內(nèi)存，因為Redis 在備份時會獨(dú)立創(chuàng)建一個子進(jìn)程，將數(shù)據(jù)寫入到一個臨時文件（此時內(nèi)存中的數(shù)據(jù)是原來的兩倍哦），最后再將臨時文件替換之前的備份文件。

所以Redis 的持久化和數(shù)據(jù)的恢復(fù)要選擇在夜深人靜的時候執(zhí)行是比較合理的。

操作演示

[root@itdragon bin]# vim redis.conf
save 900 1
save 120 5
save 60 10000
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set key1 value1
OK
127.0.0.1:6379> set key2 value2
OK
127.0.0.1:6379> set key3 value3
OK
127.0.0.1:6379> set key4 value4
OK
127.0.0.1:6379> set key5 value5
OK
127.0.0.1:6379> set key6 value6
OK
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# cp dump.rdb dump_bk.rdb
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> FLUSHALL 
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# cp dump_bk.rdb dump.rdb
cp: overwrite `dump.rdb'? y
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "key5"
2) "key1"
3) "key3"
4) "key4"
5) "key6"
6) "key2"

第一步：vim 修改持久化配置時間，120秒內(nèi)修改5次則持久化一次。

第二步：重啟服務(wù)使配置生效。

第三步：分別set 5個key，過兩分鐘后，在bin的當(dāng)前目錄下會自動生產(chǎn)一個dump.rdb文件。（set key6 是為了驗證shutdown有觸發(fā)RDB快照的作用）

第四步：將當(dāng)前的dump.rdb 備份一份（模擬線上工作）。

第五步：執(zhí)行FLUSHALL命令清空數(shù)據(jù)庫數(shù)據(jù)（模擬數(shù)據(jù)丟失）。

第六步：重啟Redis服務(wù)，恢復(fù)數(shù)據(jù).....咦？？？？( ′◔ ‸◔`)。數(shù)據(jù)是空的？？？？這是因為FLUSHALL也有觸發(fā)RDB快照的功能。

第七步：將備份的 dump_bk.rdb 替換 dump.rdb 然后重新Redis。

注意點(diǎn)：SHUTDOWN 和 FLUSHALL 命令都會觸發(fā)RDB快照，這是一個坑，請大家注意。

其他命令：

keys * 匹配數(shù)據(jù)庫中所有 key save 阻塞觸發(fā)RDB快照，使其備份數(shù)據(jù) FLUSHALL 清空整個 Redis 服務(wù)器的數(shù)據(jù)(幾乎不用) SHUTDOWN 關(guān)機(jī)走人（很少用）

AOF 詳解

AOF ：Redis 默認(rèn)不開啟。它的出現(xiàn)是為了彌補(bǔ)RDB的不足（數(shù)據(jù)的不一致性），所以它采用日志的形式來記錄每個寫操作，并追加到文件中。Redis 重啟的會根據(jù)日志文件的內(nèi)容將寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復(fù)工作。

從配置文件了解AOF

打開 redis.conf 文件，找到 APPEND ONLY MODE 對應(yīng)內(nèi)容
1 redis 默認(rèn)關(guān)閉，開啟需要手動把no改為yes

appendonly yes

2 指定本地數(shù)據(jù)庫文件名，默認(rèn)值為 appendonly.aof

appendfilename "appendonly.aof"

3 指定更新日志條件

# appendfsync always
appendfsync everysec
# appendfsync no

解說：

always：同步持久化，每次發(fā)生數(shù)據(jù)變化會立刻寫入到磁盤中。性能較差當(dāng)數(shù)據(jù)完整性比較好（慢，安全）

everysec：出廠默認(rèn)推薦，每秒異步記錄一次（默認(rèn)值）

no：不同步

4 配置重寫觸發(fā)機(jī)制

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

解說：當(dāng)AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發(fā)。一般都設(shè)置為3G，64M太小了。

觸發(fā)AOF快照

根據(jù)配置文件觸發(fā)，可以是每次執(zhí)行觸發(fā)，可以是每秒觸發(fā)，可以不同步。

根據(jù)AOF文件恢復(fù)數(shù)據(jù)

正常情況下，將appendonly.aof 文件拷貝到redis的安裝目錄的bin目錄下，重啟redis服務(wù)即可。但在實(shí)際開發(fā)中，可能因為某些原因?qū)е耡ppendonly.aof 文件格式異常，從而導(dǎo)致數(shù)據(jù)還原失敗，可以通過命令redis-check-aof --fix appendonly.aof 進(jìn)行修復(fù) 。從下面的操作演示中體會。

AOF的重寫機(jī)制

前面也說到了，AOF的工作原理是將寫操作追加到文件中，文件的冗余內(nèi)容會越來越多。所以聰明的 Redis 新增了重寫機(jī)制。當(dāng)AOF文件的大小超過所設(shè)定的閾值時，Redis就會對AOF文件的內(nèi)容壓縮。

重寫的原理：Redis 會fork出一條新進(jìn)程，讀取內(nèi)存中的數(shù)據(jù)，并重新寫到一個臨時文件中。并沒有讀取舊文件（你都那么大了，我還去讀你？？？ o(ﾟДﾟ)っ傻啊！）。最后替換舊的aof文件。

觸發(fā)機(jī)制：當(dāng)AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發(fā)。這里的“一倍”和“64M” 可以通過配置文件修改。

AOF 的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：數(shù)據(jù)的完整性和一致性更高

缺點(diǎn)：因為AOF記錄的內(nèi)容多，文件會越來越大，數(shù)據(jù)恢復(fù)也會越來越慢。

操作演示

[root@itdragon bin]# vim appendonly.aof
appendonly yes
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set keyAOf valueAof
OK
127.0.0.1:6379> FLUSHALL 
OK
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "keyAOf"
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# vim appendonly.aof
fjewofjwojfoewifjowejfwf
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> QUIT
[root@itdragon bin]# redis-check-aof --fix appendonly.aof 
'x    3e: Expected prefix '*', got: '
AOF analyzed: size=92, ok_up_to=62, diff=30
This will shrink the AOF from 92 bytes, with 30 bytes, to 62 bytes
Continue? [y/N]: y
Successfully truncated AOF
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "keyAOf"

第一步：修改配置文件，開啟AOF持久化配置。

第二步：重啟Redis服務(wù)，并進(jìn)入Redis 自帶的客戶端中。

第三步：保存值，然后模擬數(shù)據(jù)丟失，關(guān)閉Redis服務(wù)。

第四步：重啟服務(wù)，發(fā)現(xiàn)數(shù)據(jù)恢復(fù)了。（額外提一點(diǎn)：有教程顯示FLUSHALL 命令會被寫入AOF文件中，導(dǎo)致數(shù)據(jù)恢復(fù)失敗。我安裝的是redis-4.0.2沒有遇到這個問題）。

第五步：修改appendonly.aof，模擬文件異常情況。

第六步：重啟 Redis 服務(wù)失敗。這同時也說明了，RDB和AOF可以同時存在，且優(yōu)先加載AOF文件。

第七步：校驗appendonly.aof 文件。重啟Redis 服務(wù)后正常。

補(bǔ)充點(diǎn)：aof 的校驗是通過 redis-check-aof 文件，那么rdb 的校驗是不是可以通過 redis-check-rdb 文件呢？？？

總結(jié) Redis 默認(rèn)開啟RDB持久化方式，在指定的時間間隔內(nèi)，執(zhí)行指定次數(shù)的寫操作，則將內(nèi)存中的數(shù)據(jù)寫入到磁盤中。 RDB 持久化適合大規(guī)模的數(shù)據(jù)恢復(fù)但它的數(shù)據(jù)一致性和完整性較差。 Redis 需要手動開啟AOF持久化方式，默認(rèn)是每秒將寫操作日志追加到AOF文件中。

AOF 的數(shù)據(jù)完整性比RDB高，但記錄內(nèi)容多了，會影響數(shù)據(jù)恢復(fù)的效率。 Redis 針對 AOF文件大的問題，提供重寫的瘦身機(jī)制。若只打算用Redis 做緩存，可以關(guān)閉持久化。若打算使用Redis 的持久化。建議RDB和AOF都開啟。其實(shí)RDB更適合做數(shù)據(jù)的備份，留一后手。AOF出問題了，還有RDB。

到這里Redis 的持久化就介紹完了，有什么不對的地方可以指出。