Redis之RDB與AOF 筆記

AOF定義：以日志的形式記錄每個操作，將Redis執行過的所有指令全部記錄下來（讀操作不記錄），只許追加文件但不可以修改文件，Redis啟動時會讀取AOF配置文件重構數據

換句話說，就是Redis重啟就會根據日志內容從頭到尾執行一次來完成數據的恢復工作。

Tip:

　　一.RDB與AOF同時開啟  默認先加載AOF的配置文件

　　二.相同數據集，AOF文件要遠大於RDB文件，恢復速度慢於RDB

　　三.AOF運行效率慢於RDB,但是同步策略效率好，不同步效率和RDB相同

1.RDB持久化(以快照的方式) 策略（默認）：

　　save 900 1       （15分鍾變更一次）
　　save 300 10     （5分鍾變更10次）
　　save 60 10000  （1分鍾變更1萬次）
2.RDB默認配置文件名稱：

　　dbfilename dump.rdb

3.表示是否開啟AOF持久化：

　　appendonly yes(默認no,關閉) 

4.AOF持久化配置文件的名稱：

　　appendfilename "appendonly.aof"

5.AOF持久化策略(默認每秒)：

　　appendfsync always (同步持久化，每次發生數據變更會被立即記錄到磁盤，性能差但數據完整性比較好)

　　appendfsync everysec (異步操作，每秒記錄，如果一秒鍾內宕機，有數據丟失)

　　appendfsync no  （將緩存回寫的策略交給系統，linux 默認是30秒將緩沖區的數據回寫硬盤的）

6.AOF配置文件損壞修復方法：

　　進入redis安裝路徑 執行 redis-check-aof --fix AOF配置文件名稱

7.AOF的Rewrite(重寫) ：

　　定義：AOF采用文件追加的方式持久化數據，所以文件會越來越大，為了避免這種情況發生，增加了重寫機制

        　　當AOF文件的大小超過了配置所設置的闕值時，Redis就會啟動AOF文件壓縮，只保留可以恢復數據的最小指令集，可以使用命令bgrewriteaof

　　原理：當AOF增長過大時，會fork出一條新的進程將文件重寫(也是先寫臨時文件最后rename)，遍歷新進程的內存數據，每條記錄有一條set語句。

　　　　   重寫AOF文件並沒有操作舊的AOF文件，而是將整個內存中的數據內容用命令的方式重寫了一個新的aof文件（有點類似快照）

觸發機制：Redis會記錄上次重寫時的AOF文件大小，默認配置時當AOF文件大小是上次rewrite后大小的一倍且文件大於64M時觸發

　　　　　auto-aof-rewrite-percentage 100  （一倍）
　　　　   auto-aof-rewrite-min-size 64mb
8.RDB與AOF的選擇：

　　做備份：當數據量大，且對恢復速度有要求，並且數據的一致性要求不高的話，可以只使用RDB

　　只做緩存：不用開啟任何的持久化方式

　　兩者都開啟的建議：RDB數據不實時，同時使用兩者時服務器只會找AOF文件，可不可以只使用AOF?建議不要，因為RDB更適合備份數據庫(AOF在不斷變化，不好備份)，快速重啟，而且不會又AOF可能潛在的BUG,留作萬一的手段。

9、常見配置

RDB持久化配置

Redis會將數據集的快照dump到dump.rdb文件中。此外，我們也可以通過配置文件來修改Redis服務器dump快照的頻率，在打開6379.conf文件之后，我們搜索save，可以看到下面的配置信息：

save 900 1              #在900秒(15分鍾)之后，如果至少有1個key發生變化，則dump內存快照。

save 300 10            #在300秒(5分鍾)之后，如果至少有10個key發生變化，則dump內存快照。

save 60 10000        #在60秒(1分鍾)之后，如果至少有10000個key發生變化，則dump內存快照。

AOF持久化配置

在Redis的配置文件中存在三種同步方式，它們分別是：

appendfsync always     #每次有數據修改發生時都會寫入AOF文件。

appendfsync everysec  #每秒鍾同步一次，該策略為AOF的缺省策略。

appendfsync no          #從不同步。高效但是數據不會被持久化。

　　　　　　　　　

10.優化：