一、rdb（redis database）：在指定的時間間隔內將記憶體中的資料集快照寫入到本地磁碟，也就是行話講的snapshot快照，它恢復時是將快照檔案直接讀到記憶體中。

1、備份：記憶體到磁碟。恢復：快照檔案從磁碟讀回到記憶體。

2、redis會單獨建立（fork）一個子程序來進行持久化，先將資料寫入到一個臨時檔案(dump.rdb)中，待持久化過程都結束了，在用這個臨時檔案替換上次持久化好的檔案。新的替換舊的，在整個過程當中，主程序不進行任何io操作，這就確保了極高的效能。如果需要進行大規模的資料恢復，且對於資料的精度要求不高，那rdb方法比aof更加高效。rdb的缺點是最後一次持久化後的資料可能丟失。

3、fork的作用是複製一個與當前程序一樣的程序。新程序的所有資料（變數、環境變數、程式計數器等）數值都和原程序一致，但是是一個全新的程序，並且作為原程序的子程序。

4、如何觸發rdb快照：

（1）：配置檔案中預設的快照配置，冷拷貝後重新使用，可以cp dump.rdb dump_new.rdb

（2）：命令save或者bgsave save:只管儲存，其他不管，全部阻塞 bgsave:redis在後臺非同步進行快照操作，快照同時還可以響應客戶端的請求。可以通過lastsave命令獲取最後一次成功執行快照的時間

（3）：Flushall也會產生dump.rdb檔案，但裡面是空的，無意義。

4、資料如何恢復：將備份檔案移動到

5、優勢：

（1）：適合大規模的資料恢復。

（2）：對資料的一致性和完整性要求不高。

6、劣勢：

（1）：在一定間隔時間內做一次備份，所以redis意外down掉的話，就會丟失最後一次快照後的所有修改。

（2）：fork的時候，記憶體中的資料被克隆了一份，大致2倍的膨脹性需要考慮。

二：aof（append only file）：以日誌的形式來記錄每個寫操作，將redis執行過的所有寫指令記錄下來（讀操作不記錄），只有追加檔案但不可以修改檔案，redis啟動之初會讀取該檔案重新構建資料，換言之，redis啟動的話就是根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的恢復工作（其實更狠的是redis

1、若appendonly.aof檔案損壞，則不能啟動redis。修復appendonly.aof檔案，redis-check-aof --fix appendonly.aof。

2、appendonly.aof檔案和dump.rdb可以同時存在，這種情況下，redis首先會去載入appendonly.aof檔案。

3、Aof的配置策略：

Always：同步持久化 每次發生資料變更會被立即記錄到磁碟 效能較差但資料完整性比較好。

Everysec：出廠預設推薦，非同步操作，每秒記錄，如果一秒內宕機，則有資料丟失。

No

4、aof的rewrite重寫：aof採用檔案追加的形式，檔案會越來越大為了避免出現這種情況，新增了重寫機制，當aof檔案的大小超過所設定的閾值時，redis就會啟動aof檔案的內容壓縮。

重寫原理：aof檔案會持續增加而過大時，會fork出一條新的程序來將檔案重寫（也就是先寫臨時檔案最後在rename），遍歷新程序的記憶體中的資料，每條記錄有一條的set語句。重寫aof檔案的操作，並沒有去讀取舊的aof檔案，而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的aof檔案，這一點和快照有點類似。

觸發重寫機制：redis會記錄上次重寫時的aof的檔案的大小，預設配置是當aof檔案大小是上次rewrite後大小的一倍並且檔案大於64m時觸發。

conf檔案中的配置：auto-aof-rewrite-percentage 設定重寫的百分比

Auto-aof-rewrite-min-size 64mb 設定重寫的基準值

No-appendfsync-on-rewrite：重寫時是否可以運用appendfsync,使用預設no即可，保證資料的安全性。

5、優勢：

（1）、同步持久化，每發生資料變更時會被立即記錄到磁碟中，效能較差但資料性比較狠。

（2）、非同步操作，每秒記錄 如果一秒內宕機，有資料丟失。

（3）、不同步。

6、劣勢：
（1）、相同資料集的資料而言aof檔案要遠大於rdb檔案，恢復速度慢與rdb。

（1）、aof執行效率慢於rdb，每秒同步策略較好，不同步效率和rdb相同。

8、只做快取：如果只希望你的資料在伺服器執行的時候存在，你也可以不使用任何持久化方式。

9、同時開啟：redis重啟的時候會首先載入aof檔案，因為通常情況下aof檔案儲存的資料集要比rdb儲存的資料集完整。也不要只使用aof，因為rdb更適合於備份資料庫（aof在不斷的變化不好備份）。

10、效能建議：

（1）、因為rdb只用作後備用途，建議只在slave上持久化rdb檔案，而且只要15分鐘備份一次即可。

（2）如果Enable Aof，好處是在最惡劣的情況下只會丟失不會超過1秒的資料，啟動指令碼較簡單隻load自己的aof檔案就可以了。代價一是帶來了持續的io，二是aof rewrite的最後將rewrite過程中產生的資料寫到新檔案造成的阻塞幾乎是不可避免的。只要硬碟許可，應該減少重寫的頻率，比如aof重寫預設的基礎值太小了，可以設定到5G以上。

（3）、如果不Enable Aof，僅依靠Master-Slave Replication實現高可用也可以。能省掉一大筆的io操作。代價是如果Master-Slave同時倒掉，會丟失十幾分鐘的資料，啟動指令碼也需要比較兩個Master-Slave中的rdb檔案，載入比較新的那一個。