一、RDB持久化

RDB（Redis DataBase）：

配置檔案中對其的相關配置：

觸發機制：

恢復rdb檔案：

優點：

缺點：

二、AOF持久化

AOF（Append Only File）：

配置檔案中對其的相關配置：

恢復aof檔案：

優點：

缺點：

---

Redis中的資料存在記憶體中肯定是不安全的，所以需要將資料進行持久化操作，防止資料丟失造成的危害。

 

一、RDB持久化

RDB（Redis DataBase）：

在指定時間間隔內將記憶體中的資料集快照集體寫入磁碟，也就是Snapshot快照，恢復時將快照檔案直接讀到記憶體中。

Redis會單獨建立（fork）一個子程式來進行持久化，會先將資料寫入一個臨時檔案中，待持久化過程都結束，再用這個臨時檔案替換上次持久化好的檔案。整個過程中，主程式不進行任何IO操作。這就確保了極高的效能。如果需要進行大規模資料的恢復，且對於資料恢復的完整性不是非常敏感，那RDB方式比AOF方式更加高效。RDB的缺點是最後一次持久化後的資料可能丟失。

預設情況下時 RDB，一般不需要修改這個配置！

在主從複製中，rdb就是備用，從機上！

配置檔案中對其的相關配置：

1、RDB儲存的檔案 dump.rdb （在生成環境中經常將rdb檔案備份）

2、RDB預設的儲存規則：900s中發生一次修改就進行儲存

觸發機制：

1. save的規則滿足情況下，自動觸發rdb規則

2. 執行flushall命令，也會觸發rdb規則

3. 退出redis（合理退出 shut down命令），也會產生rdb檔案

備份就自動生成一個 dump.rdb 檔案

恢復rdb檔案：

1. 只需將rdb檔案放在redis啟動目錄就可以，redis啟動的時候會自動檢查dump.rdb 恢復其中的資料！

2. 檢視需要存放的位置：config get dir

優點：

1. 適合大規模的資料恢復！（父程式不參與資料的儲存恢復，而是fork子程式管理，效率高）

2. 對資料完整性要求不高！（比如300s內更新了9次突然當機了，那最後的資料沒來得及儲存就丟失了）

缺點：

1. 需要一定的時間間隔進行操作！如果redis意外當即，最後一次修改資料就沒

2. fork程式的時候，會佔用一定的資源！

 

二、AOF持久化

AOF（Append Only File）：

以日誌的形式將我們的所有命令都記錄下來（寫記錄讀不記錄），秩序罪加檔案不可更改檔案，redis重啟會去讀該檔案重新構建資料，換言之，把這個檔案中指令全部再執行一遍。

配置檔案中對其的相關配置：

1、儲存在 appendonly.aof（預設不開啟，開啟需要手動配置）

2、持久化策略（預設每秒寫一次）

3、重寫規則

預設是檔案的無限追加，檔案會越來越大！

當檔案大小超過64m，fork一個新的程式來講我們的檔案進行重寫

 

恢復aof檔案：

破壞/損壞 aof 檔案後，無法啟動redis（如果預設時aof模式下）

此時，可以用 redis-check-aof 來修復

 

優點：

1. 每次修改都同步，檔案的完整性會更好！

2. 沒秒同步一次，可能會丟失一秒的資料！

3. 從不同步，效率最高的！

缺點：

1. 相對於資料檔案來說，aof遠遠大於rdb，修復的速度也比rdb慢！

2. aof執行效率也要比rdb慢，所以redis預設配置是rdb！