1、RDB持久化機制

就是我們俗稱的備份，他可以在定期內對資料進行備份，將Redis伺服器中的資料持久化到硬碟中；

檔案格式是：dump.rdb

快照持久化通用的配置：

RDB持久化的工作流程：

1. Redis根據配置自己嘗試生成RDB快照檔案；
2. fork一個子程序出來；
3. 子程序嘗試將資料寫到臨時的RDB快照檔案中；
4. 完成RDB快照檔案的生成之後，就替換之前舊的快照檔案；

2、AOF持久化機制

他會在執行寫命令的時候，將執行的每條寫命令以append-only的模式寫入一個日誌檔案中存放在硬盤裡面，後期恢復的時候，只需要重新執行一下這個寫命令就可以了。類似於我們的MySQL資料庫在進行主從複製的時候，使用的是binlog二進位制檔案，同樣的是執行一遍寫命令。在Redis重啟的時候，可以通過回放AOF日誌中的寫入指令來重新構建整個資料集；

檔案格式是：appendonly.aof

AOP持久化配置：

3、注意事項

1. 這兩種持久化的方式既可以單獨的使用，也可以同時使用，具體選擇哪種方式需要根據具體的情況進行選擇。
2. 如果我們想要Redis僅僅作為純記憶體的快取來用，那麼我們可以禁止RDB和AOF所有的持久化機制；
3. 通過RDB或AOF，都可以將Redis記憶體中的資料給持久化到磁碟上面來，然後可以將這些資料備份到別的地方去。我們一般會選擇非當前機器的磁碟檔案，這樣可以避免由於機器損壞等因素導致磁碟資料和記憶體資料全部丟失，一般具有一定的隔離性。比如說雲盤，雲服務等；
4. 如果Redis掛了，伺服器上的記憶體和磁碟上的資料都丟了，我們就可以從事先備份好的存放在雲盤、雲服務等地方的資料拷貝回來，放到指定的目錄中，然後重新啟動Redis，Redis就會自動根據持久化資料檔案中的資料，去恢復記憶體中的資料，繼續對外提供服務；
5. 如果同時使用RDB和AOF兩種持久化機制，那麼在Redis重啟的時候，會使用AOF來重新構建資料，因為AOF中的資料更加完整；
6. 也可以通過save或者bgsave命令同步或非同步指定RDB快照生成。
7. AOF持久化，預設是關閉的，預設是開啟RDB持久化；
8. appendonly yes，可以開啟AOF持久化機制，在生產環境裡面，一般來說AOF都是要開啟的，除非你說隨便丟個幾分鐘的資料也無所謂；

二、RDB持久化機制的優點

1、RDB會生成多個數據檔案，每個資料檔案都代表了某一個時刻中Redis的資料，這種多個數據檔案的方式，非常適合做冷備，可以將這種完整的資料檔案傳送到一些遠端的安全儲存上去。比如說Amazon的S3雲服務上去，在國內可以是阿里雲的ODPS分散式儲存上，以預定好的備份策略來定期備份Redis中的資料；

1. RDB做冷備時會生成多個檔案，每個檔案都代表了某一個時刻的完整的資料快照;
2. AOF也可以做冷備，只有一個檔案，但是你可以，每隔一定時間，去copy一份這個檔案出來;
3. RDB做冷備，優勢在哪兒呢？由Redis去控制固定時長生成快照檔案的事情，比較方便; AOF，還需要自己寫一些指令碼去做這個事情，各種定時;
4. RDB資料做冷備，在最壞的情況下，提供資料恢復的時候，速度比AOF快;

2、RDB對Redis對外提供的讀寫服務，影響非常小，可以讓Redis保持高效能，因為Redis主程序只需要fork一個子程序，讓子程序執行磁碟IO操作來進行RDB持久化即可;

1. RDB每次寫，都是直接寫Redis記憶體，只是在一定的時候，才會將資料寫入磁碟中；
2. AOF，每次都是要寫檔案的，雖然可以快速寫入os cache中，但是還是有一定的時間開銷的，速度肯定比RDB略慢一些;

3、相對於AOF持久化機制來說，直接基於RDB資料檔案來重啟和恢復Redis程序，更加快速；（為什麼恢復的時候RDB比AOF快？）

