redis 5.0.2 原始碼閱讀——跳躍表skiplist
阿新 • • 發佈：2021-07-06
什麼是持久化
利用永久性儲存介質將資料進行儲存，在特定的時間將儲存的資料進行恢復的工作機制稱為持久化。
為什麼要進行持久化
防止資料的意外丟失，確保資料安全性
持久化過程儲存什麼
- 將當前資料狀態進行儲存，快照形式，儲存資料結果，儲存格式簡單，關注點在資料（RDB）
- 將資料的操作過程進行儲存，日誌形式，儲存操作過程，儲存格式複雜，關注點在資料的操作過程(AOF)
配置檔案例項：
RDB
一、RDB啟動方式
1、save 指令
命令：save
作用：手動執行一次儲存操作
2、save 指令相關配置
- dbfilename dump.rdb
說明：設定本地資料庫檔名，預設值為 dump.rdb
經驗：通常設定為 dump-埠號.rdb - dir
說明：設定儲存 .rdb 檔案的路徑
經驗：通常設定為dump-埠號.rdb - rdbcompression yes
說明：設定儲存至本地資料庫時是否壓縮資料，預設為 yes，採用 LZF 壓縮
經驗：通常預設為開啟狀態，如果設定為 no，可以節省 CPU 執行時間，但會使儲存的檔案變大（巨大） - rdbchecksum yes
說明：設定是否進行RDB檔案格式校驗，該校驗過程在寫檔案和讀檔案過程均進行
經驗：通常預設為開啟狀態，如果設定為 no，可以節約讀寫性過程約10%時間消耗，但是儲存一定的資料損壞風險
注意：save指令的執行會阻塞當前Redis伺服器，直到當前RDB過程完成為止，有可能會造成長時間阻塞，線上環境不建議使用。
3、bgsave指令
命令：bgsave
作用：手動啟動後臺儲存操作，但不是立即執行
bgsave 指令工作原理如下圖：
注意：bgsave命令是針對save阻塞問題做的優化。Redis內部所有涉及到RDB操作都採用bgsave的方式，save命令可以放棄使用。
4、bgsave 指令相關配置
- stop-writes-on-bgsave-error yes
說明：後臺儲存過程中如果出現錯誤現象，是否停止儲存操作
經驗：通常預設為開啟狀態
5、save 自動儲存配置（執行的是 bgsave 操作）
- 配置
save second changes - 作用
滿足限定時間範圍內key的變化數量達到指定數量即進行持久化 - 引數
second：監控時間範圍
changes：監控key的變化量 - 位置
在conf檔案中進行配置 - 範例
save 900 1
save 300 10
save 60 10000
注意：
1、save配置要根據實際業務情況進行設定，頻度過高或過低都會出現效能問題，結果可能是災難性的
2、save配置中對於second與changes設定通常具有互補對應關係，儘量不要設定成包含性關係
3、save配置啟動後執行的是bgsave操作
4、RDB三種啟動方式對比
| 方式 | save指令 | bgsave指令 |
|---|---|---|
| 讀寫 | 同步 | 非同步 |
| 阻塞客戶端指令 | 是 | 否 |
| 額外記憶體消耗 | 否 | 是 |
| 啟動新程序 | 否 | 是 |
二、RDB特殊啟動形式
- 全量複製
在主從複製中詳細講解 - 伺服器執行過程中重啟
debug reload - 關閉伺服器時指定儲存資料
shutdown save
預設情況下執行shutdown命令時，自動執行
bgsave(如果沒有開啟AOF持久化功能)
三、RDB優缺點
優點：
- RDB是一個緊湊壓縮的二進位制檔案，儲存效率較高
- RDB內部儲存的是redis在某個時間點的資料快照，非常適合用於資料備份，全量複製等場景
- RDB恢復資料的速度要比AOF快很多
- 應用：伺服器中每X小時執行bgsave備份，並將RDB檔案拷貝到遠端機器中，用於災難恢復。
缺點：
- RDB方式無論是執行指令還是利用配置，無法做到實時持久化，具有較大的可能性丟失資料
- bgsave指令每次執行要執行fork操作建立子程序，要犧牲掉一些效能
- Redis的眾多版本中未進行RDB檔案格式的版本統一，有可能出現各版本服務之間資料格式無法相容現象
AOF
- AOF(append only file)持久化：以獨立日誌的方式記錄每次寫命令，重啟時再重新執行 AOF檔案中命令達到恢復資料的目的。與RDB相比可以簡單描述為改記錄資料為記錄資料產 生的過程
- AOF的主要作用是解決了資料持久化的實時性，目前已經是Redis持久化的主流方式
AOF寫資料三種策略(appendfsync)
- always(每次）
每次寫入操作均同步到AOF檔案中，資料零誤差，效能較低 - everysec（每秒）
每秒將緩衝區中的指令同步到AOF檔案中，資料 準確性較高，效能較高
在系統突然宕機的情況下丟失1秒內的資料 - no（系統控制）
由作業系統控制每次同步到AOF檔案的週期，整體過程 不可控
AOF功能開啟
- 配置：
appendonly yes|no - 作用：是否開啟AOF持久化功能，預設為不開啟狀態
- 配置：
appendfsync always|everysec|no - 作用：AOF寫資料策略
AOF相關配置
- 配置：
appendfilename filename - 作用：AOF持久化檔名，預設檔名未appendonly.aof，建議配置為appendonly-埠 號.aof
- 配置：
dir - 作用：AOF持久化檔案儲存路徑，與RDB持久化檔案保持一致即可
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 - 自動重寫:
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
AOF自動重寫方式
AOF工作流程
AOF重寫流程
1、
2、
AOF緩衝區同步檔案策略，由引數appendfsync控制
系統呼叫write和fsync說明：
- write操作會觸發延遲寫（delayed write）機制，Linux在核心提供頁緩衝區用來提高硬碟IO效能。write操作在寫入系統緩衝區後直接返回。同步硬碟操作依賴於系統排程機制，列如：緩衝區頁空間寫滿或達到特定時間週期。同步檔案之前，如果此時系統故障宕機，緩衝區內資料將丟失。
- fsync針對單個檔案操作（比如AOF檔案），做強制硬碟同步，fsync將阻塞知道寫入硬碟完成後返回，保證了資料持久化。
RDB與AOF區別
| 持久化方式 | RDB | AOF |
|---|---|---|
| 佔用儲存空間 | 小（資料級：壓縮） | 大（指令級：重寫） |
| 儲存速度 | 慢 | 快 |
| 恢復速度 | 快 | 慢 |
| 資料安全性 | 會丟失資料 | 依據策略決定 |
| 資源消耗 | 高/重量級 | 低/輕量級 |
| 啟動優先順序 | 低 | 高 |
RDB與AOF的選擇之惑
- 對資料非常敏感，建議使用預設的AOF持久化方案
- AOF持久化策略使用everysecond，每秒鐘fsync一次。該策略redis仍可以保持很好的處理效能，當出現問題時，最多丟失0-1秒內的資料。
- 注意：由於AOF檔案儲存體積較大，且恢復速度較慢
- 資料呈現階段有效性，建議使用RDB持久化方案
- 資料可以良好的做到階段內無丟失（該階段是開發者或運維人員手工維護的），且恢復速度較快，階段點資料恢復通常採用RDB方案
- 注意：利用RDB實現緊湊的資料持久化會使Redis降的很低，慎重總結。
- 綜合比對
- RDB與AOF的選擇實際上是在做一種權衡，每種都有利有弊
- 如不能承受數分鐘以內的資料丟失，對業務資料非常敏感，選用AOF
- 如能承受數分鐘以內的資料丟失，且追求大資料集的恢復速度，選用RDB
- 災難恢復選用RDB
- 雙保險策略，同時開啟 RDB 和 AOF，重啟後，Redis優先使用 AOF 來恢復資料，降低丟失資料的量