【redis高級】一、持久化

1. 持久化簡介

持久化：將內存中的數據保存在硬盤中當作備份，當遇到斷電，數據崩潰等，內存中數據丟失，可以將數據從硬盤恢復到內存中。專業術語：利用永久性存儲介質(硬盤)將數據進行保存，在特定的時間將保存的數據進行恢復的工作機制稱爲持久化。

持久化原因：防止數據的意外丟失，確保數據安全性

有2類持久化：RDB：數據(快照)；AOF：過程（日誌）

保存的內容：

• 將當前數據狀態進行保存，快照形式，存儲數據結果，存儲格式簡單，關注點在數據
• 將數據的操作過程進行保存，日誌形式，存儲操作過程，存儲格式複雜，關注點在數據的操作過程
  

2. RDB：數據(快照)

RDB啓動方式——save

• 命令

save

• 作用
  手動執行一次保存操作

RDB配置相關命令

• dbfilename dump.rdb
  說明：設置本地數據庫文件名，默認值爲 dump.rdb
  經驗：通常設置爲dump-端口號.rdb
• dir
  說明：設置存儲.rdb文件的路徑
  經驗：通常設置成存儲空間較大的目錄中，目錄名稱data
• rdbcompression yes
  說明：設置存儲至本地數據庫時是否壓縮數據，默認爲 yes，採用 LZF 壓縮
  經驗：通常默認爲開啓狀態，如果設置爲no，可以節省 CPU 運行時間，但會使存儲的文件變大（巨大）
• rdbchecksum yes
  說明：設置是否進行RDB文件格式校驗，該校驗過程在寫文件和讀文件過程均進行
  經驗：通常默認爲開啓狀態，如果設置爲no，可以節約讀寫性過程約10%時間消耗，但是存儲一定的數據損壞風險

RDB啓動方式——save指令工作原理

注意：save指令的執行會阻塞當前Redis服務器，直到當前RDB過程完成爲止，有可能會造成長時間阻塞，線上環境不建議使用。

RDB啓動方式——bgsave

• 命令

bgsave

• 作用
  手動啓動後臺保存操作，但不是立即執行

RDB啓動方式 —— bgsave指令工作原理

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

bgsave的保存操作可以通過redis的日誌查看

docker logs myredis

RDB啓動方式 ——save配置

• 配置

save second changes

• 作用
  滿足限定時間範圍內key的變化數量達到指定數量即進行持久化
• 參數

second：監控時間範圍
changes：監控key的變化量

• 配置位置
  在conf文件中進行配置

RDB啓動方式 ——save配置原理

注意：

• save配置要根據實際業務情況進行設置，頻度過高或過低都會出現性能問題，結果可能是災難性的
• save配置中對於second與changes設置通常具有互補對應關係（一個大一個小），儘量不要設置成包含性關係
• save配置啓動後執行的是bgsave操作

RDB啓動方式對比

RDB優缺點

• 優點
  1）RDB是一個緊湊壓縮的二進制文件，存儲效率較高
  2）RDB內部存儲的是redis在某個時間點的數據快照，非常適合用於數據備份，全量複製等場景
  3）RDB恢復數據的速度要比AOF快很多
  4）應用：服務器中每X小時執行bgsave備份，並將RDB文件拷貝到遠程機器中，用於災難恢復
• 缺點
  1）RDB方式無論是執行指令還是利用配置，無法做到實時持久化，具有較大的可能性丟失數據
  2）bgsave指令每次運行要執行fork操作創建子進程，要犧牲掉一些性能
  3）Redis的衆多版本中未進行RDB文件格式的版本統一，有可能出現各版本服務之間數據格式無法兼容現象

3. AOF：過程（日誌）

AOF概念

• AOF(append only file)持久化：以獨立日誌的方式記錄每次寫命令，重啓時再重新執行AOF文件中命令，以達到恢復數據的目的。與RDB相比可以簡單描述爲改記錄數據爲記錄數據產生的過程
• AOF的主要作用是解決了數據持久化的實時性，目前已經是Redis持久化的主流方式

AOF寫數據過程

AOF寫數據三種策略(appendfsync)

• always
  每次寫入操作均同步到AOF文件中，數據零誤差，性能較低,不建議使用
• everysec
  每秒將緩衝區中的指令同步到AOF文件中，數據準確性較高，性能較高 ，建議使用，也是默認配置在系統突然宕機的情況下丟失1秒內的數據
• no
  由操作系統控制每次同步到AOF文件的週期，整體過程不可控

AOF功能開啓

• 配置
  作用：是否開啓AOF持久化功能，默認爲不開啓狀態

appendonly yes|no

• 配置
  作用：AOF寫數據策略

appendfsync always|everysec|no

AOF重寫

• 作用
  1)降低磁盤佔用量，提高磁盤利用率
  2)提高持久化效率，降低持久化寫時間，提高IO性能
  3)降低數據恢復用時，提高數據恢復效率
• 規則
  1)進程內已超時的數據不再寫入文件
  2)忽略無效指令，重寫時使用進程內數據直接生成，這樣新的AOF文件只保留最終數據的寫入命令
  — 如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
  3)對同一數據的多條寫命令合併爲一條命令
  — 如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自動重寫的一些配置

• 自動重寫觸發條件設置

//觸發重寫的最小大小
auto-aof-rewrite-min-size size 
//觸發重寫須達到的最小百分比
auto-aof-rewrite-percentage percent

• 自動重寫觸發比對參數（ 運行指令info Persistence獲取具體信息 ）

//當前.aof的文件大小
aof_current_size 
//基礎文件大小
aof_base_size

• 自動重寫觸發條件
  

4. RDB VS AOF

RDB與AOF的選擇

• 對數據非常敏感，建議使用默認的AOF持久化方案
  1）AOF持久化策略使用everysecond，每秒鐘fsync一次。該策略redis仍可以保持很好的處理性能，當出現問題時，最多丟失0-1秒內的數據。
  2）注意：由於AOF文件存儲體積較大，且恢復速度較慢
• 數據呈現階段有效性，建議使用RDB持久化方案
  1）數據可以良好的做到階段內無丟失（該階段是開發者或運維人員手工維護的），且恢復速度較快，階段 點數據恢復通常採用RDB方案
  2）注意：利用RDB實現緊湊的數據持久化會使Redis降的很低
• 綜合比對
  1）RDB與AOF的選擇實際上是在做一種權衡，每種都有利有弊
  2）如不能承受數分鐘以內的數據丟失，對業務數據非常敏感，選用AOF
  3）如能承受數分鐘以內的數據丟失，且追求大數據集的恢復速度，選用RDB
  4）災難恢復選用RDB
  5）雙保險策略，同時開啓 RDB 和 AOF，重啓後，Redis優先使用 AOF 來恢復數據，降低丟失數據