Redis持久化《Redis開發與運維讀書筆記》
阿新 • • 發佈：2018-12-12
Redis支援RDB和AOF兩種持久化機制
RDB (Redis Dump Binary )
RDB永續性以指定的時間間隔執行資料集的時間點 快照
觸發機制
- 手動觸發
| 命令 | 說明 |
|---|---|
| save | 阻塞Redis直到RDB過程完成 |
| bgsave | Redis程序執行fork建立子程序來執行RDB。阻塞只發生在fork階段。Redis內部所有涉及RDB的操作都是採用bgsave |
- 自動觸發
- 使用
save m n表示m秒內集存n次修改時自動觸發bgsave - 從節點執行全量複製操作，主節點自動執行
bgsave生成RDB檔案傳送給從節點。 - 執行
debug reload命令重新載入Redis時會自動觸發save操作 - 預設情況下執行
shutdown命令時，如果沒有開啟AOF持久化功能則自動執行bgsave
RDB檔案處理
- 儲存：RDB檔案儲存在
dir配置的指定目錄下 - 壓縮：Redis預設採用LZF演算法對RDB檔案做壓縮處理，線上建議開啟
- 校驗：如果Redis載入損壞的RDB檔案時拒絕啟動
RDB優缺點
- 優點
- RDB是一個緊湊壓縮的二進位制檔案，代表redis在某個時間節點上的資料快照。非常適合備份、全量複製等功能。
- Redis載入RDB恢復資料的速度遠遠告訴AOF
- 缺點
- 無法實時/秒級持久化。因為
bgsave操作需要fork新的程序屬於重量級操作，頻繁操作成本高。 - RDB檔案使用特定的二進位制格式儲存，可能存在老版本Redis無法相容新版RDB檔案的問題。
AOF (Append-Only File)
以獨立日誌的方式記錄每次寫命令，重啟時再重新執行AOF檔案中的命令達到回覆資料的目的。 AOF主要解決資料持久化的實時性問題。
執行流程
1）所有寫入命令回追加到aof_buf緩衝區中 2）AOF緩衝區根據對應的策略向硬碟做同步操作 3）隨著AOF檔案越來越大需要定期對AOF檔案重寫達到壓縮的目的 4） 當Redis重啟時載入AOF檔案進行資料恢復
命令寫入
AOF命令寫入的內容直接是文字協議格式，即Reids協議的文字。
檔案同步
檔案同步策略
| 可配置值 | 說明 |
|---|---|
| always | 命令寫入aof_buf後呼叫系統的fsync同步AOF檔案，並在完成後返回。會嚴重影響效能 |
| everysec | 命令寫入aof_buf後呼叫系統的write命令後返回。fsync操作由專門的執行緒每秒鐘執行一次。（預設配置：效能高，並且最多對視1秒鐘的資料） |
| no | 同步硬碟的操作由系統負責，通常同步週期為30秒 |
重寫機制
重寫會壓縮AOF檔案體積：
1）已超時的資料不再寫入檔案
2）多條命令合併：例如 lpush list a, lpush list b, lpush list c 合併為 lpush list a b c
3）就得AOF無效命令會在AOF檔案種植保留最終的寫入命令。例如：set a 111, set a 222 只保留 set a 222
觸發機制：
- 手動觸發：直接呼叫
bgrewriteaof命令 - 自動觸發：通過
auto-aof-rewrite-min-size和auto-aof-rewrite-percentage配置重寫自動重寫的時機。
重新載入
檔案校驗
載入損壞的AOF檔案會拒絕啟動。
AOF檔案可能存在結尾不完整的情況，例如突然掉電了導致AOF檔案不全。可以使用aof-load-truncated配置來相容這種清空（預設是開啟的）。
常見持久化問題
Redis持久化一直是影像Redis效能的高發地。 1）持久化阻塞主執行緒場景有:
- fork阻塞: 阻塞時間跟記憶體量和系統有關
- AOF追加阻塞：跟硬碟資源緊張有關
2）Redis單程序架構導致無法充分利用CPU多核特性。可以單機部署多例項。為了避免出現多個子程序進行重寫操作建議做隔離控制，避免CPU和IO資源競爭。