Redis高階-2.Redis 持久化
阿新 • • 發佈：2021-09-19
目錄
2.Redis 持久化
2.1 持久化簡介
什麼是持久化 ?
利用永久性儲存介質將資料進行儲存，在特定的時間將儲存的資料進行恢復的工作機制稱為持久化。
為什麼要進行持久化 ?
防止資料的意外丟失，確保資料安全性
持久化過程儲存什麼 ?
將 當前資料狀態 進行儲存，快照形式，儲存資料結果，儲存格式簡單，關注點在資料
將 資料的操作過程 進行儲存，日誌形式，儲存操作過程，儲存格式複雜，關注點在資料的操作過程
2.2 RDB
RDB啟動方式
誰，什麼時間，幹什麼事情 ? 命令執行 誰：redis操作者（使用者） 什麼時間：即時（隨時進行） 幹什麼事情：儲存資料
RDB啟動方式 —— save指令
命令
save
作用
手動執行一次儲存操作
執行後會生成xxx.rdb檔案，裡面儲存資料。
RDB啟動方式 —— save指令相關配置
修改conf配置檔案：
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過程完成為止，有可能會造成長時間阻塞，線上環境不建議使用。
資料量過大，單執行緒執行方式造成效率過低如何處理？
後臺執行
誰：redis操作者（使用者）發起指令；redis伺服器控制指令執行
什麼時間：即時（發起）；合理的時間（執行）
幹什麼事情：儲存資料
RDB啟動方式 —— bgsave指令
命令
bgsave
作用
手動啟動後臺儲存操作，但不是立即執行
過程： 執行bgsave命令，會發送指令給redis，redis返回給Background saving started訊息，並沒有真正執行RDB操作。 返回訊息後會呼叫linux的fork函式生成一個子程序，不參與redis的序列命令操作，單獨用一個子程序來維護，去建立rdb檔案，返回一個訊息告訴redis執行完成。
注意： bgsave命令是針對save阻塞問題做的優化。Redis內部所有涉及到RDB操作都採用bgsave的方式，save命令可以放棄使用。
RDB啟動方式 —— bgsave指令相關配置
conf配置檔案：
dbfilename dump.rdb
dir
rdbcompression yes
rdbchecksum yes
stop-writes-on-bgsave-error yes
說明：後臺儲存過程中如果出現錯誤現象，是否停止儲存操作
經驗：通常預設為開啟狀態
反覆執行儲存指令，忘記了怎麼辦？不知道資料產生了多少變化，何時儲存？
自動執行
誰：redis伺服器發起指令（基於條件）
什麼時間：滿足條件
幹什麼事情：儲存資料
conf配置檔案中設定
配置
save second changes
作用
滿足限定時間範圍內key的變化數量達到指定數量即進行持久化(若限定時間內key數量沒有達到，則重新計時)
引數
second：監控時間範圍 （秒）
changes：監控key的變化量
位置
在conf檔案中進行配置
範例
save 900 1
save 300 10
save 60 10000
注意：
save配置要根據實際業務情況進行設定，頻度過高或過低都會出現效能問題，結果可能是災難性的
save配置中對於second與changes設定通常具有互補對應關係，儘量不要設定成包含性關係
save配置啟動後執行的是bgsave操作
save配置相關配置
dbfilename dump-埠號.rdb
dir
rdbcompression yes
rdbchecksum yes
RDB三種啟動方式對比
rdb特殊啟動形式
全量複製
伺服器執行過程中重啟
debug reload
關閉伺服器時指定儲存資料
shutdown save
預設情況下執行shutdown命令時，自動執行
bgsave(如果沒有開啟AOF持久化功能)
RDB優點
RDB是一個緊湊壓縮的二進位制檔案，儲存效率較高
RDB內部儲存的是redis在 某個時間點 的資料快照，非常適合用於資料備份，全量複製等場景
RDB恢復資料的速度要比AOF快很多
應用：伺服器中每X小時執行bgsave備份，並將RDB檔案拷貝到遠端機器中，用於災難恢復。
RDB缺點
RDB方式無論是執行指令還是利用配置，無法做到實時持久化，具有較大的可能性丟失資料
bgsave指令每次執行要執行fork操作建立子程序，要犧牲掉一些效能
Redis的眾多版本中未進行RDB檔案格式的版本統一，有可能出現各版本服務之間資料格式無法相容現象
2.3 AOF
RDB儲存的弊端
儲存資料量較大，效率較低
基於快照思想，每次讀寫都是全部資料，當資料量巨大時，效率非常低
大資料量下的IO效能較低
基於fork建立子程序，記憶體產生額外消耗
宕機帶來的資料丟失風險
解決思路
不寫全資料，僅記錄部分資料
降低區分資料是否改變的難度，改記錄資料為記錄操作過程
對所有操作均進行記錄，排除丟失資料的風險
AOF概念
AOF(append only file)持久化：以獨立日誌的方式記錄每次寫命令，重啟時再重新執行AOF檔案中命令達到恢復資料的目的。與RDB相比可以簡單描述為改記錄資料為記錄資料產生的過程
AOF的主要作用是解決了資料持久化的實時性，目前已經是Redis持久化的主流方式
AOF寫資料過程
AOF寫資料三種策略(appendfsync)
always(每次） /ˈɔːlweɪz/ 總是，永遠
每次寫入操作均同步到AOF檔案中，資料零誤差，效能較低，不建議使用。
everysec（每秒）
每秒將緩衝區中的指令同步到AOF檔案中，資料準確性較高，效能較高，建議使用，也是預設配置
在系統突然宕機的情況下丟失1秒內的資料
no（系統控制）
由作業系統控制每次同步到AOF檔案的週期，整體過程不可控
AOF功能開啟
conf配置檔案：
配置
appendonly yes|no
作用
是否開啟AOF持久化功能，預設為不開啟狀態
配置
appendfsync always|everysec|no
作用
AOF寫資料策略
AOF相關配置
配置
appendfilename filename
作用
AOF持久化檔名，預設檔名為appendonly.aof，建議配置為appendonly-埠號.aof
配置
dir
作用
AOF持久化檔案儲存路徑，與RDB持久化檔案保持一致即可
AOF寫資料遇到的問題
如果連續執行如下指令該如何處理
AOF重寫
隨著命令不斷寫入AOF，檔案會越來越大，為了解決這個問題，Redis引入了AOF重寫機制壓縮檔案體積。
AOF檔案重寫是將Redis程序內的資料轉化為寫命令同步到新AOF檔案的過程。簡單說就是將對同一個資料的若干個條命令執行結果轉化成最終結果資料對應的指令進行記錄。
AOF重寫作用
降低磁碟佔用量，提高磁碟利用率
提高持久化效率，降低持久化寫時間，提高IO效能
降低資料恢復用時，提高資料恢復效率
AOF重寫規則
程序內已超時的資料不再寫入檔案
忽略無效指令，重寫時使用程序內資料直接生成，這樣新的AOF檔案只保留最終資料的寫入命令
如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
對同一資料的多條寫命令合併為一條命令
如lpush list1 a、lpush list1 b、 lpush list1 c 可以轉化為：lpush list1 a b c。
為防止資料量過大造成客戶端緩衝區溢位，對list、set、hash、zset等型別，每條指令最多寫入64個元素
AOF重寫方式
手動重寫
bgrewriteaof -> bg re write aof 後臺重寫aof
自動重寫
在conf配置檔案中設定：
auto-aof-rewrite-min-size size 設定觸發的值
auto-aof-rewrite-percentage percentage 設定觸發的百分比值
兩個條件滿足一個就觸發重寫
AOF手動重寫 —— bgrewriteaof指令工作原理
過程:
執行bgrewriteaof命令，會發送指令給redis，redis返回給Background append only file rewriting started訊息(日誌中可以檢視)，並沒有真正執行aof操作。
返回訊息後會呼叫linux的fork函式生成一個子程序，不參與redis的序列命令操作，單獨用一個子程序來維護，去重寫aof檔案，返回一個訊息告訴redis執行完成。
AOF自動重寫方式
自動重寫觸發條件設定
auto-aof-rewrite-min-size size 設定觸發的值
auto-aof-rewrite-percentage percent 設定觸發的百分比值
兩個條件滿足一個就觸發重寫
這兩個引數不在conf配置檔案中，使用info指令可以看到redis的配置資訊：
自動重寫觸發比對引數（ 執行指令info Persistence獲取具體資訊 ）
aof_current_size 當前大小
aof_base_size 基礎大小（尺寸）
自動重寫觸發條件
當前大小大於設定的auto-aof-rewrite-min-size size 最小值就重寫
AOF重寫流程
重寫流程：
AOF緩衝區同步檔案策略，由引數appendfsync控制
系統呼叫write和fsync說明：
write操作會觸發延遲寫（delayed write）機制，Linux在核心提供頁緩衝區用
來提高硬碟IO效能。write操作在寫入系統緩衝區後直接返回。同步硬碟操作依
賴於系統排程機制，列如：緩衝區頁空間寫滿或達到特定時間週期。同步檔案之
前，如果此時系統故障宕機，緩衝區內資料將丟失。
fsync針對單個檔案操作（比如AOF檔案），做強制硬碟同步，fsync將阻塞知道
寫入硬碟完成後返回，保證了資料持久化。
除了write、fsync、Linx還提供了sync、fdatasync操作，具體API說明參見：
2.4 RDB與AOF區別
RDB VS AOF
RDB與AOF的選擇之惑
對資料非常敏感，建議使用預設的AOF持久化方案
AOF持久化策略使用everysecond，每秒鐘fsync一次。該策略redis仍可以保持很好的處理效能，當出現問題時， 最多丟失0-1秒內的資料。
注意：由於AOF檔案儲存體積較大，且恢復速度較慢
資料呈現階段有效性，建議使用RDB持久化方案
資料可以良好的做到階段內無丟失（該階段是開發者或運維人員手工維護的），且恢復速度較快，階段點資料恢復通 常採用RDB方案
注意：利用RDB實現緊湊的資料持久化會使Redis降的很低
綜合比對
RDB與AOF的選擇實際上是在做一種權衡，每種都有利有弊
如不能承受數分鐘以內的資料丟失，對業務資料非常敏感，選用AOF
如能承受數分鐘以內的資料丟失，且追求大資料集的恢復速度，選用RDB
災難恢復選用RDB
雙保險策略，同時開啟 RDB 和 AOF，重啟後，Redis優先使用 AOF 來恢復資料，降低丟失資料的量
2.5 持久化應用場景
刪除線標註不建議持久化，臨時儲存即可。