Redis 的 RDB 持久化，本質(zhì)是通過生成內(nèi)存數(shù)據(jù)的快照文件（.rdb）來保存數(shù)據(jù)，Redis 重啟時加載該文件即可恢復(fù)數(shù)據(jù)。

RDB 是 Redis 默認的持久化方式，支持手動觸發(fā)和自動觸發(fā)兩種模式，下面從核心機制、配置、操作步驟、恢復(fù)流程、優(yōu)缺點等方面，詳細說明如何使用 RDB 持久化。

一、RDB 持久化的核心原理

快照生成邏輯當觸發(fā) RDB 持久化時，Redis 會執(zhí)行以下步驟：

• Redis 主進程 fork 一個子進程（父子進程共享內(nèi)存數(shù)據(jù)）；
• 子進程遍歷內(nèi)存中的數(shù)據(jù)，將其寫入到一個臨時的 RDB 文件中；
• 子進程寫入完成后，用臨時文件替換舊的 RDB 文件（原子操作，保證文件完整性）；
• 子進程退出，主進程繼續(xù)處理客戶端請求。

關(guān)鍵：fork 操作會產(chǎn)生 ** 寫時復(fù)制（Copy-On-Write）** 機制 —— 父子進程共享內(nèi)存頁，只有當主進程修改數(shù)據(jù)時，才會復(fù)制對應(yīng)內(nèi)存頁，避免占用雙倍內(nèi)存。

RDB 文件特性

• 文件名默認是 dump.rdb，是二進制壓縮文件，體積小，便于傳輸和備份；
• 一個 RDB 文件包含某一時刻 Redis 的全量數(shù)據(jù)快照，恢復(fù)時直接加載到內(nèi)存，速度遠快于 AOF 持久化。

二、RDB 持久化的觸發(fā)方式

RDB 有兩種觸發(fā)方式：手動觸發(fā)（按需執(zhí)行）和自動觸發(fā)（配置規(guī)則自動執(zhí)行）。

手動觸發(fā)（常用）

手動觸發(fā)有兩個命令：SAVE 和 BGSAVE，生產(chǎn)環(huán)境優(yōu)先使用 BGSAVE。

實操示例

# 1. 手動執(zhí)行 BGSAVE（推薦）
127.0.0.1:6379> BGSAVE
Background saving started  # 提示：后臺保存已啟動

# 2. 查看 BGSAVE 執(zhí)行狀態(tài)（通過 INFO 命令）
127.0.0.1:6379> INFO persistence
# Persistence
rdb_changes_since_last_save: 0  # 上次保存后數(shù)據(jù)變化量
rdb_bgsave_in_progress: 0       # 0=未執(zhí)行，1=正在執(zhí)行
rdb_last_save_time: 1719234567  # 上次保存的時間戳
rdb_last_bgsave_status: ok      # 上次保存狀態(tài)：ok=成功，err=失敗

自動觸發(fā)（配置規(guī)則）

通過修改 redis.conf 配置文件，設(shè)置數(shù)據(jù)變化觸發(fā)條件，Redis 會在滿足條件時自動執(zhí)行 BGSAVE。

核心配置項是 save <seconds> <changes>，格式為：save 時間窗口(秒) 數(shù)據(jù)變化次數(shù)，可以配置多個條件（滿足任意一個即觸發(fā)）。

配置示例（redis.conf）

# 900秒內(nèi)至少1個鍵被修改 → 觸發(fā) BGSAVE
save 900 1
# 300秒內(nèi)至少10個鍵被修改 → 觸發(fā) BGSAVE
save 300 10
# 60秒內(nèi)至少10000個鍵被修改 → 觸發(fā) BGSAVE
save 60 10000

# 禁用自動觸發(fā) RDB（注釋所有 save 配置，或添加下面一行）
# save ""

其他自動觸發(fā)場景

• 執(zhí)行 FLUSHALL 命令：會清空所有數(shù)據(jù)，并生成一個空的 dump.rdb 文件（生產(chǎn)環(huán)境慎用）。
• 主從復(fù)制時：主節(jié)點首次向從節(jié)點同步數(shù)據(jù)時，會自動執(zhí)行 BGSAVE 生成 RDB 文件，發(fā)送給從節(jié)點。

三、RDB 持久化的核心配置（redis.conf）

除了 save 觸發(fā)條件，redis.conf 中還有多個參數(shù)控制 RDB 的行為，關(guān)鍵配置如下：

配置生效步驟

