redis提供了三種持久化的方案，將內(nèi)存中的數(shù)據(jù)持久化寫入磁盤。
1、RDB（快照）持久化：保存某個時間點的全量數(shù)據(jù)快照。特定的時間間隔保存那個時刻的全量數(shù)據(jù)。
打開conf配置文件，
第一個框表示：
900秒內(nèi)有1個寫入操作，就RDB一次。
300秒內(nèi)有10個寫入操作，就RDB一次。
60秒內(nèi)有10000個寫入操作，就RDB一次。
第二個框表示：
當備份進程出錯的時候，主進程就停止接收新的寫入操作，保證持久化的數(shù)據(jù)的一致性。
第三個框表示：
RDB文件的壓縮選項，Yes表示將RDB文件壓縮后再去做保存。建議設(shè)置成no，因為redis是CPU密集型服務(wù)區(qū)，開啟壓縮后會帶來更多的CPU的消耗，相比硬盤成本，CPU更值錢。
RDB文件通過兩個命令來生成：
SAVE:阻塞redis的服務(wù)器進程，直到RDB文件被創(chuàng)建完畢。在主線程中保存快照，redis是用一個主線程來處理所有請求的，這種方式會阻塞所有客戶端的請求。
BGSAVE:Fork出一個子進程來創(chuàng)建RDB文件，不阻塞服務(wù)器進程，記錄接收BGSAVE當時的數(shù)據(jù)庫狀態(tài)，父進程繼續(xù)處理接收到的命令，子進程完成文件的創(chuàng)建之后，會發(fā)送信號給父進程。
BGSAVE原理
1>執(zhí)行BGSAVE之后會去檢查當前主進程有沒有正在進行AOF/RDB的子進程。如果有，返回錯誤。（防止子線程之間的競爭）
2>如果沒有，觸發(fā)持久化，調(diào)用rdbSaveBackground。
3>再之后，執(zhí)行fork系統(tǒng)調(diào)用（本質(zhì)調(diào)用操作系統(tǒng)的系統(tǒng)調(diào)用fork指令）。
4>fork指令創(chuàng)建進程，linux下實現(xiàn)了Copy-on-Write。傳統(tǒng)方式下的話，直接把所有資源復制給子進程，實現(xiàn)簡單但是效率低下，而且復制的資源可能對子進程毫無用處。
（linux下，內(nèi)核只為子進程創(chuàng)建虛擬空間，父子兩個進程使用的是相同的物理空間，只有父進程發(fā)生更改時才會對子進程分配獨立的物理空間。）
自動化觸發(fā)RDB持久化的方式
1>根據(jù)配置redis.conf的save就可以(用的bgsave)
2>主從復制時，主節(jié)點自動觸發(fā)
3>執(zhí)行Debug Reload
4>執(zhí)行shutdown且沒有開啟AOF持久化
2、AOF持久化：通過保存redis服務(wù)器所執(zhí)行的寫狀態(tài)來記錄數(shù)據(jù)庫的。
RDB備份數(shù)據(jù)庫狀態(tài)，AOF備份數(shù)據(jù)庫接受到的指令。所有被寫入AOF的命令都是以redis的協(xié)議格式來保存的，在AOF持久化的文件中，數(shù)據(jù)庫會記錄下所有變更數(shù)據(jù)庫的命令。
那現(xiàn)在有一個問題，比如說redis現(xiàn)在做一個定時器，輪詢100下，那其實我們想要的結(jié)果是最后的數(shù)據(jù)，但是AOF會把整個過程記錄下來，所以AOF文件大小會不斷增大。怎么辦呢？
BGREWRITEAOF命令來重寫
1>調(diào)用fork()，創(chuàng)建一個子進程
2>子進程把新的AOF寫到一個臨時文件里，不依賴原來的AOF文件
3>主進程持續(xù)將新的變動同時寫到內(nèi)存和原來的AOF里
4>主進程獲取子進程重寫AOF的信號之后，往新的AOF同步增量變動
5>使用新的AOF文件替換舊的AOF文件
RDB和AOF的優(yōu)缺點比較
1>
RDB優(yōu)點：全量數(shù)據(jù)快照，文件小，恢復快
RDB缺點：無法保存最近一次快照之后的數(shù)據(jù)
2>
AOF優(yōu)點：可讀性高，適合保存增量數(shù)據(jù)，數(shù)據(jù)不易丟失
AOF缺點：文件體積大，恢復時間長
RDB-AOF混合
redis4.0之后推出RDB-AOF混合持久化方式，并且是默認配置。
BGSAVE做鏡像全量持久化，AOF做增量持久化。
在redis實例重啟時，會使用BGSAVE持久化文件重新構(gòu)建內(nèi)容，再使用AOF重放近期的操作指令。
