技術標籤：Redisredis

1、持久化RDB

1.1、RDB是什麼

• 在指定的時間間隔內將記憶體中的資料集快照寫入磁碟，也就是行話講的Snapshot快照，它恢復時是將快照檔案直接讀到記憶體裡
• Redis會單獨建立（fork）一個子程序來進行持久化，會先將資料寫入到 一個臨時檔案中，待持久化過程都結束了，再用這個臨時檔案替換上次持久化好的檔案。 整個過程中，主程序是不進行任何IO操作的，這就確保了極高的效能。如果需要進行大規模資料的恢復，且對於資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的資料可能丟失。

Fork

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

• rdb 儲存的是dump.rdb檔案
• 相關配置在配置檔案的位置 - 在redis.conf搜尋### SNAPSHOTTING ###

1.2、如何觸發RDB快照

###################################  SNAPSHOTTING  ###################################
 
#RDB核心規則配置 save <指定時間間隔> <執行指定次數更新操作>，滿足條件就將記憶體中的資料同步到硬碟
中。官方出廠配置預設是 900秒內有1個更改，300秒內有10個更改以及60秒內有10000個更改，則將記憶體中的
資料快照寫入磁碟。
若不想用RDB方案，可以把 save "" 的註釋開啟，下面三個註釋
#   save ""
save 900 1
save 300 10
save 60 10000
 

配置檔案中預設的快照配置

dbfilename dump.rdb

我們結束redis會生成一個dump.rdb檔案,將dump.rdb檔案複製一份改名為dump-newname.rdb檔案,我們在啟動redis修改資料的時候不小心清空了所有資料,我們這時候就可以吧dump-newname.rdb改為dump.rdb,再次重新啟動就會自動恢復上一次的資料。

save命令和bgsave

如果我們不想等待配置檔案裡面的儲存時間,寫完資料立即儲存

例子:

127.0.0.1:6379> set k1 1
OK
127.0.0.1:6379> save 或者 bgsave

命令save或者是bgsave

• Save：save時只管儲存，其它不管，全部阻塞
• BGSAVE：Redis會在後臺非同步進行快照操作， 快照同時還可以響應客戶端請求。可以通過lastsave 命令獲取最後一次成功執行快照的時間

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

1.3、RDB如何恢復

• 將備份檔案 (dump.rdb) 移動到 redis 安裝目錄並啟動服務即可
• CONFIG GET dir獲取目錄

1.4、RDB的優勢與劣勢

• 優勢
  • 適合大規模的資料恢復
  • 對資料完整性和一致性要求不高
• 劣勢
  • 在一定間隔時間做一次備份，所以如果redis意外down掉的話，就 會丟失最後一次快照後的所有修改
  • Fork的時候，記憶體中的資料被克隆了一份，大致2倍的膨脹性需要考慮

1.5、RDB如何停止

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

1.6、小結

• RDB是一個非常緊湊的檔案。
• RDB在儲存RDB檔案時父程序唯一需要做的就是fork出一個子程序，接下來的工作全部由子程序來做，父程序不需要再做其他I0操作，所以RDB持久化方式可以最大化redis的效能。
• 與AOF相比，在恢復大的資料集的時候，RDB方式會更快一一些。
• 資料丟失風險大。
• RDB需要經常fork子程序來儲存資料集到硬碟上，當資料集比較大的時候fork的過程是非常耗時的嗎，可能會導致Redis在一些毫秒級不能迴應客戶端請求。

2、持久化AOF

2.1、AOF是什麼

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

2.2、AOF配置

• 相關配置在配置檔案的位置 - 在redis.conf搜尋### APPEND ONLY MODE ###
• aof儲存的是appendonly.aof檔案（在配置檔案可修改檔名）

2.3、AOF啟動/修復/恢復

• 正常恢復
  • 啟動：設定Yes
    • 修改預設的appendonly no，改為yes
  • 將有資料的aof檔案複製一份儲存到對應目錄(config get dir)
  • 恢復：重啟redis然後重新載入
• 異常恢復
  • 啟動：設定Yes
    • 修改預設的appendonly no，改為yes
  • 備份被寫壞的AOF檔案
  • 修復：
    • Redis-check-aof --fix進行修復
  • 恢復：重啟redis然後重新載入

突然斷電,我們寫的資料只寫到了一半,我們啟動redis載入xxx.aof是啟動不起來的,因為讀取不到正確的資料,我們可以用Redis-check-aof --fix xxx.aof進行修復,剔除不正常的資料。

2.4、rewrite

• 是什麼：
  • AOF採用檔案追加方式，檔案會越來越大。為避免出現此種情況，新增了重寫機制， 當AOF檔案的大小超過所設定的閾值時，Redis就會啟動AOF檔案的內容壓縮， 只保留可以恢復資料的最小指令集。可以使用命令bgrewriteaof
• 重寫原理
  • AOF檔案持續增長而過大時，會fork出一條新程序來將檔案重寫(也是先寫臨時檔案最後再rename)， 遍歷新程序的記憶體中資料，每條記錄有一條的Set語句。重寫aof檔案的操作，並沒有讀取舊的aof檔案， 而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的aof檔案，這點和快照有點類似
• 觸發機制
  • Redis會記錄上次重寫時的AOF大小，預設配置是當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發

2.5、優勢與劣勢

• 優勢
  • 每修改同步：appendfsync always 同步持久化 每次發生資料變更會被立即記錄到磁碟 效能較差但資料完整性比較好
  • 每秒同步：appendfsync everysec 非同步操作，每秒記錄 如果一秒內宕機，有資料丟失
  • 不同步：appendfsync no 從不同步
• 劣勢
  • 相同資料集的資料而言aof檔案要遠大於rdb檔案，恢復速度慢於rdb
  • Aof執行效率要慢於rdb,每秒同步策略效率較好，不同步效率和rdb相同

2.6、小結

• AOF檔案時一個只進行追加的日誌檔案
• Redis可以在AOF檔案體積變得過大時，自動地在後臺對AOF進行重寫
• AOF檔案有序地儲存了對資料庫執行的所有寫入操作，這些寫入操作以Redis協議的格式儲存，因此AOF檔案的內容非常容易被人讀懂，對檔案進行分析也很輕鬆
• 對於相同的資料集來說，AOF檔案的體積通常要大於RDB檔案的體積
• 根據所使用的fsync 策略，AOF的速度可能會慢於RDB