Redis持久化方案(RDB/AOF)

RDB持久化方案

• rdb持久化配置

  # 時間策略，表示900s內若是有1條是寫入命令，就觸發產生一次快照，能夠理解爲就進行一次備份
  save 900 1
  save 300 10  # 表示300s內有10條寫入，就產生快照
  save 60 10000
  # redis servercron 相似於linux的crontab，默認每隔100毫秒執行一次
  
  # 文件名稱
  dbfilename dump.rdb
  
  # 若是持久化出錯，主進程是否中止寫入
  stop-writes-on-bgsave-error yes
  
  # 是否壓縮
  rdbcompression yes
  
  # 導入時是否檢查
  rdbchecksum yes
  
  # 文件保存路徑
  dir /usr/local/redis-4.0.6

• save的含義

  ​ 實際生產環境每一個時段的讀寫請求確定不是均衡的，爲此redis提供一種根據key單位時間操做次數來觸發一次備份到磁盤，咱們能夠自由定製什麼狀況下觸發備份，此功能起到平衡性能與數據安全的做用

• 在Redis中RDB持久化的觸發分爲兩種：本身手動觸發與Redis定時觸發

  • 針對RDB方式的持久化，手動觸發可使用：
    • save：會阻塞當前Redis服務器，直到持久化完成，線上應該禁止使用。
    • bgsave：該觸發方式會fork一個子進程，由子進程負責持久化過程，所以阻塞只會發生在fork子進程的時候

• 而自動觸發的場景主要是有如下幾點

  • 根據咱們的 save m n 配置規則自動觸發
  • 從節點全量複製時，主節點發送rdb文件給從節點完成複製操做，主節點會觸發 bgsave
  • 執行 debug reload 時
  • 執行 shutdown時，若是沒有開啓aof，也會觸發

• 禁用RDB

  • 只須要在save的最後一行寫上：save ""

AOF持久化方案

• AOF持久化配置

  # 是否開啓aof
  appendonly yes
  
  # 文件名稱
  appendfilename "appendonly.aof"
  
  # 同步方式
  appendfsync everysec
  
  # aof重寫期間是否同步
  no-appendfsync-on-rewrite no
  
  # 重寫觸發配置
  auto-aof-rewrite-percentage 100
  auto-aof-rewrite-min-size 64mb
  
  # 加載aof時若是有錯如何處理
  aof-load-truncated yes # yes表示若是aof尾部文件出問題，寫log記錄並繼續執行。no表示提示寫入等待修復後寫入
  
  # 文件重寫策略
  aof-rewrite-incremental-fsync yes

• appendfsync 同步模式有三種模式，通常狀況下都採用 everysec 配置，在數據和安全裏面作平衡性選擇，最多損失1s的數據

  • always：把每一個寫命令都當即同步到aof，很慢，可是很安全

  • everysec：每秒同步一次，是折中方案

  • no：redis不處理交給OS來處理，很是快，可是也最不安全

• AOF的整個流程大致來看能夠分爲兩步，一步是命令的實時寫入（若是是 appendfsync everysec 配置，會有1s損耗），第二步是對aof文件的重寫。

  • 步驟：

    • 命令寫入=》追加到aof_buf =》經過時間事件調用flushAppendOnlyFile函數同步到aof磁盤

  • 緣由：

    • 實時寫入磁盤會帶來很是高的磁盤IO，影響總體性能

• AOF持久化的效率和安全性分析

  always：每一個時間事件循環都將AOF_BUF緩衝區的全部內容寫入到AOF文件，而且同步AOF文件，這是最安全的方式，但磁盤操做和阻塞延遲，是IO開支較大。
  everysec：每秒同步一次，性能和安全都比較中庸的方式，也是redis推薦的方式。若是遇到物理服務器故障，有可能致使最近一秒內aof記錄丟失(可能爲部分丟失)。
  no：redis並不直接調用文件同步，而是交給操做系統來處理，操做系統能夠根據buffer填充狀況/通道空閒時間等擇機觸發同步；這是一種普通的文件操做方式。性能較好，在物理服務器故障時，數據丟失量會因OS配置有關。處於no模式下的flushAppendOnlyFile調用無須執行同步操做

Redis兩種持久化方案對比

• Redis提供了不一樣的持久性選項：

  • RDB持久性以指定的時間間隔執行數據集的時間點快照。
  • AOF持久性記錄服務器接收的每一個寫入操做，將在服務器啓動時再次播放，重建原始數據集。使用與Redis協議自己相同的格式以僅追加方式記錄命令。當Redis太大時，Redis可以重寫日誌背景。

• RDB的優缺點

  • 優勢：
    • RDB最大限度地提升了Redis的性能，父進程不須要參與磁盤I/O
    • 與AOF相比，RDB容許使用大數據集更快地重啓
  • 缺點：
    • 若是您須要在Redis中止工做時（例如斷電後）將數據丟失的可能性降至最低，則RDB並很差
    • RDB常常須要fork（）才能使用子進程持久存儲在磁盤上。若是數據集很大，Fork（）可能會很是耗時

• AOF的優缺點

  • 優勢：

    • 數據更加安全
    • 當Redis AOF文件太大時，Redis可以在後臺自動重寫AOF ## INCRE 1 執行10萬 = INCREBY10萬執行一次
    • AOF以易於理解和解析的格式一個接一個地包含全部操做的日誌 # flushdb相似於rm -rf /*

  • 缺點：

    • AOF文件一般比同一數據集的等效RDB文件大

    • 根據確切的fsync策略，AOF可能比RDB慢

• RDB 和 AOF ,我應該用哪個？
  通常來講,若是想達到足以媲美 PostgreSQL 的數據安全性， 你應該同時使用兩種持久化功能。若是你很是關心你的數據,但仍然能夠承受數分鐘之內的數據丟失， 那麼你能夠只使用 RDB 持久化。有不少用戶都只使用 AOF 持久化， 但咱們並不推薦這種方式： 由於定時生成 RDB 快照（snapshot）很是便於進行數據庫備份， 而且 RDB 恢復數據集的速度也要比 AOF 恢復的速度要快

• 在線上咱們到底該怎麼作？

  • RDB持久化與AOF持久化同步使用

  • 若是Redis中的數據並非特別敏感或者能夠經過其它方式重寫生成數據，能夠關閉持久化，若是丟失數據能夠經過其它途徑補回；

  • 本身制定策略按期檢查Redis的狀況，而後能夠手動觸發備份、重寫數據；

  • 採用集羣和主從同步