原文鏈接：https://www.cnblogs.com/itdragon/p/7906481.html
溫馨提示
在正式數據（當然是非生產環境啦）練習以下操作時，一定一定一定記得備份dump.rdb文件。
我給自己的服務器添加了aof持久化配置，重啓後，發現aof文件爲空，就想把rdb文件恢復到redis中，所以刪除了aof文件，並shutdown了服務，重啓後，redis中爲空，rdb文件爲空，aof文件爲空，悲劇了。
Redis 有兩種持久化方案，RDB （Redis DataBase）和 AOF （Append Only File）。如果你想快速瞭解和使用RDB和AOF，可以直接跳到文章底部看總結。本章節通過配置文件，觸發快照的方式，恢復數據的操作，命令操作演示，優缺點來學習 Redis 的重點知識持久化。
RDB 詳解
RDB 是 Redis 默認的持久化方案。在指定的時間間隔內，執行指定次數的寫操作，則會將內存中的數據寫入到磁盤中。即在指定目錄下生成一個dump.rdb文件。Redis 重啓會通過加載dump.rdb文件恢復數據。
從配置文件瞭解RDB
打開 redis.conf 文件，找到 SNAPSHOTTING 對應內容
1 RDB核心規則配置（重點）
save
save ""
save 900 1
save 300 10
save 60 10000
解說：save ，滿足條件就將內存中的數據同步到硬盤中。官方出廠配置默認是 900秒內有1個更改，300秒內有10個更改以及60秒內有10000個更改，則將內存中的數據快照寫入磁盤。
若不想用RDB方案，可以把 save "" 的註釋打開，下面三個註釋。
2 指定本地數據庫文件名，一般採用默認的 dump.rdb
dbfilename dump.rdb
3 指定本地數據庫存放目錄，一般也用默認配置
dir ./
4 默認開啓數據壓縮
rdbcompression yes
解說：配置存儲至本地數據庫時是否壓縮數據，默認爲yes。Redis採用LZF壓縮方式，但佔用了一點CPU的時間。若關閉該選項，但會導致數據庫文件變的巨大。建議開啓。
觸發RDB快照
1 在指定的時間間隔內，執行指定次數的寫操作
2 執行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （異步）命令
3 執行flushall 命令，清空數據庫所有數據，意義不大。
4 執行shutdown 命令，保證服務器正常關閉且不丟失任何數據，意義...也不大。
通過RDB文件恢復數據
將dump.rdb 文件拷貝到redis的安裝目錄的bin目錄下，重啓redis服務即可。在實際開發中，一般會考慮到物理機硬盤損壞情況，選擇備份dump.rdb 。可以從下面的操作演示中可以體會到。
RDB 的優缺點
優點：
1 適合大規模的數據恢復。
2 如果業務對數據完整性和一致性要求不高，RDB是很好的選擇。
缺點：
1 數據的完整性和一致性不高，因爲RDB可能在最後一次備份時宕機了。
2 備份時佔用內存，因爲Redis 在備份時會獨立創建一個子進程，將數據寫入到一個臨時文件（此時內存中的數據是原來的兩倍哦），最後再將臨時文件替換之前的備份文件。
所以Redis 的持久化和數據的恢復要選擇在夜深人靜的時候執行是比較合理的。
操作演示
[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秒內修改5次則持久化一次。
第二步：重啓服務使配置生效。
第三步：分別set 5個key，過兩分鐘後，在bin的當前目錄下會自動生產一個dump.rdb文件。（set key6 是爲了驗證shutdown有觸發RDB快照的作用）
第四步：將當前的dump.rdb 備份一份（模擬線上工作）。
第五步：執行FLUSHALL命令清空數據庫數據（模擬數據丟失）。
第六步：重啓Redis服務，恢復數據.....咦？？？？( ′◔ ‸◔`)。數據是空的？？？？這是因爲FLUSHALL也有觸發RDB快照的功能。
第七步：將備份的 dump_bk.rdb 替換 dump.rdb 然後重新Redis。
注意點：SHUTDOWN 和 FLUSHALL 命令都會觸發RDB快照，這是一個坑，請大家注意。
其他命令：
keys * 匹配數據庫中所有 key
save 阻塞觸發RDB快照，使其備份數據
FLUSHALL 清空整個 Redis 服務器的數據(幾乎不用)
SHUTDOWN 關機走人（很少用）AOF 詳解
AOF ：Redis 默認不開啓。它的出現是爲了彌補RDB的不足（數據的不一致性），所以它採用日誌的形式來記錄每個寫操作，並追加到文件中。Redis 重啓的會根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工作。
從配置文件瞭解AOF
打開 redis.conf 文件，找到 APPEND ONLY MODE 對應內容
1 redis 默認關閉，開啓需要手動把no改爲yes
appendonly yes
2 指定本地數據庫文件名，默認值爲 appendonly.aof
appendfilename "appendonly.aof"
3 指定更新日誌條件
appendfsync always
appendfsync everysec
appendfsync no
解說：
always：同步持久化，每次發生數據變化會立刻寫入到磁盤中。性能較差當數據完整性比較好（慢，安全）
everysec：出廠默認推薦，每秒異步記錄一次（默認值）
no：不同步
4 配置重寫觸發機制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
解說：當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發。一般都設置爲3G，64M太小了。
觸發AOF快照
根據配置文件觸發，可以是每次執行觸發，可以是每秒觸發，可以不同步。
根據AOF文件恢復數據
正常情況下，將appendonly.aof 文件拷貝到redis的安裝目錄的bin目錄下，重啓redis服務即可。但在實際開發中，可能因爲某些原因導致appendonly.aof 文件格式異常，從而導致數據還原失敗，可以通過命令redis-check-aof --fix appendonly.aof 進行修復 。從下面的操作演示中體會。
AOF的重寫機制
前面也說到了，AOF的工作原理是將寫操作追加到文件中，文件的冗餘內容會越來越多。所以聰明的 Redis 新增了重寫機制。當AOF文件的大小超過所設定的閾值時，Redis就會對AOF文件的內容壓縮。
重寫的原理：Redis 會fork出一條新進程，讀取內存中的數據，並重新寫到一個臨時文件中。並沒有讀取舊文件（你都那麼大了，我還去讀你？？？ o(ﾟДﾟ)っ傻啊！）。最後替換舊的aof文件。
觸發機制：當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發。這裏的“一倍”和“64M” 可以通過配置文件修改。
AOF 的優缺點
優點：數據的完整性和一致性更高
缺點：因爲AOF記錄的內容多，文件會越來越大，數據恢復也會越來越慢。
操作演示
[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服務，並進入Redis 自帶的客戶端中。
第三步：保存值，然後模擬數據丟失，關閉Redis服務。
第四步：重啓服務，發現數據恢復了。（額外提一點：有教程顯示FLUSHALL 命令會被寫入AOF文件中，導致數據恢復失敗。我安裝的是redis-4.0.2沒有遇到這個問題）。
第五步：修改appendonly.aof，模擬文件異常情況。
第六步：重啓 Redis 服務失敗。這同時也說明了，RDB和AOF可以同時存在，且優先加載AOF文件。
第七步：校驗appendonly.aof 文件。重啓Redis 服務後正常。
補充點：aof 的校驗是通過 redis-check-aof 文件，那麼rdb 的校驗是不是可以通過 redis-check-rdb 文件呢？？？
總結
Redis 默認開啓RDB持久化方式，在指定的時間間隔內，執行指定次數的寫操作，則將內存中的數據寫入到磁盤中。
RDB 持久化適合大規模的數據恢復但它的數據一致性和完整性較差。
Redis 需要手動開啓AOF持久化方式，默認是每秒將寫操作日誌追加到AOF文件中。
AOF 的數據完整性比RDB高，但記錄內容多了，會影響數據恢復的效率。
Redis 針對 AOF文件大的問題，提供重寫的瘦身機制。
若只打算用Redis 做緩存，可以關閉持久化。
若打算使用Redis 的持久化。建議RDB和AOF都開啓。其實RDB更適合做數據的備份，留一後手。AOF出問題了，還有RDB。到這裏Redis 的持久化就介紹完了，有什麼不對的地方可以指出。