Redis的持久化

1、RDB（Redis DateBase）

RDB持久化是什麼：

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

RDB過程圖：

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

整個過程中，主程序是不進行任何IO操作的，這就確保了極高的效能，如果需要進行大規模資料的恢復，且對於資料恢復的完整性不是非常敏感，那麼RDB方式要比AOF方式更加高效。

RDB的缺點是最後一次持久化後的資料可能丟失

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

RBD 儲存的是dump.rdb檔案

如何觸發RDB快照

• 滿足配置檔案中預設的快照配置

• 命令save或者是bgsave

  Save：save時只管儲存，其它不管，全部阻塞

  bgsave：Redis會在後臺非同步進行快照操作，同時還可以響應客戶端請求。可以通過lastsave命令獲取最後一次成功執行快照的時間

• 執行flushall命令，也會產生dump.rdb檔案，但是裡面是空的，無意義

如何恢復：

將備份檔案（dump.rdb）移動到redis安裝目錄並啟動服務即可

config get dir 獲取目錄

優勢：

• 適合大規模的資料恢復
• 對資料完整性和一致性要求不高

劣勢：

• 在一定時間間隔做一次備份，所以如果redis意外宕機的話，就會丟失最後一次快照後的所有修改
• Fork的時候，記憶體中的資料被克隆了一份，大致2倍的膨脹性需要考慮

如何停止：

動態所有停止RDB儲存規則的方法：redis-cli config set save “”

RDB總結：

2、AOF （Append Only File）

AOF流程圖：

是什麼：

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

AOF儲存的是appendonly.aof

AOF啟動/修復/恢復：

• 正常恢復

  啟動：設定yes，修改預設的appendonly no，改為yes

  將有資料的aof檔案複製一份儲存到對應目錄（config get dir）

  恢復：重啟redis然後重新載入

• 異常恢復：

  啟動：設定yes，修改預設的appendonly no，改為yes

  備份被寫壞的aof檔案

  修復：Redis-check-aof --fix進行修復

  恢復：重啟redis然後重新載入

AOF的Rewrite：

是什麼：

aof採用檔案追加方式，檔案會越來越大為避免出現此種情況，新增了重寫機制，當aof檔案的大小超過所設定的閾值時，Redis就會啟動aof檔案的內容壓縮，只保留可以恢復資料的最小指令集，可以使用命令bgrewriteaof（手動觸發）

重寫原理：

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

觸發機制：

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

優勢：

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

每秒同步：appendfsync everysec 非同步操作，每秒記錄 如果一秒內宕機，所有資料丟失

不同步：appendfsync no 從不同步

劣勢：

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

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

總結：

應用總結：

RDB持久化方式能夠在指定的時間間隔能對你的資料進行快照儲存。

AOF持久化方式記錄每次對伺服器寫的操作，當伺服器重啟的時候會重新執行這些命令來恢復原始的資料，AOF命令以redis協議追加儲存每次寫的操作到檔案尾部。

Redis還能對AOF檔案進行後臺重寫，使得AOF檔案的體積不至於過大

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

同時開啟兩種持久化方式：

在這種情況下，當redis重啟的時候會優先載入AOF資料夾來恢復原始的資料，因為通常情況下AOF檔案儲存的資料集比RDB檔案儲存的資料集要完整。

RDB的資料不實時，同時使用兩者時伺服器重啟也只會找AOF檔案。那要不要只使用AOF呢？

建議不要，因為RDB更適合用於備份資料庫（AOF在不斷變化不好備份），快速重啟，而且會不會AOF可能潛在的bug，留著作為一個萬一的手段。

效能建議：

因為RDB檔案只用作後備用途，建議只在Slave上持久化RDB檔案，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。

如果Enable AOF 好處是在最惡劣情況下也只會丟失不超過兩秒資料，啟動時指令碼較簡單隻load自己的AOF檔案就可以了。代價一是帶來了持續的IO，二是AOF rewrite的最後將rewrite過程中產生的新資料寫到新的檔案造成的阻塞幾乎是不可避免的。只要硬碟許可，應該儘量減少AOF rewrite的頻率，AOF重寫的基礎大小預設值64M太小了，可以設到5G以上。預設超過原大小100%大小時重寫可以改到適當的數值。

如果不Enable AOF，僅靠Master-Slave Replication實現高可用性也是可以。能省掉一大筆IO也減少了rewrite是帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的資料，啟動指令碼也要比較兩個Master/Slave中RDB檔案，載入比較新的那個。

able AOF，僅靠Master-Slave Replication實現高可用性也是可以。能省掉一大筆IO也減少了rewrite是帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的資料，啟動指令碼也要比較兩個Master/Slave中RDB檔案，載入比較新的那個。