1. AOF，存放的指令日誌，做資料恢復的時候，其實是要回放和執行所有的指令日誌，來恢復出來記憶體中的所有資料的；
2. RDB，就是一份資料檔案，恢復的時候，直接載入到記憶體中即可；

結合上述優點，RDB特別適合做冷備份，冷備。

• RDB持久化機制的缺點

1、如果想要在Redis故障時，儘可能少的丟失資料，那麼RDB沒有AOF好。一般來說，RDB資料快照檔案，都是每隔5分鐘，或者更長時間生成一次，這個時候就得接受一旦Redis程序宕機，那麼會丟失最近5分鐘的資料；

這個問題，也是RDB最大的缺點，就是不適合做第一優先的恢復方案，如果你依賴RDB做第一優先恢復方案，會導致資料丟失的比較多

2、RDB每次在fork子程序來執行RDB快照資料檔案生成的時候，如果資料檔案特別大，可能會導致對客戶端提供的服務暫停數毫秒，或者甚至數秒；

一般不要讓RDB的間隔太長，否則每次生成的RDB檔案太大了，對Redis本身的效能可能會有影響的；

• AOF持久化機制的優點

1、AOF可以更好的保護資料不丟失，一般AOF會每隔1秒，通過一個後臺執行緒執行一次fsync操作，最多丟失1秒鐘的資料;

1. 每隔1秒，就執行一次fsync操作，保證os cache中的資料寫入磁碟中；
2. Redis程序掛了，最多丟掉1秒鐘的資料；

2、AOF日誌檔案以append-only模式寫入，所以沒有任何磁碟定址的開銷，寫入效能非常高，而且檔案不容易破損，即使檔案尾部破損，也很容易修；

3、AOF日誌檔案即使過大的時候，出現後臺重寫操作，也不會影響客戶端的讀寫。因為在rewrite log的時候，會對其中的指導進行壓縮，創建出一份需要恢復資料的最小日誌出來。再建立新日誌檔案的時候，老的日誌檔案還是照常寫入。

1. 當新的merge後的日誌檔案ready的時候，再交換新老日誌檔案即可。

4、AOF日誌檔案的命令通過非常可讀的方式進行記錄，這個特性非常適合做災難性的誤刪除的緊急恢復。比如某人不小心用flushall命令清空了所有資料，只要這個時候後臺rewrite還沒有發生，那麼就可以立即拷貝AOF檔案，將最後一條flushall命令給刪了，然後再將該AOF檔案放回去，就可以通過恢復機制，自動恢復所有資料；

五、AOF持久化機制的缺點

1、對於同一份資料來說，AOF日誌檔案通常比RDB資料快照檔案更大；

2、AOF開啟後，支援的寫QPS會比RDB支援的寫QPS低，因為AOF一般會配置成每秒fsync一次日誌檔案，當然，每秒一次fsync，效能也還是很高的；

如果你要保證一條資料都不丟，也是可以的，AOF的fsync設定成沒寫入一條資料，fsync一次，那就完蛋了，Redis的QPS大降；

3、以前AOF發生過bug，就是通過AOF記錄的日誌，進行資料恢復的時候，沒有恢復一模一樣的資料出來。所以說，類似AOF這種較為複雜的基於命令日誌/merge/回放的方式，比基於RDB每次持久化一份完整的資料快照檔案的方式，更加脆弱一些，容易有bug。不過AOF就是為了避免rewrite過程導致的bug，因此每次rewrite並不是基於舊的指令日誌進行merge的，而是基於當時記憶體中的資料進行指令的重新構建，這樣健壯性會好很多。

六、RDB和AOF到底該如何選擇

1、不要僅僅使用RDB，因為那樣會導致你丟失很多資料；

2、也不要僅僅使用AOF，因為那樣有兩個問題：

1. 你通過AOF做冷備，沒有RDB做冷備，來的恢復速度更快;
2. 第二，RDB每次簡單粗暴生成資料快照，更加健壯，可以避免AOF這種複雜的備份和恢復機制的bug；；

3、綜合使用AOF和RDB兩種持久化機制，用AOF來保證資料不丟失，作為資料恢復的第一選擇; 用RDB來做不同程度的冷備，在AOF檔案都丟失或損壞不可用的時候，還可以使用RDB來進行快速的資料恢復；