Redis-持久化策略
為什麼要使用redis持久化
Redis 是一個記憶體資料庫，所有的資料都直接儲存在記憶體中，那麼，一旦 Redis 程序異常退出，或伺服器本身異常宕機，我們儲存在 Redis 中的資料就憑空消失，再也找不到了。
Redis 作為一個優秀的資料中介軟體，必定是擁有自己的持久化資料備份機制的，redis 中主要有兩種持久化策略，用於將儲存在記憶體中的資料備份到磁碟上，並且在伺服器重啟時進行備份檔案過載。
怎麼做持久化
Redis RDB - 快照
RDB 按指定時間間隔執行資料集的時間點快照，類似於MySQL Dump。
Redis AOF - 命令日誌
AOF 會記錄伺服器接收的每個寫操作，這些操作將在伺服器啟動時再次執行，以重建原始資料集。使用與Redis協議本身相同的格式記錄命令，並且僅採用append-only方式。當日志太大時，Redis可以在後臺重寫日誌。類似於MySQL Binlog、Hbase HLog。在Redis重啟時，通過回放日誌中的寫入指令來重構整個資料。
對比
一、RDB（Redis DataBase）
- 原理
生成dump.rdb檔案
- 觸發機制
(1) save(同步)
(2)bgsave(非同步)
(3)自動(符合配置檔案中 save滿足條件)
- save與bgsave
| 命令 | save | bgsave |
|---|---|---|
| IO型別 | 同步 | 非同步 |
| 阻塞 | 是 | 否(阻塞僅僅會發生在fork出子程序) |
| 複雜度 | O(n) | O(n) |
| 優點 | 不消耗額外記憶體 | 不阻塞客戶端命令 |
- 自動
save <seconds> <changes> save 900 1 save 300 10 save 60 10000 //以上表示seconds做了changes操作時，生成一次快照檔案
- 相關配置
# 每多少秒 資料改變幾次 # 滿足下面任一條件進行RDB檔案生成 #如果線上環境資料量很大時，可以關閉RDB持久化方式 只需要註釋下面三個save即可 save 900 1 save 300 10 save 60 10000 #bgsave生成RDB檔案出錯時是否停止 stop-writes-on-bgsave-error yes #RDB檔案是否採用壓縮 rdbcompression yes #是否對rdb檔案校驗和校驗 #redis 5之後採用CRC64校驗方式 rdbchecksum yes # rdb檔名字 # 目錄位置 採用 dir設定 dbfilename dump-6379.rdb #指定目錄路徑非檔名 # rdb檔案aof檔案均採用此目錄 dir ./
- 其他觸發情況
從節點執行全量複製操作的時候，主節點會自動觸發bgsave命令生存rdb檔案併發送給從節點
(2)debug reload
Redis中的debug reload提供debug級別的重啟，不清空記憶體的一種重啟，這種方式也會觸發RDB檔案的生成。 (3)shutdown
- 缺點
① 耗時、耗效能
複雜度為o(n)，save時記憶體資料dump到磁碟：耗時
bgsave時，fork()階段採用copy-on-write策略，會比較耗記憶體
dump到檔案造成io開銷
②不可控，丟失資料
- 優點
- 儲存的檔案是緊湊的
- 適合用於備份，方便恢復不同版本的資料
- 適合於容災恢復，備份檔案可以在其他伺服器恢復
- 最大化了Redis的效能，備份的時候啟動的是子執行緒，父程序不需要執行IO操作
- 資料儲存比AOF要快
二、AOF（Append Only File）
- 三種策略
① always
只要緩衝區有資料 立馬寫入檔案中
②everysec
每隔一秒將資料從緩衝區寫入檔案中
③no
寫檔案的操作交由作業系統控制
- 相關配置
#是否啟用AOF持久化方式 appendonly no #AOF檔名 #目錄受Dir控制 appendfilename "appendonly-6379.aof" #AOF持久化策略 #預設值 everysec # 有三種 no everysec always #no 寫檔案的操作交由作業系統控制 #always 只要緩衝區有資料 立馬寫入檔案中 #everysec 每隔一秒將資料從緩衝區寫入檔案中 appendfsync everysec #aof重寫期間主程序是否繼續講日誌從緩衝區重新整理到舊日誌檔案(上圖aof_buf-<舊aof檔案) no-appendfsync-on-rewrite no #以下兩個配置同時滿足即可觸發AOF重寫 #檔案增長率 auto-aof-rewrite-percentage 100 #aof重寫需要的檔案 auto-aof-rewrite-min-size 64mb
- 優點
- 使用AOF模式更加的靈活，因為可以有不同的
fsync策略 - AOF是一個日誌追加檔案，所有不需要定位，就算斷電也沒有損壞問題，哪怕檔案末尾是一個寫到一半的命令，redus-check-aof工具也可以很輕易的修復
- 當AOF檔案很大的，Redis會自動在後臺進行重寫。重寫是決對安全的，因為Redis是繼續往舊的檔案裡面追加，使用建立當前資料集所需的最小操作集合來建立一個全新的檔案，一旦建立完成，Redis就會切換到新檔案，開始往新檔案進行追加操作
- AOF包含一個又一個的操作命令，易於理解和解析
- 缺點
- 對於同樣的資料集，AOF檔案通常要大於RDB檔案
- AOF可能比RDB要慢，這取決於
fsync策略。通常fsync設定為每秒一次的話效能仍然很高，如果關閉sfync，即使在很高的負載下也和RDB一樣快。不過，即使在很大的寫負載情況下，RDB還是能提供很好的最大延遲保證 - AOF1通過遞增的方式更新資料，而RDB快照是從頭開始建立，RDB會更健壯和穩定（所以適用於備份）
三、使用
不要僅使用RDB，因為那樣會導致你丟失很多資料
不要僅使用AOF，因為那樣有兩個問題，你通過AOF做冷備，沒有RDB做冷備恢復速度更快；RDB每次簡單粗暴生成資料快照，更加健壯，可以避免AOF這種複雜的備份和恢復機制的bug
綜合使用AOF和RDB用AOF保證資料不丟失，作為資料恢復的第一選擇用RDB做不同程度的冷備，在AOF檔案都丟失或損壞不可用時，還可使用RDB快速實現資料恢復