每隔一段時間Redis會把資料持久化到硬碟進行資料的儲存。其中持久化方案包括RDB和AOF模式 ，其中RDB全稱為Redis DataBase，AOF全稱為Append Only File。Redis預設使用的是RDB方式進行資料的持久化。

RDB

從英文的全稱可以看出區別，RDB是把所有的資料進行以快照的方式進行持久化。快照檔案的生成可以使用兩個命令來完成，即save和bgsave。

127.0.0.1:6379> help save
  SAVE -
  summary: Synchronously save the dataset to disk
  since: 1.0.0
  group: server
127.0.0.1:6379> help bgsave
  BGSAVE -
  summary: Asynchronously save the dataset to disk
  since: 1.0.0
  group: server
 

從summary可以看出，save是以同步的方式把資料以快照方式寫入磁碟，而bgsave是非同步的寫入。所謂同步即redis在執行rdb備份時，期間redis不能響應外部的請求直到完成本次備份。而非同步是redis呼叫Linux的核心函式fork()生成一個子程序，並且由該子程序來完成資料的持久化，所以備份時redis仍然可以響應外部的請求。

持久化配置

配置檔案redis.conf中的save即為bgsave模式，官方配置檔案中有save三種預設的選項配置：

218 save 900 1                     #每900秒(15分鐘)有1個鍵更新就執行一次bgsave
219 save 300 10                    #每300秒(5分鐘)有10個鍵更新就執行一次bgsave
220 save 60 10000                  #每60秒(1分鐘)有10000個鍵更新就執行一次bgsave
 

三種配置不是互斥的，只要有一個滿足了條件就會觸發備份操作。同時設定多個save是為了匹配不同的場景需要。若按照上面配置save 60 10000進行，並且redis在一分鐘內持續更新了10000個鍵，但是伺服器卻在第59.99秒發生宕機，那後果可想而知:這一分鐘內更新的所有鍵將全部丟失並且無法恢復。生產環境需要根據請求的調整合適的配置。

備份檔案配置

253 dbfilename dump.rdb
263 dir ./

預設情況下備份儲存在./dump.rdb中,預設在配置檔案redis.conf所在的目錄。可以手動更改配置檔案備份的地址和檔名重啟redis，也可以在redis命令列工具中熱變更，比如將備份調整為/var/redis/redis-6379.rdb:

127.0.0.1:6379> CONFIG SET dir /var/redis
OK
127.0.0.1:6379> CONFIG SET dbfilename resid-6379.rdb
OK

完成後可以使用CONFIG REWRITE將變更合併到配置檔案中。

其它選項

241 rdbcompression yes

將備份出的rdb檔案按照LZF演算法進行壓縮，可以大大減少備份檔案的體積，此選項是預設開啟的。當然為了節省CPU時間，可以改為no,但是快照檔案的大小會大大增加。

250 rdbchecksum yes

預設情況下，一串CRC64d的檢驗和會追加到快照檔案的尾部，這個可以使得快照檔案更耐破壞。但是在儲存和載入快照檔案會損失約10%的效能。

AOF

與RDB模式不同的是，AOF僅僅儲存修改命令，類似mysql的bin-log日誌。也就是說RDB儲存的是資料快照，AOF儲存的是修改命令。預設情況下AOF是關閉的，Redis僅使用RDB方式持久化資料。

699 appendonly no

在命令列中使用 CONFIG SET appendonly yes來開啟AOF持久化模式，同樣的可以使用CONFIG REWRITE將變更合併到配置檔案中。

相應的持久化資料會預設儲存到appendonly.aof中，路徑即是dir中定義的路徑。如果變更在寫入過程中伺服器發生了宕機，變更的命令位於來不及寫入到.aof檔案,也會造成資料丟失。Redis通過fsync()系統呼叫將執行的命令寫入磁碟，這裡Redis也提供了三種模式用於控制fsync的速度。

持久化配置

728 appendfsync always
729 appendfsync everysec
730 appendfsync no

always:Redis每次操作都寫入.aof檔案中，最慢但也是最安全的選項，幾乎不存在資料的丟失

no:Redis從不執行fsync()系統呼叫，而是讓作業系統決定什麼時候將資料寫入磁碟，最快但資料存在資料丟失風險

everysecond:每秒呼叫一次fsync()，折中方案也是預設配置

日誌重寫

如果生產環境開啟了AOF模式，那麼生成的.aof檔案會變得越來越大。aof重寫的主要包括1.刪除抵消的命令 2.合併重複的命令，比如說一個Python Django專案使用Redis來作為計數器，該計數器在5分鐘發生了1000次的值更新，但是資料集中包含最終值的鍵只有一個，而在AOF中卻包含1000個條目，不需要其中的999個條目來重建當前狀態。所以這999個條目可以在重建時可以全部刪除。

Redis支援一個有趣的功能：它可以在後臺fork()出一個子程序重建AOF，而不會中斷對客戶端的服務。每當您發出BGREWRITEAOF，Redis都會編寫最短的命令序列來重建記憶體中的當前資料集。除了手動的在Redis命令列中手動執行外，還可以在配置檔案中宣告自動重建的配置。

770 auto-aof-rewrite-percentage 100
771 auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-min-size 64mb指的是資料量達到64mb就觸發執行一次重寫操作，如果redis啟動時資料量大於64mb，則會自動進行一次重寫操作。此後這條配置項將不再有效。

auto-aof-rewrite-percentage 100此第一次重寫後後當資料再次達到100%，即128mb時，會再次執行一次重寫操作，以此類推，不斷執行自動重寫。

如果auto-aof-rewrite-percentage 0,則會禁用自動重寫

auto-aof-rewrite-min-size的值不能太小，否則會頻繁重寫造成效能降低

總結

• RDB永續性按指定的時間間隔執行資料集的時間點快照
• AOF永續性會記錄伺服器接收的每個寫入操作，這些操作將在伺服器啟動時再次播放，以重建原始資料集。使用與Redis協議本身相同的格式記錄命令，並且僅採用追加方式。當日志太大時，Redis可以在後臺重寫日誌
• 如果希望，只要您的資料在伺服器執行時就一直存在，則可以完全禁用永續性。當做memcache使用
• 可以在同一例項中同時合併AOF和RDB。請注意，在這種情況下，當Redis重新啟動時，AOF檔案將用於重建原始資料集，因為它可以保證是最完整的