Redis（五）：Redis的持久化

Redis的持久化目錄導航：

• 整體介紹
• RDB（Redis DataBase）
• AOF（Append Only File）
• 總結（Which one）

整體介紹

• 官網介紹

 

RDB（Redis DataBase）

• 官網介紹

• 是什麼

  • 在指定的時間間隔內將內存中的數據集快照寫入磁盤，也就是行話講的Snapshot快照，它恢復時是將快照文件直接讀到內存裏。

  • Redis會單首創建（fork）一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。整個過程當中，主進程是不進行任何IO操做的，這就確保了極高的性能若是須要進行大規模數據的恢復，且對於數據恢復的完整性不是很是敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的數據可能丟失。

• Fork

Fork的做用是複製一個與當前進程同樣的進程。新進程的全部數據（變量、環境變量、程序計數器等）數值都和原進程一致，可是是一個全新的進程，並做爲原進程的子進程。

• Rdb 保存的是dump.rdb文件
• 配置位置
• 如何觸發RDB快照
  • 配置文件中默認的快照配置
    

• • • 冷拷貝後從新使用
      • 能夠cp dump.rdb dump_new.rdb
        
  •  命令save或者是bgsave

• • • Save：save時只管保存，其它無論，所有阻塞

    • BGSAVE：Redis會在後臺異步進行快照操做，快照同時還能夠響應客戶端請求。能夠經過lastsave命令獲取最後一次成功執行快照的時間。

• • • 執行flushall命令，也會產生dump.rdb文件，但裏面是空的，無心義
• 如何恢復
  
• 將備份文件 (dump.rdb) 移動到 redis 安裝目錄並啓動服務便可
  
• CONFIG GET dir獲取目錄
• 優點
• 適合大規模的數據恢復
  
• 對數據完整性和一致性要求不高
• 劣勢

• 在必定間隔時間作一次備份，因此若是redis意外down掉的話，就會丟失最後一次快照後的全部修改

• Fork的時候，內存中的數據被克隆了一份，大體2倍的膨脹性須要考慮
• 如何中止
• 動態全部中止RDB保存規則的方法：redis-cli config set save ""
  
• 小總結

AOF（Append Only File）

• 官網介紹

• 是什麼：

• 以日誌的形式來記錄每一個寫操做，將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而後從新加載
• 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相同
• 小總結

  

總結（Which one）

• 官網建議

• 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這條規則。若是Enalbe 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文件，載入較新的那個。新浪微博就選用了這種架構