1.RDB概述

RDB是在某個時間點將資料寫入一個臨時檔案，持久化結束後，用這個臨時檔案替換上次持久化的檔案，達到資料恢復。

優點：使用單獨子程序來進行持久化，主程序不會進行任何IO操作，保證了redis的高效能

缺點：RDB是間隔一段時間進行持久化，如果持久化之間redis發生故障，會發生資料丟失。所以這種方式更適合資料要求不嚴謹的時候

這裡說的這個執行資料寫入到臨時檔案的時間點是可以通過配置來自己確定的，通過配置redis在n秒內如果超過m個key被修改這執行一次RDB操作。這個操作就類似於在這個時間點來儲存一次Redis的所有資料，一次快照資料。所有這個持久化方法也通常叫做snapshots。

snapshot觸發的時機，是有“間隔時間”和“變更次數”共同決定，同時符合2個條件才會觸發snapshot,否則“變更次數”會被繼續累加到下一個“間隔時間”上。snapshot過程中並不阻塞客戶端請求。snapshot首先將資料寫入臨時檔案，當成功結束後，將臨時檔案重名為dump.rdb。

2.AOF概述

Append-only file，將“操作 + 資料”以格式化指令的方式追加到操作日誌檔案的尾部，在append操作返回後(已經寫入到檔案或者即將寫入)，才進行實際的資料變更，“日誌檔案”儲存了歷史所有的操作過程；當server需要資料恢復時，可以直接replay此日誌檔案，即可還原所有的操作過程。AOF相對可靠，它和mysql中bin.log、apache.log、zookeeper中txn-log簡直異曲同工。AOF檔案內容是字串，非常容易閱讀和解析。

優點：可以保持更高的資料完整性，如果設定追加file的時間是1s，如果redis發生故障，最多會丟失1s的資料；且如果日誌寫入不完整支援redis-check-aof來進行日誌修復；AOF檔案沒被rewrite之前（檔案過大時會對命令進行合併重寫），可以刪除其中的某些命令（比如誤操作的flushall）。
缺點：AOF檔案比RDB檔案大，且恢復速度慢。

3.比較

AOF更加安全，可以將資料更加及時的同步到檔案中，但是AOF需要較多的磁碟IO開支，AOF檔案尺寸較大，檔案內容恢復數度相對較慢。

snapshot，安全性較差，它是“正常時期”資料備份以及master-slave資料同步的最佳手段，檔案尺寸較小，恢復數度較快。
• 暗裡著迷
• Redis之RDB與AOF 筆記

• 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 （不同步）
• 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.優化：