Redis RDB和AOF詳解

小云云原創: 2017-12-14 14:22:121714瀏覽

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 1
save 300 10
save 60 10000

解說：save 8b56aa7a39e35fe7c642d0542a41ad07 4925617f05afd2a8274d03395ff4c2fd，滿足條件就將記憶體中的資料同步到硬碟中。官方出廠配置預設是 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&#39;? 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 
&#39;x    3e: Expected prefix &#39;*&#39;, got: &#39;
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 RDB和AOF詳解

相關文章