Redis：持久化之RDB和AOF

RDB（Redis DataBase）

　　在指定的時間間隔內將記憶體中的資料集快照寫入硬碟

　　也就是行話講的Snapshot快照，它恢復時是將快照檔案直接讀到記憶體裡。

　　Redis會單獨建立（fork）一個子程序來進行持久化，會先將資料寫入到一個臨時檔案中，待持久化過程都結束了，再用這個臨時檔案替換上次持久化好的檔案。

　　整個過程中，主程序是不進行任何IO操作的，這就確保了極高的效能。如果需要進行大規模資料的回覆，且對於資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的資料可能丟失。

Fork

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

預設的save配置

1）15分鐘一次

2）5分鐘10次

3）1分鐘 1萬次

在redis.conf中

當滿足上訴的更新次數時，rdb會自動備份到檔案 dump.rdb 中

將dump.rdb移動至安裝目錄下啟動服務可完成恢復

優缺點

優點：

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

　　2）對資料完整性和一致性要求不高

缺點：

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

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

如何停止

redis-cli config set save ""

AOF（Append Only File）

　　以日誌的形式來記錄每個寫操作，將 Redis 執行過的所有寫指令記錄下來（讀操作不記錄），只許追加檔案但不可以改寫檔案，redis啟動之初會讀取該檔案重新構建資料，換言之，redis重啟的話就根據日誌檔案的內容將寫指令從前到後執行一次以完成資料的回覆工作。

修改配置

　　預設情況下AOF是關閉的狀態，在redis的配置檔案中搜索Append快速定位到，進行修改為 yes

　　同時可以修改預設檔名（預設為：appendonly.aof）

　　Appendfsync：

　　　　1）Always：同步持久化，一步一寫，效能較差，資料完整性高

　　　　2）everysec：出廠預設推薦，非同步操作，每秒記錄一次

　　　　3）NO

恢復同RDB，VIM可進去修改，但建議不要

修復aof檔案

　　在安裝目錄下（刪除不符合語法規範的）：　　redis-check-aof --fix aof檔案

重寫機制Rewrite什麼時候觸發:

　　Redis會記錄上次重寫時AOF大小，預設配置是當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發

優缺：

　　優點：

　　　　1）靈活的配置

　　缺點：

　　　　1）相同資料集的資料而言aof檔案要遠大於rdb檔案，恢復速度慢於rdb

　　　　2）aof執行效率要慢於rdb，每秒同步策略效率較好，不同步效率和rdb相同

總結：

1）RDB和AOF可以並存沒毛病

2）如果只做快取作用，可以不使用任何持久化方式

3）同時存在時，載入備份檔案的優先順序aof會高於rdb，因為aof相對比較完整

4）儘量不要只開啟aof而關掉rdb，因為rdb更適合用於備份資料庫（aof不斷變化不好備份），快速重啟不會有aof的潛在bug（指令語法錯誤），留著做個保障。