Redis RDB和AOF詳解

Redis 有兩種持久化方案，RDB （Redis DataBase）和 AOF （Append Only File）。如果你想快速瞭解和使用RDB和AOF，可以直接跳到文章底部看總結。本章節通過設定檔，觸發快照的方式，恢複資料的操作，命令操作示範，優缺點來學習 Redis 的重點知識持久化。本文主要針對Redis 有兩種持久化方案RDB和AOF做了詳細的分析，希望我們整理的內容能夠協助大家對這個兩種方案有更加深入的理解。

RDB 詳解

RDB 是 Redis 預設的持久化方案。在指定的時間間隔內，執行指定次數的寫操作，則會將記憶體中的資料寫入到磁碟中。即在指定目錄下產生一個dump.rdb檔案。Redis 重啟會通過載入dump.rdb檔案恢複資料。

從設定檔瞭解RDB

開啟 redis.conf 檔案，找到 SNAPSHOTTING 對應內容
1 RDB核心規則配置（重點）

save <seconds> <changes># save ""save 900 1save 300 10save 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.confsave 900 1save 120 5save 60 10000[root@itdragon bin]# ./redis-server redis.conf[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379127.0.0.1:6379> keys *(empty list or set)127.0.0.1:6379> set key1 value1OK127.0.0.1:6379> set key2 value2OK127.0.0.1:6379> set key3 value3OK127.0.0.1:6379> set key4 value4OK127.0.0.1:6379> set key5 value5OK127.0.0.1:6379> set key6 value6OK127.0.0.1:6379> SHUTDOWNnot 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 6379127.0.0.1:6379> FLUSHALL OK127.0.0.1:6379> keys *(empty list or set)127.0.0.1:6379> SHUTDOWNnot connected> QUIT[root@itdragon bin]# cp dump_bk.rdb dump.rdbcp: overwrite `dump.rdb'? y[root@itdragon bin]# ./redis-server redis.conf[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379127.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 alwaysappendfsync everysec# appendfsync no

解說：

always：同步持久化，每次發生資料變化會立刻寫入到磁碟中。效能較差當資料完整性比較好（慢，安全）

everysec：出廠預設推薦，每秒非同步記錄一次（預設值）

no：不同步

4 配置重寫觸發機制

auto-aof-rewrite-percentage 100auto-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.aofappendonly yes[root@itdragon bin]# ./redis-server redis.conf[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379127.0.0.1:6379> keys *(empty list or set)127.0.0.1:6379> set keyAOf valueAofOK127.0.0.1:6379> FLUSHALL OK127.0.0.1:6379> SHUTDOWNnot connected> QUIT[root@itdragon bin]# ./redis-server redis.conf[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379127.0.0.1:6379> keys *1) "keyAOf"127.0.0.1:6379> SHUTDOWNnot connected> QUIT[root@itdragon bin]# vim appendonly.aoffjewofjwojfoewifjowejfwf[root@itdragon bin]# ./redis-server redis.conf[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379Could not connect to Redis at 127.0.0.1:6379: Connection refusednot 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=30This will shrink the AOF from 92 bytes, with 30 bytes, to 62 bytesContinue? [y/N]: ySuccessfully truncated AOF[root@itdragon bin]# ./redis-server redis.conf[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379127.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。