[[411832]]

Redis持久化

為什么需要持久化

其實在我們工作中也有多持久化場景，比如word。它的持久化形式是以~$論文.docx的形式來持久化。

那么在Redis中為了防止數據意外丟失，確保數據安全，也會進行持久化。

利用永久性存儲介質將數據進行保存，在特定的時間將保存的數據進行恢復的工作機制稱為持久化。

在Redis中有兩種持久化方式：RDB(Redis DataBase)、AOF(Append Only File)。

RDB(Redis DataBase)將當前數據狀態進行保存，快照形式，存儲數據結果，存儲格式簡單，關注點在數據。

AOF(Append Only File)將數據的操作過程進行保存，日志形式，存儲操作過程，存儲格式復雜，關注點在命令。

RDB持久化

在Redis中可以使用save命令來執行一次RDB持久化操作.

save指令相關配置：

dbfilename.dump.rdb 
 說明：設置本地數據庫文件名，默認值為dump.rdb 
 
dir 
 說明：設置存儲.rdb文件的路徑 
 
rdbcompression yes 
 說明：設置存儲至本地數據庫時是否壓縮數據，默認為yes，采用LZF壓縮 
  
rdbchecksum yes 
 說明：設置是否進行RDB文件格式校驗，該校驗在寫文件和讀文件過程均進行 

我們知道早期Redis版本是單線程的。當我們執行save命令時會阻塞當前Redis服務器，直到RDB過程完成為止，有可能會造成長時間阻塞，線上環境不建議使用。

那么問題來了，既然使用save會對線上服務器造成影響，那么有沒有一種更好的持久化方式呢?答案是有的，那就是bgsave.

通過名稱可以看出這個持久化操作是后臺執行的，不會導致Redis發生阻塞。

下面看一下bgsave的工作原理：

可以看出，當執行bgsave命令后Redis會fork出一個子進程，用于創建RDB文件進行持久化，這樣一來就不會阻塞Redis了。但是bgsave不會立即執行，且會消耗額外的CPU資源。

bgsave命令是針對save阻塞問題做的優化。Redis內部所有涉及到RDB操作都采用bgsave的方式，save命令可以放棄使用。

bgsave指令相關配置：

dbfilename.dump.rdb 
 說明：設置本地數據庫文件名，默認值為dump.rdb 
 
dir 
 說明：設置存儲.rdb文件的路徑 
 
rdbcompression yes 
 說明：設置存儲至本地數據庫時是否壓縮數據，默認為yes，采用LZF壓縮 
  
rdbchecksum yes 
 說明：設置是否進行RDB文件格式校驗，該校驗在寫文件和讀文件過程均進行 
  
stop-writes-on-bgsave-error yes 
 說明：后臺存儲如果出現錯誤，是否停止保存操作 

那么問題又來了，我們不可能一直手動去執行或者bgsave指令，這時Redis為我們提供了自動執行bgsave的功能。

在Redis的配置文件中有這么一個配置save [secone] [changes]可以幫助我們自動進行持久化。

配置： 
 save second changes 
  
作用： 
 滿足限定時間范圍內key的變化數量達到指定數量即進行持久化 
  
參數： 
 second：監控時間范圍 
 changes：監控key的變化量 
  
位置： 
 在conf文件中進行配置 
  
范例： 
 save 900 1 
 save 300 10 
 save 60 10000 

注意: save配置要根據實際業務情況進行設置，頻度過高或過低都會出現性能問題，結果可能是災難性的 save配置中對于second與changes設置通常具有互補對應關系，盡量不要設置成包含性關系 save配置啟動后執行的是bgsave操作

RDB三種持久化方式對比：

RDB的優點：

• RDB是一個緊湊的壓縮二進制文件，存儲效率高
• RDB是內部存儲的在Redis某個時間點的數據快照，非常適用于數據備份，全量復制等場景
• RDB恢復數據的速度要比AOF快的多
• 服務器每X個小時執行bgsave備份，并將RDB文件拷貝至遠程機器中，用于災難恢復

RDB的缺點：

• RDB無論是執行指令還是利用配置，都無法做到實時持久化，具有較大的可能性丟失數據
• bgsave每次執行都會fork創建子進程，要犧牲掉一些性能
• Redis眾多版本中，沒有對RDB文件格式統一，有可能出現各版本數據不兼容的情況

AOF持久化

