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

 本回答由網(wǎng)友推薦