修改 redis.conf 后，重啟 Redis 生效：

redis-server /etc/redis/redis.conf

驗證配置：

127.0.0.1:6379> CONFIG GET dbfilename
1) "dbfilename"
2) "redis_6379.rdb"

127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/var/lib/redis"

四、RDB 持久化的數(shù)據(jù)恢復(fù)流程

Redis 重啟時會自動加載 RDB 文件恢復(fù)數(shù)據(jù)，無需手動操作，恢復(fù)流程如下：

• Redis 啟動時，檢查 dir 配置的目錄下是否存在 dbfilename 指定的 RDB 文件；
• 如果存在，加載 RDB 文件到內(nèi)存；如果不存在，啟動后數(shù)據(jù)為空；
• 加載完成后，Redis 開始接受客戶端請求。

注意：如果 Redis 同時開啟了 AOF 持久化，則會優(yōu)先加載 AOF 文件（因為 AOF 數(shù)據(jù)的實時性更高）。

驗證數(shù)據(jù)恢復(fù)

手動執(zhí)行 BGSAVE 生成 RDB 文件：

127.0.0.1:6379> SET name tom  # 寫入測試數(shù)據(jù)
OK
127.0.0.1:6379> BGSAVE
Background saving started

停止 Redis：

redis-cli shutdown

重啟 Redis，查看數(shù)據(jù)是否恢復(fù)：

redis-cli
127.0.0.1:6379> GET name
"tom"  # 數(shù)據(jù)成功恢復(fù)

五、RDB 持久化的優(yōu)缺點

優(yōu)點

1. 恢復(fù)速度快：RDB 是全量快照文件，Redis 重啟時直接加載到內(nèi)存，比 AOF 逐行重放命令快得多。
2. 文件體積小：二進制壓縮格式，便于備份、歸檔和傳輸（適合用于定時備份）。
3. 對主進程影響小：BGSAVE 由子進程執(zhí)行，主進程可以正常處理請求。

缺點

1. 數(shù)據(jù)安全性低：RDB 是周期性快照，兩次快照之間的數(shù)據(jù)會丟失（比如設(shè)置 save 900 1，如果 Redis 崩潰，最多會丟失 15 分鐘的數(shù)據(jù)）。
2. 大內(nèi)存實例開銷大：fork 子進程時，會復(fù)制主進程的內(nèi)存頁表，大內(nèi)存實例（如 10GB 以上）fork 耗時較長，期間 Redis 可能出現(xiàn)短暫卡頓。
3. 無法實時持久化：不適合對數(shù)據(jù)實時性要求高的場景（如金融交易）。

六、RDB 持久化的最佳實踐（生產(chǎn)環(huán)境）

1. 配合 AOF 使用：開啟 RDB+AOF 混合持久化（Redis 4.0+ 支持），兼顧 RDB 的恢復(fù)速度和 AOF 的數(shù)據(jù)安全性。
2. 合理配置 save 參數(shù)：避免過于頻繁觸發(fā) BGSAVE（如不要設(shè)置 save 10 1），防止 fork 操作頻繁消耗資源；也不要設(shè)置太寬松（如 save 3600 1），避免數(shù)據(jù)丟失過多。
3. 定期手動備份 RDB 文件：通過 BGSAVE 生成 RDB 文件后，復(fù)制到其他服務(wù)器或云存儲（如 S3），作為災(zāi)難恢復(fù)的備份。
4. 控制 Redis 內(nèi)存大小：避免 Redis 內(nèi)存過大（如超過 10GB），減少 fork 時的內(nèi)存開銷和卡頓時間。
5. 監(jiān)控 fork 耗時：通過 INFO stats 查看 latest_fork_usec（上次 fork 耗時，單位微秒），如果耗時過長（如超過 1 秒），需要優(yōu)化內(nèi)存或調(diào)整持久化策略。

總結(jié)

RDB 持久化是 Redis 的基礎(chǔ)持久化方式，核心是通過快照文件保存全量數(shù)據(jù)，使用時需注意：

• 手動觸發(fā)用 BGSAVE，避免 SAVE 阻塞主進程；
• 自動觸發(fā)通過 redis.conf 的 save 參數(shù)配置，平衡性能和數(shù)據(jù)安全性；
• 恢復(fù)時 Redis 自動加載 RDB 文件，AOF 開啟時優(yōu)先加載 AOF；
• 生產(chǎn)環(huán)境建議 RDB+AOF 混合持久化，兼顧速度和安全性。

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論