Redis 持久化（RDB 和AOF）（四）

1. 持久化簡介

1.1 什麼是持久化

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

1.2 爲什麼要進行持久化

防止數據的意外丟失，確保數據安全性

1.3 持久化過程保存什麼

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

2. RDB

2.1 RDB 簡介

• RDB其實就是把數據以快照的形式保存在磁盤上。什麼是快照呢，你可以理解成把當前時刻的數據拍成一張照片保存下來。
• RDB持久化是指在指定的時間間隔內將內存中的數據集快照寫入磁盤。也是默認的持久化方式，這種方式是就是將內存中數據以快照的方式寫入到二進制文件中,默認的文件名爲dump.rdb。
• 在我們安裝了redis之後，所有的配置都是在redis.conf文件中，裏面保存了RDB和AOF兩種持久化機制的各種配置。
• 既然RDB機制是通過把某個時刻的所有數據生成一個快照來保存，那麼就應該有一種觸發機制，是實現這個過程。對於RDB來說，提供了三種機制：save、bgsave、自動化。

2.2 RDB 三種觸發方式

save 觸發方式

• 命令執行

誰執行：redis 操作者（用戶）
什麼時間執行：即時（隨時執行）
幹什麼事：保存數據

• 命令

save   手動執行一次保存操作

如果是第一次執行save指令，會生成一個.rdb文件，之後再執行save，都會更新.rdb文件。
當再次啓動redis服務器和客戶端的時候，redis 會根據.rdb 文件將數據加載內存。

• save 指令相關配置

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

• save 指令工作原理

redis只支持單線程，當多個客戶端向服務器發送指令時，指令按順序執行，save指令的執行會阻塞當前Redis服務器，直到當前RDB過程完成爲止，有可能會造成長時間阻塞，線上環境不建議使用。

bgsave 觸發方式

• 後臺執行

誰執行：redis操作者（用戶）發起指令，redis服務器控制指令執行
什麼時間執行：即時（發起），redis服務器合理的時間執行
幹什麼事情：保存數據

• 命令

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

• bgsave 指令工作原理

執行該命令時，Redis會在後臺異步進行快照操作，同時還可以響應客戶端請求。 bgsave命令是針對save阻塞問題做的優化。Redis內部所有涉及到RDB操作都採用bgsave的方式，save命令可以放棄使用。

• bgsave 指令的相關配置

• dbfilename
• dir
• rdbcompression
• rdbchecksum yes
• stop-writes-on-bgsave-error yes/no
  說明：後臺存儲過程中如果出現錯誤現象，是否停止保存操作
  經驗：通常默認爲開啓狀態

自動觸發（save 配置）
自動觸發是由我們的配置文件（通過設置save屬性）來完成的，底層還是通過bgsave 來執行的。

• 自動執行

誰執行：redis服務器發起指令（基於條件）
什麼時間執行：滿足條件的時候執行
幹什麼事：保存數據

• 配置

save second changes 

• 作用
  滿足限定時間範圍內，key的變化次數達到指定數即進行持久化，然後重新計數，如果指定的時間範圍內，沒有那麼多次變化，就重新計時計數。
• 參數
  second ：監控時間範圍,單位是秒
  changes：監控key的變化量，增刪改都算一次變化，get操作不算
• 位置
  在conf中進行配置
• 範例
  save 900 1 900秒內，每改變一次，就進行持久化
  save 300 10 300秒內，如果改變10次就持久化一次

• save配置 原理
  
• 注意

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

save配置的相關配置和save指令的相關配置一樣。

2.3 RDB三種觸發方式對比

自動觸發方式底層使用的還是bgsave指令。

2.4 RDB 優缺點

• RDB 優點

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

• RDB 缺點

• RDB方式無論是執行指令還是利用配置，無法做到實時持久化，具有較大的可能性丟失數據
• 大數據量下，IO的性能較低
• bgsave指令每次運行要執行fork操作創建子進程，要犧牲掉一些性能
• Redis的衆多版本中未進行RDB文件格式的版本統一，有可能出現各版本服務之間數據格式無法兼容現象

3. AOF

3.1 AOF 概念

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

3.2 AOF 工作流程

當客戶端向服務器發送set指令，服務器接受到這條指令，並沒有馬上記錄，而是放到了一個臨時的區域（AOF 寫命令刷新緩衝區），根據AOF的觸發機制來決定什麼時候將命令寫入AOF文件中。

3.3 AOF 三種觸發機制（appendfsync）

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

優缺點

3.4 AOF 相關配置

 appendonly yes|no  是否開啓AOF持久化功能，默認爲不開啓狀態