AOF(Append Only File)持久化，以獨立日志的方式記錄每次寫命令，重啟時再重新執行AOF文件中的命令達到恢復數據的目的。與RDB相比可以簡單描述為數據產生的過程。

AOF主要作用是解決了持久化的實時性，目前已經是Redis持久化的主流方式。

AOF持久化過程

在把AOF命令緩沖區同步到文件時有三種寫數據策略(appendfsync)：

always(每次) 
 每次寫入操作均同步到AOF文件中，數據零誤差，但性能較低 
  
everysec（每秒） 
 每秒將緩沖區中的指令同步到AOF文件中，數據準確性較高，性能也較高 
 在系統突然宕機是會丟失1秒內的數據 
  
no（系統控制） 
 由操作系統每次同步到AOF文件的周期，整體過程不可控 

Redis開啟AOF功能持久化

配置：

appendonly yes|no 
 作用：是否開啟AOF持久化，默認為不開啟狀態 
  
appendfsync always|everysec|no 
 作用：AOF同步命令數據策略 
  
appendfilename filename 
 AOF持久化文件名，默認文件名為appendonly.aof,建議配置成appendonly-端口號.aof 

AOF在遇到相同命令是如何處理呢

假如同步策略是 appendfsync everysec每秒同步一次，執行如下命令：

set name zhangsan 
set name lisi 
set name wangwu 

最終AOF文件里將只有一條：

set name wangwu 

AOF重寫

隨著AOF文件不斷寫入，AOF文件會越來越大，為了解決這個問題，Redis引入了AOF重寫機制壓縮文件體積。

AOF文件重寫是將Redis進程內的數據轉化為寫命令同步到新AOF文件的過程。簡單說就是將若干條命令執行結果轉化成最終結果數據對應的指令進行記錄。

AOF 重寫的作用

• 降低磁盤占用量，提高磁盤利用率
• 提高持久化效率，降低持久化時間，提高IO性能
• 降低數據恢復的時間，提高數據恢復效率

AOF重寫的規則

• 進程內已經超時的命令不再寫入文件
• 忽略無效指令，重寫時使用進程內數據直接生成，這樣新的AOF中只保留最終數據的寫入命令

del key1 
hdel key2 

• 對同一數據寫命令合并為一條命令

如下命令： 
lpush list1 a、lpush list1 b、 lpush list1 c 
可以轉化為： 
lpush list1 a b c。 
 
為防止數據量過大造成客戶端緩沖區溢出，對list、set、hash、zset等類型，每條指令最多寫入64個元素 

AOF重寫規則

• 手動重寫

bgrewriteaof 

• 自動重寫

auto-aof-rewrite-min-size size 
auto-aof-rewrite-percentage percentage 

AOF重寫流程

AOF持久化+重寫：

• 執行set等命令
• 主進程先是執行這條命令，緊接著fork一個子進程，用于往AOF緩存區和AOF重寫緩存區寫命令
• 滿足條件后寫入AOF文件
• 當bgwriteaof執行時，同樣會fork一個子進程從AOF重寫緩存區讀取指令并重啟，同時提示bgwriteaof正在執行
• 重寫完成后，替換原來的.aof文件

RDB與AOF的區別

RDB與AOF如何選擇

對數據敏感，建議使用默認的AOF持久化方案

• AOF持久化策略使用everysec，每秒鐘fsync一次。該策略可以很好的保持處理性能，當出現問題時最多丟失0-1秒鐘的數據。
• 注意：由于AOF存儲體積較大，所以恢復速度較慢

數據呈現階段有效性，建議使用RDB持久化方案

• 數據可以良好的做到階段內無丟失，且恢復速度較快，階段點數據恢復通常使用RDB方案
• 注意：利用RDB實現緊湊的數據持久化會使Redis性能降低

綜合對比

• RDB與AOF的選擇實際上是在做一種權衡，每種都有利弊
• 如果不能承受數分鐘以內的數據丟失，對業務非常敏感，選用AOF
• 如果能接受數分鐘以內的數據丟失，且追求大數據集的回復速度，選用RDB
• 災難恢復選RDB
• 雙保險策略，同時開啟RDB與AOF，重啟后，Redis優先使用AOF來恢復數據，降低丟失數據的量

持久化應用場景

• 應用于搶購，限購類、限量發放優惠卷、激活碼等業務的數據存儲設計
• 應用于具有操作先后順序的數據控制
• 應用于最新消息展示
• 應用于基于黑名單與白名單設定的服務控制
• 應用于計數器組合排序功能對應的排名