RDB的問題
1：fork
一個進(jìn)程時，內(nèi)存的數(shù)據(jù)也被復(fù)制了，即內(nèi)存會是原來的兩倍
2：每次快照持久化都是將內(nèi)存數(shù)據(jù)完整寫入到磁盤一次，并不是增量的只同步臟數(shù)據(jù)。
如果數(shù)據(jù)量大的話，而且寫操作比較多，必然會引起大量的磁盤io操作，可能會嚴(yán)重影響性能。
3：由于快照方式是在一定間隔時間做一次的，所以如果redis意外down掉的話，就會丟失最后一次快照后的所有修改。
觸發(fā)快照的情況
1：根據(jù)配置規(guī)則進(jìn)行自動快照
2：用戶執(zhí)行save或bgsave命令
3：執(zhí)行flushall命令
4：執(zhí)行復(fù)制replication時
save命令執(zhí)行
Save命令時，Redis會阻塞所有客戶端的請求，然后同步進(jìn)行快照操作。
bgsave命令
執(zhí)行bgsave命令時，Redis會在后臺異步進(jìn)行快照操作，快照同時還可以響應(yīng)客戶端請求?？梢酝ㄟ^lastsave命令獲取最后一次成功執(zhí)行快照的時間。
flushall命令
這個命令會導(dǎo)致redis清除內(nèi)存中的所有數(shù)據(jù)，如果定義了自動快照的條件，那么無論是否滿足條件，都會進(jìn)行一次快照操作；如果沒有定義自動快照的條件，那么就不執(zhí)　　　 行快照
AOF的問題
默認(rèn)的AOF持久化策略是每秒鐘fsync一次，fsync是指把緩存中的寫指令記錄到磁盤中，
在這種情況下，redis扔可以保持很高的性能
當(dāng)然由于OS會在內(nèi)核中緩存write做的修改，所以可能不是立即寫到磁盤上。
這樣aof方式的持久化也還是有可能會丟失部分修改。不過可以通過配置文件告訴redis，想要通過fsync函數(shù)強(qiáng)制os寫入磁盤的時機(jī)
AOF方式在同等數(shù)據(jù)規(guī)模的情況下，AOF文件要比RDB文件的體積大，因此AOF方式的恢復(fù)速度也要慢于RDB方式
AOF日志恢復(fù)
如果在追加日志時，恰好遇到磁盤空間滿或斷電等情況，導(dǎo)致日志寫入不完整，也沒有關(guān)系，
redis提供了redis-check-aof工具，可以用來進(jìn)行日志修復(fù)，基本步驟如下：
1、備份被寫壞的AOF文件
2、運(yùn)行redis-check-aof -fix進(jìn)行修復(fù)
3、用diff -u來看下兩個文件的差異，確認(rèn)問題點(diǎn)
4、重啟redis，加載修復(fù)后的AOF文件
AOF重寫
AOF采用文件追加方式，這樣會導(dǎo)致AOF文件越來越大，為此，redis提供了AOF文件重寫（rewrite）機(jī)制，即當(dāng)AOF文件的大小超過所
設(shè)定的閾（yu）值時，redis就會啟動AOF文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集。可以使用命令bgrewriteaof.