Redis持久化機制

​ 我們知道redis是一種基於記憶體的資料庫,一旦系統宕機,redis儲存在記憶體中的資料就會全部丟失,。如果僅僅是將reids作為資料庫的快取來使用的情況,我們還可以將資料重新載入到redis, 不會有太大的影響, 對於將redis作為資料庫來使用的情況,資料丟失就會引發生產問題。

Redis的兩種持久化方式

一、RDB

RDB 即快照方式，它將某個時間點的所有 Redis 資料儲存到一個經過壓縮的二進位制檔案中, 是Redis預設採用的持久化機制。

RDB方式的優點

• 恢復大資料集時，RDB 比 AOF 更快, 因為其二進位制儲存的形式更加緊湊。

缺點

• 如果系統發生故障，將會丟失最後一次建立快照之後的資料。
• 如果資料量很大，儲存快照的時間會很長。

觸發方式

• save命令
  save本身是單執行緒序列方式執行，因此當資料量大時，可能會發生Redis Server的長時間卡頓。

• bgsave命令
  bgsave命令在執行時，會fork一個子程序。子程序提交完成後，會立即給客戶端返回響應，備份操作在後臺非同步執行，期間不會影響Redis的正常響應。對於bgsave來說，當父程序Fork完子程序之後，非同步任務會將當前的記憶體狀態作為一個版本進行復制 在複製過程中產生的變更，不會反映在這次備份當中。

• 定時任務觸發
  Redis 允許使用者通過設定伺服器配置的 save 選項，讓伺服器每隔一段時間自動執行儲存快照命令。
  

  Redis的預設配置:
  save 900 1 900秒內,至少對資料庫進行了1次修改
  save 300 10 300秒內,至少對資料庫進行了10次修改
  save 60 10000 60秒內,至少對資料庫進行了10000次修改
  只要滿足上面任一個條件,伺服器就會執行bgsave命令生成快照

二、AOF(Append Only File)

將所有修改類的命令以文字日誌的形式記錄到檔案中, 以此來記錄資料的變化過程。當伺服器重啟時，重新執行一遍 AOF 檔案中的命令，就可以恢復原始的資料。

開啟方式: 通過 appendfsync yes配置來開啟AOF持久化機制。

Redis並不是每有一條更新類的命令就會將其寫入到AOF檔案中, 命令會先進入到AOF緩衝區(記憶體中), Redis每隔一定的時間將其追加到AOF檔案中。可以通過appendfsync配置寫入檔案的時間間隔。

持久化配置:

• appendfsync always 每有一條命令就寫入到AOF檔案中, 這種方式效能很差,生產環境一般不使用這種方式。
• appendfsync ererysec 每隔1秒鐘,Redis將緩衝區中的命令追加到AOF檔案中, 也是AOF機制下,Redis的預設方式。生產環境中一般採用這種方式。
• appendfsync no 由作業系統決定不定時地將緩衝區中的內容同步到AOF檔案, 不推薦這種方式。

AOF 的優缺點

• 如果系統發生故障，AOF 丟失資料比 RDB 少, 如在預設每1秒同步一次的情況下,最多損失一秒的資料。
• 恢復大資料集時，AOF 比 RDB 慢。

AOF重寫

Redis 在長期執行的過程中，AOF 的日誌會越變越長。如果例項宕機重啟，重放整個 AOF 日誌會非常耗時。

Redis 提供了 bgrewriteaof 指令用於對 AOF 日誌進行瘦身。其 原理 就是 開闢一個子程序 對記憶體進行 遍歷 轉換成一系列 Redis 的操作指令，序列化到一個新的 AOF 日誌檔案 中。序列化完畢後再將操作期間發生的 增量 AOF 日誌 追加到這個新的 AOF 日誌檔案中，追加完畢後就立即替代舊的 AOF 日誌檔案了，瘦身工作就完成了

備份的載入

當Redis重啟時會自動載入備份檔案進行資料恢復, 當rdb檔案和aof檔案同時存在時,會優先使用aof檔案進行資料恢復, 因為大多數情況下aof檔案的資料要比rdb檔案更為完整。

​