概述
Redis是基於內存的nosql數據庫,數據一般是存儲於內存中,想讓內存數據保存到磁盤中,我們需要利用Redis的持久化機制。
Redis的持久化機制用於將內存中的數據保存到磁盤,以便在重啓後恢復數據。
Redis 提供了兩種主要的持久化方式:
- RDB(Redis Database)快照
- AOF(Append Only File)日誌
在Redis4.0版本之後,引入了混合持久化(RDB + AOF)
RDB持久化方式講解
RDB 持久化機制以輕量、快速為核心優勢,適合對數據實時性要求不高但需要高效恢復的場景。在生產環境中,通常與 AOF 結合使用(混合持久化),以平衡數據安全性和性能。合理配置觸發策略、監控文件生成狀態,並做好備份管理,是確保 RDB 機制穩定運行的關鍵。
其使用場景通常為:
- 緩存場景:允許部分數據丟失(如緩存熱點數據),優先使用 RDB 提升恢復速度。
- 定期全量備份:例如每天生成一次 RDB 文件,用於歷史數據存檔或容災切換。
- 主從複製:Redis 主從集羣中,主節點通過 RDB 向從節點同步初始數據(增量同步通過 AOF 實現)。
RDB實現原理
RDB 是 Redis 在某個時間點將數據寫入一個臨時文件(快照),持久化結束後,用這個臨時文件替換之前的持久化文件,達到數據持久化的目的。
RDB觸發持久化方式
手動觸發
SAVE 命令:阻塞主線程,直到 RDB 文件生成完畢,期間無法處理客户端請求。
BGSAVE 命令: fork 出一個子進程來生成 RDB 文件,主線程繼續處理請求,不阻塞。
自動觸發
通過配置文件(redis.conf)中的 save 配置項,滿足條件時自動執行 BGSAVE。
# 基礎配置項
save 900 1 # 900秒內至少有1個鍵被修改,觸發快照
save 300 10 # 300秒內至少有10個鍵被修改,觸發快照
save 60 10000 # 60秒內至少有10000個鍵被修改,觸發快照
# RDB 文件存儲路徑(建議使用獨立磁盤,避免與系統盤混用)
dir /data/redis/rdb
# RDB 文件名(可包含日期戳,便於區分版本)
dbfilename "dump-${DATE}.rdb" # 需配合腳本動態生成,Redis 不支持變量直接替換
# 壓縮配置(生產環境建議保持默認)
rdbcompression yes
# 校驗配置(加載時校驗 RDB 文件完整性,默認開啓)
rdbchecksum yes
RDB文件管理
文件存儲位置與命名
- 存儲路徑:由配置項 dir 決定,默認值為 /var/lib/redis(可通過 config get dir 查看)。
- 文件名:由配置項 dbfilename 決定,默認值為 dump.rdb(可通過 config get dbfilename 查看)。
壓縮配置:
- RDB 文件默認使用 LZF 算法壓縮,可通過配置項 rdbcompression yes|no 開啓或關閉(默認 yes)。
- 關閉壓縮可提升生成速度,但會增加文件體積,適用於 CPU 資源緊張的場景。
- 二進制格式:RDB 文件為二進制格式,不可直接讀取,但體積小、恢復速度快。
RDB恢復方式及時機
-
當Redis宕機重啓之後會自動加載rdb文件(如果同時開啓了AOF,則優先加載AOF)。
-
如果想強制加載RDB,忽略AOF時,可在配置中設置 appendonly no,或在啓動時指定 --loadrdb 參數。
-
手動加載指定加載RDB文件
# --dbfilename:指定dump.rdb文件的路徑
redis-server --dbfilename /path/dump.rdb
RDB實戰
# 創建模擬數據
127.0.0.1:6379> set test1 1
OK
127.0.0.1:6379> set test2 2
OK
127.0.0.1:6379> set test3 3
OK
127.0.0.1:6379> keys *
1) "test1"
2) "test2"
3) "test3"
# 執行快照
127.0.0.1:6379> bgsave
Background saving started
[root@master /data00/data/redis]# ll
total 96
-rw-r--r-- 1 root root 125 May 29 19:28 dump.rdb
模擬一下將dump.rdb文件刪除,重啓之後數據還在嗎?
[root@master /data00/data/redis]# mv dump.rdb ~
# 強制停止redis
[root@master ~]# ps -ef | grep redis
root 908803 635754 0 19:38 pts/0 00:00:00 grep redis
root 1818909 1 0 May20 ? 00:19:44 redis-server 0.0.0.0:6379
[root@master ~]# pkill redis-server
啓動Redis服務
[root@master ~]# redis-server /data00/data/redis/redis.conf
[root@master ~]# ss -lntup | grep 6379
tcp LISTEN 0 511 0.0.0.0:6379 0.0.0.0:* users:(("redis-server",pid=1807376,fd=6))
檢查數據是否存在
127.0.0.1:6379> keys *
(empty array)
模擬恢復dump.rdb文件
# 將dump.rdb文件遷移到Redis數據目錄下
[root@master /data00/data/redis]# mv ~/dump.rdb /data00/data/redis
# 檢查rdb文件是否損壞
[root@master /data00/data/redis]# redis-check-rdb dump.rdb
[offset 0] Checking RDB file dump.rdb
[offset 27] AUX FIELD redis-ver = '6.2.18'
[offset 41] AUX FIELD redis-bits = '64'
[offset 53] AUX FIELD ctime = '1748518107'
[offset 68] AUX FIELD used-mem = '875088'
[offset 84] AUX FIELD aof-preamble = '0'
[offset 86] Selecting DB ID 0
[offset 125] Checksum OK
[offset 125] \o/ RDB looks OK! \o/
[info] 3 keys read
[info] 0 expires
[info] 0 already expired
# 啓動Redis並檢查數據
[root@master ~]# redis-server /data00/data/redis/redis.conf
[root@master ~]# redis-cli
127.0.0.1:6379> auth !Xinxin123
OK
127.0.0.1:6379> keys *
1) "test2"
2) "test1"
3) "test3"
AOF持久化方式講解
AOF(Append Only File)是 Redis 提供的一種實時性更強的持久化方式,通過記錄所有寫操作命令(而非數據本身)來保證數據的完整性。
核心原理
- 客户端發送寫命令(如 SET key value)。
- Redis 執行命令並將結果返回客户端。
- 將命令寫入 AOF 緩衝區(內存)。
- 根據配置策略將緩衝區內容同步到磁盤。
刷盤策略(appendfsync)
- always:每個寫命令都同步到磁盤,最多會丟失一個命令
- everysec:每秒同步一次磁盤(默認配置),最多丟失 1 秒數據
- no:由操作系統決定何時刷盤(通常為 30 秒左右,取決於內核調度),可能會丟失大量數據
AOF相關配置
# 啓用 AOF(默認關閉)
appendonly yes
# 刷盤策略(推薦 everysec,兼顧安全與性能)
appendfsync everysec
# AOF 文件名(默認 appendonly.aof)
appendfilename "appendonly.aof"
# AOF 文件存儲目錄(與 RDB 共享,由 dir 參數決定)
dir /var/lib/redis
# 開啓混合持久化(Redis 4.0+ 支持)
aof-use-rdb-preamble yes
AOF重寫機制
為什麼需要重寫?
隨着寫命令不斷追加,AOF 文件會越來越大,可能導致:
- 文件體積膨脹:佔用大量磁盤空間。
- 恢復速度變慢:重啓時需要重放更多命令。
重寫原理
通過 BGREWRITEAOF 命令觸發,Redis 會:
- fork 子進程遍歷當前內存數據。
- 生成最簡命令集(如合併多個 SET 為一個)。
- 替換原有 AOF 文件,保證原子性。
自動觸發重寫
在 redis.conf 中配置:
# 當 AOF 文件比上次重寫後增長超過 100% 時觸發
auto-aof-rewrite-percentage 100
# AOF 文件至少達到 64MB 才觸發重寫(避免頻繁重寫小文件)
auto-aof-rewrite-min-size 64mb
AOF恢復機制
Redis 自動加載 AOF 日誌
Redis 服務器啓動時會優先嚐試加載 AOF 文件來恢復數據,前提是滿足以下條件:
1、配置文件中需啓用 AOF 持久化,在 Redis 的配置文件(redis.conf)中,appendonly 參數需設置為 yes:
appendonly yes
2、存在有效的 AOF 文件,Redis 會檢查 appendfilename 參數指定的 AOF 文件名(默認是 appendonly.aof)是否存在,且文件內容未損壞
混合持久化機制講解
Redis的混合持久化機制(Hybrid Persistence)是Redis4.0版本及以上的新特性,混合持久化機制(Hybrid Persistence)是結合了 AOF(Append Only File)和 RDB(Redis Database)兩種持久化方式優點的策略,旨在提供更高效的數據恢復能力和更細粒度的數據安全性。
工作原理
混合持久化機制的核心是:
在執行 AOF 重寫(BGREWRITEAOF)時,將當前內存中的數據以 RDB 快照格式寫入 AOF 文件,後續的寫命令繼續以 AOF 格式追加到文件末尾。
具體流程如下:
- 啓用混合持久化:在 redis.conf 中配置 aof-use-rdb-preamble yes(默認關閉)。
- AOF 重寫觸發:當 AOF 文件達到一定大小或手動執行 BGREWRITEAOF 時,Redis 會:
- 生成 RDB 快照數據(二進制格式,緊湊高效)。
- 將 RDB 數據寫入新 AOF 文件的開頭。
- 繼續將後續的寫命令以文本協議格式追加到 AOF 文件末尾。
- 數據恢復:Redis 啓動時,先加載 RDB 部分(快速恢復大部分數據),再執行 AOF 追加部分的命令(恢復最新操作)。
混合持久化相關配置
appendonly yes # 啓用 AOF 持久化
aof-use-rdb-preamble yes # 啓用混合持久化(Redis 4.0+ 支持)
# 觸發AOF重寫
auto-aof-rewrite-percentage 100 # AOF 文件大小比上次重寫後增長 100% 時觸發
auto-aof-rewrite-min-size 64mb # AOF 文件最小達到 64MB 時觸發
數據恢復流程
當 Redis 服務器重啓時,加載混合 AOF 文件的流程:
- 檢查文件格式:識別 AOF 文件是否包含 RDB 前綴。
- 加載 RDB 部分:快速解析二進制 RDB 數據,重建內存狀態。
- 執行 AOF 部分:繼續執行 RDB 之後的 AOF 命令,恢復最新操作。
混合持久化 vs 純 AOF vs 純 RDB區別
| 特性 | 混合持久化 | 純 AOF | 純 RDB |
|---|---|---|---|
| 數據恢復速度 | 快(RDB 加載 + 少量 AOF 命令) | 較慢(逐行執行命令) | 最快(直接加載快照) |
| 文件體積 | 小(RDB 二進制 + 增量 AOF) | 大(純文本命令) | 中等(二進制快照) |
| 數據安全性 | 高(接近 AOF,僅丟失未同步數據) | 高(取決於 fsync 策略) | 低(可能丟失最後一次快照後的數據) |
| 寫操作開銷 | 中等(重寫時生成 RDB) | 高(頻繁 fsync) | 低(定期快照) |
| 兼容性 | Redis 4.0+ | 全版本支持 | 全版本支持 |