appendfsync always|everysec|no  AOF觸發方式

 appendfilename filename  AOF持久化文件名，默認文件名未appendonly.aof建議配置爲
 						  appendonly-端口號.aof 

 dir   AOF持久化文件保存路徑，與RDB持久化文件保持一致即可 

3.5 AOF 重寫

• AOF 遇到的問題

當對同一個key,連續進行多次同樣的操作，AOF會記錄多次，而一般我們需要的是最後一次的結果，前n-1次的操作對我們來說並沒有用，記錄的話，會浪費內存。

• AOF 重寫

隨着命令不斷寫入AOF，文件會越來越大，爲了解決這個問題，Redis引入了AOF重寫機制壓縮文件體積。AOF文件重寫就是將對同一個數據的若干條命令執行結果轉化成最終結果數據對應的指令進行記錄，就是對aof文件的整理、壓縮。

• AOF 重寫作用

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

• AOF 重寫規則

• 進程內已超時的數據不再寫入文件
• 忽略無效指令，重寫時使用進程內數據直接生成，這樣新的AOF文件只保留最終數據的寫入命令 ，比如當對同一個key進行set,重寫之後，只保存最後一條set記錄，如果刪除這個key,因爲這個key已經不存在了，重寫之後，沒有key的相關記錄了。
• 對同一數據的多條寫命令合併爲一條命令 如lpush list1 a、lpush list1 b、 lpush list1 c 可以轉化爲：lpush list1 a b c。 爲防止數據量過大造成客戶端緩衝區溢出，對list、set、hash、zset等類型，每條指令最多寫入64個元素

• AOF 重寫方式（手動）

bgrewriteaof

• AOF 手動重寫原理

AOF 手動重寫原理和bgsave 的原理類似，都是服務器調用Linux的fork函數生成一個子進程執行相關操作。

• AOF 重寫方式（自動）

• 自動重寫觸發條件設置
  auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
• 自動重寫觸發比對參數（運行指令info Persistence 獲取具體信息）
  aof_current_size
aof_base_size
• 自動重寫觸發條件(滿足一個即可）
  aof_current_size > auto-aof-rewrite-min-size
  （ aof_current_size - aof_base_size ）/ aof_base_size >= auto-aof-rewrite-percentage
  也就是說，當緩衝區當前尺寸（aof_current_size）大於你設置的自動重寫最小尺寸（auto-aof-rewrite-min-size ）時就重寫，或者緩衝區當前尺寸（aof_current_size）與基礎尺寸的差再比上基礎尺寸得到的百分比當大於你自己設置的自動重寫百分比（auto-aof-rewrite-percentage）

• AOF 重寫原理

  非重寫

  重寫

3.6 AOF 優缺點

• 優點

• AOF可以更好的保護數據不丟失，一般AOF會每隔1秒，通過一個後臺線程執行一次fsync操作，最多丟失1秒鐘的數據
• AOF日誌文件沒有任何磁盤尋址的開銷，寫入性能非常高，文件不容易破損。
• AOF日誌文件即使過大的時候，出現後臺重寫操作，也不會影響客戶端的讀寫。
• AOF日誌文件的命令通過非常可讀的方式進行記錄，這個特性非常適合做災難性的誤刪除的緊急恢復。比如某人不小心用flushall命令清空了所有數據，只要這個時候後臺rewrite還沒有發生，那麼就可以立即拷貝AOF文件，將最後一條flushall命令給刪了，然後再將該AOF文件放回去，就可以通過恢復機制，自動恢復所有數據

• 缺點

• 對於同一份數據來說，AOF日誌文件通常比RDB數據快照文件更大
• AOF開啓後，支持的寫QPS會比RDB支持的寫QPS低，因爲AOF一般會配置成每秒fsync一次日誌文件，當然，每秒一次fsync，性能也還是很高的
• 以前AOF發生過bug，就是通過AOF記錄的日誌，進行數據恢復的時候，沒有恢復一模一樣的數據出來。

4. RDB 與 AOF 區別

5. RDB 與 AOF的選擇

• 對數據非常敏感，建議使用默認的AOF持久化方案
  AOF持久化策略使用everysecond，每秒鐘fsync一次。該策略redis仍可以保持很好的處理性能，當出 現問題時，最多丟失0-1秒內的數據。
  注意：由於AOF文件存儲體積較大，且恢復速度較慢
• 數據呈現階段有效性，建議使用RDB持久化方案
  數據可以良好的做到階段內無丟失（該階段是開發者或運維人員手工維護的），且恢復速度較快，階段 點數據恢復通常採用RDB方案
  注意：利用RDB實現緊湊的數據持久化會使Redis降的很低
• 綜合比對

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

6. 參考

• 112節Redis入門到精通【黑馬程序員】
• 詳解Redis中兩種持久化機制RDB和AOF（面試常問，工作常用）