## 兩種持久化方法的基本原理 * RDB持久化:將Reids在內存中的數據庫記錄定時dump到磁盤上的RDB持久化 * AOF定義：以日志的形式記錄每個操作，將Redis執行過的所有指令全部記錄下來（讀操作不記錄），只許追加文件但不可以修改文件.Redis啟動時會讀取AOF配置文件重構數據,換句話說，就是Redis重啟就會根據日志內容從頭到尾執行一次來完成數據的恢復工作。 >一.RDB與AOF同時開啟 默認先加載AOF的配置文件 二.相同數據集，AOF文件要遠大于RDB文件，恢復速度慢于RDB 三.AOF運行效率慢于RDB,但是同步策略效率好，不同步效率和RDB相同 ### RDB持久化基本配置實現 1. RDB持久化(以快照的方式) 策略（默認）： 　　save 900 1 （15分鐘變更一次） 　　save 300 10 （5分鐘變更10次） 　　save 60 10000 （1分鐘變更1萬次） 2. RDB默認配置文件名稱： 　　dbfilename dump.rdb > 如果關閉RDB持久化方式，就把配置注釋掉 ### AOF持久化配置實現 1. 表示是否開啟AOF持久化： 　　appendonly yes(默認no,關閉) 2. AOF持久化配置文件的名稱： 　　appendfilename "appendonly.aof" 3. AOF持久化策略(默認每秒)： 　　appendfsync always (同步持久化，每次發生數據變更會被立即記錄到磁盤，性能差但數據完整性比較好) 　　appendfsync everysec (異步操作，每秒記錄，如果一秒鐘內宕機，有數據丟失，性能與數據安全折中，推薦) 　　appendfsync no （不同步） 4. AOF配置文件損壞修復方法： 　　進入redis安裝路徑 執行 redis-check-aof --fix AOF配置文件名稱 5. 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 ``` ## RDB與AOF的選擇： * 做備份：當數據量大，且對恢復速度有要求，并且數據的一致性要求不高的話，可以只使用RDB * 只做緩存：不用開啟任何的持久化方式 * 兩者都開啟的建議：RDB數據不實時，同時使用兩者時服務器只會找AOF文件. > 可不可以只使用AOF?作者建議不要，因為RDB更適合備份數據庫(AOF在不斷變化，不好備份) ## 優化：  * 建議一種使用方式:redis主從結構，只在slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留save 900 1 這條規則 * 在高并發大數據量寫的情況下，不建議配置自動保存RDB。在RDB保存時會fock創建一個子進程，此操作過程父進程會阻塞！ ## 參考 　　 [redis數據丟失及解決](http://blog.csdn.net/xiangliangyu/article/details/8165644)