---

前言

????????Redis 是一款內存數據庫，所有數據默認存儲在內存中。雖然內存操作速度極快，但一旦 Redis 服務重啟、進程崩潰或服務器斷電，內存中的數據會全部丟失。為解決這一問題，Redis 提供了持久化機制—— 將內存中的數據定期 / 實時寫入磁盤，確保數據在故障后可恢復。

Redis 支持三種核心持久化方式：RDB（Redis Database）、AOF（Append Only File）?和?混合持久化（RDB + AOF，Redis 4.0+ 引入）。下面逐一詳解其原理、配置、優缺點及適用場景。

---

一、RDB 持久化（快照持久化）

1. 定義

RDB 是 Redis 默認的持久化方式，其核心是在指定時間點生成內存中所有數據的 “快照”（二進制壓縮文件），并將快照保存到磁盤（默認文件名為?dump.rdb）。當 Redis 重啟時，可通過加載該快照文件恢復數據。

2. RDB 觸發機制

RDB 觸發分為手動觸發和自動觸發兩種方式，核心差異在于是否阻塞 Redis 主進程。

（1）手動觸發

手動觸發需通過 Redis 命令執行，主要有兩個命令：

• save?命令：
  直接由 Redis 主進程執行快照生成，期間會阻塞所有客戶端請求（主進程無法處理其他命令），直到快照完成。

  • 適用場景：僅用于測試或數據量極小的場景，生產環境嚴禁使用（會導致服務不可用）。

• bgsave?命令：
  主進程會先?fork()?一個子進程，由子進程負責生成快照文件，主進程繼續處理客戶端請求（非阻塞）。

  • 核心原理：fork()?子進程時采用?寫時復制（Copy-On-Write, COW）?機制 —— 子進程生成快照期間，主進程若修改數據，會先復制該數據的內存頁（子進程仍使用舊數據頁），確保快照數據的一致性。
  • 適用場景：生產環境推薦的手動觸發方式。

（2）自動觸發

Redis 配置文件（redis.conf）中通過?save?指令定義 “時間窗口 + 寫操作次數” 的觸發條件，滿足條件時自動執行?bgsave。

示例配置（默認配置）：

# 格式：save <seconds> <changes>
save 900 1    # 900秒內（15分鐘）至少有1次寫操作，觸發bgsave
save 300 10   # 300秒內（5分鐘）至少有10次寫操作，觸發bgsave
save 60 10000 # 60秒內至少有10000次寫操作，觸發bgsave

• 若需禁用自動 RDB，可刪除所有?save?配置，或添加?save ""。

3. RDB 持久化流程

1. 觸發?bgsave（手動或自動），主進程?fork()?子進程（此時主進程短暫阻塞，時間取決于內存大小，通常毫秒級）。
2. 子進程遍歷 Redis 內存中的數據，將其寫入臨時快照文件（如?temp-dump.rdb）。
3. 子進程寫完所有數據后，用臨時文件替換舊的?dump.rdb?文件（原子操作，避免文件損壞）。
4. 子進程退出，主進程記錄快照完成日志。

4. RDB 核心配置

配置項	說明	默認值
save <sec> <n>	自動觸發 RDB 的條件（可配置多個）	見上文示例
dbfilename	RDB 快照文件名稱	dump.rdb
dir	RDB/AOF 文件的存儲目錄（需指定絕對路徑）	./（當前目錄）
rdbcompression	是否對 RDB 文件進行 LZF 壓縮（壓縮會消耗 CPU，但減少文件大小）	yes
rdbchecksum	是否對 RDB 文件進行 CRC64 校驗（校驗會消耗 CPU，但確保文件完整性）	yes
stop-writes-on-bgsave-error	若?bgsave?失敗，是否停止 Redis 寫操作（防止數據不一致）	yes

5. RDB 優缺點

優點	缺點
1.?文件小：二進制壓縮格式，占用磁盤空間少。	1.?數據丟失風險高：兩次快照間的寫數據會丟失（如配置?save 60 10000，若 60 秒內服務崩潰，10000 次操作前的數據丟）。
2.?恢復速度快：加載二進制文件無需解析，適合大規模數據恢復。	2.?fork?開銷：bgsave?時?fork?子進程會占用與主進程相同的內存頁（COW 機制下實際僅復制修改頁，但內存峰值仍需關注）。
3.?不影響主進程：bgsave?由子進程執行，主進程可正常處理請求。	3.?不適用于實時持久化：無法做到 “每寫一次就持久化”，滿足不了高數據安全性需求。

二、AOF 持久化（日志持久化）

1. 定義

AOF（Append Only File）是基于 “寫操作日志” 的持久化方式——Redis 將每一條修改數據的命令（如?SET、HSET、LPUSH?等）以文本格式（或二進制，Redis 7.0+ 支持）追加到 AOF 文件中，而非記錄數據快照。當 Redis 重啟時，通過 “回放” AOF 文件中的所有命令，重新構建內存數據。

2. AOF 核心原理

AOF 的核心是 “追加（Append）而非修改”：

• 所有寫命令先寫入?內存緩沖區（aof_buf），再根據配置的?fsync?策略將緩沖區數據刷到磁盤（避免頻繁磁盤 I/O 影響性能）。
• AOF 文件始終以 “追加” 模式寫入，不會修改已有內容，確保日志文件不會因崩潰而損壞（即使崩潰，僅丟失最后未刷盤的命令）。

3. AOF 的?fsync?策略（關鍵配置）

fsync?是操作系統調用，用于將內存緩沖區的數據強制刷到磁盤（確保數據真正寫入硬件）。AOF 通過?appendfsync?配置控制?fsync?頻率，平衡 “數據安全性” 和 “性能”：

配置值	說明	安全性	性能
always	每執行一條寫命令，立即?fsync?刷盤。	最高	最低
everysec	每秒執行一次?fsync（默認配置），緩沖區數據累積 1 秒后刷盤。	較高	較高
no	Redis 不主動?fsync，由操作系統決定何時刷盤（通常依賴系統緩存，默認 30 秒）。	最低	最高

• 生產環境推薦?everysec：僅可能丟失 1 秒內的數據，性能接近?no，安全性滿足大部分場景。

4. AOF 重寫（解決文件膨脹問題）

（1）為什么需要重寫？

AOF 文件會不斷追加命令，若頻繁執行?INCR count?這類命令，AOF 文件中會積累大量重復命令（如?INCR count?1000 次，實際只需 1 條?SET count 1000?即可恢復數據），導致文件急劇膨脹，占用磁盤空間且恢復速度變慢。

AOF 重寫的核心是 **“壓縮命令日志”**：不讀取舊 AOF 文件，而是直接遍歷當前內存中的數據，生成 “重建該數據所需的最少命令”，并寫入新的 AOF 文件，替換舊文件。

（2）重寫觸發方式

• 手動觸發：執行?bgrewriteaof?命令，主進程?fork()?子進程負責重寫，主進程繼續處理請求（非阻塞）。
• 自動觸發：通過配置兩個參數，滿足條件時自動執行?bgrewriteaof：

  auto-aof-rewrite-percentage 100  # AOF 文件大小比上次重寫后增長100%（即翻倍）
  auto-aof-rewrite-min-size 64mb   # AOF 文件最小大小達到64MB（避免小文件頻繁重寫）
  

（3）重寫流程

1. 主進程?fork()?子進程，子進程開始遍歷內存數據，生成新 AOF 臨時文件。
2. 主進程繼續處理請求：新的寫命令一方面追加到舊 AOF 文件（確保重寫期間數據不丟失），另一方面寫入?AOF 重寫緩沖區（aof_rewrite_buf）。
3. 子進程完成重寫后，主進程將?aof_rewrite_buf?中的命令追加到新 AOF 文件。
4. 用新 AOF 文件替換舊文件，重寫完成。

5. AOF 核心配置

配置項	說明	默認值
appendonly	是否開啟 AOF 持久化（默認關閉，需手動設為?yes）	no
appendfilename	AOF 文件名稱	appendonly.aof
dir	AOF 文件存儲目錄（與 RDB 共享，需絕對路徑）	./
appendfsync	fsync?策略（always/everysec/no）	everysec
auto-aof-rewrite-percentage	自動重寫的文件大小增長率	100
auto-aof-rewrite-min-size	自動重寫的文件最小大小	64mb
aof-load-truncated	若 AOF 文件末尾有損壞（如崩潰導致），是否仍加載可用部分（默認開啟）	yes

6. AOF 優缺點

優點	缺點
1.?數據安全性高：everysec?策略僅丟 1 秒數據，always?可做到不丟數據。	1.?文件體積大：文本日志比 RDB 二進制文件大，占用更多磁盤空間。
2.?日志可讀性強：文本格式可直接查看 / 修改（如刪除誤操作的命令）。	2.?恢復速度慢：加載時需解析并執行所有命令，大規模數據恢復比 RDB 慢。
3.?無數據丟失風險：適合對數據安全性要求高的場景。	3.?fsync?開銷：always?策略會頻繁觸發磁盤 I/O，性能損耗較大。
4.?重寫機制優化：通過重寫解決文件膨脹問題。	4.?兼容性問題：舊版本 Redis 可能不支持新版本 AOF 文件的某些命令格式。

三、混合持久化（Redis 4.0+）

1. 定義與目的

單獨使用 RDB 或 AOF 都有明顯缺陷：

• RDB 恢復快但數據丟失多；
• AOF 數據全但恢復慢（尤其文件大時）。

混合持久化（RDB + AOF）是?Redis 4.0 引入的解決方案：將 AOF 文件分為兩部分：

• 開頭部分：RDB 二進制快照（記錄某一時間點的全量數據）；
• 末尾部分：增量 AOF 日志（記錄 RDB 快照之后的所有寫命令）。

重啟時，Redis 先加載 RDB 快照（快速恢復全量數據），再回放末尾的 AOF 日志（恢復增量數據），兼顧 “恢復速度” 和 “數據完整性”。

2. 混合持久化原理

• 開啟混合持久化后，執行?bgrewriteaof（手動或自動）時，子進程會先生成 RDB 二進制數據，寫入新 AOF 文件開頭；
• 然后將重寫期間的增量命令（aof_rewrite_buf）以 AOF 格式追加到新文件末尾；
• 最終新 AOF 文件同時包含 RDB 快照和 AOF 日志，替換舊 AOF 文件。

3. 核心配置

Redis 4.0+ 需手動開啟，Redis 5.0+ 默認為開啟：

aof-use-rdb-preamble yes  # yes：開啟混合持久化；no：純 AOF 模式

4. 混合持久化優勢

1. 恢復速度快：加載 RDB 快照比純 AOF 回放命令快一個數量級；
2. 數據完整性高：增量 AOF 日志確保 RDB 之后的數據不丟失；
3. 文件體積適中：RDB 壓縮 + AOF 增量，比純 AOF 文件小。

四、RDB vs AOF vs 混合持久化 對比

對比維度	RDB	AOF（純）	混合持久化（RDB+AOF）
持久化方式	二進制快照	寫命令日志（追加）	RDB 快照 + AOF 增量日志
數據完整性	低（丟失兩次快照間數據）	高（最多丟 1 秒數據）	高（同 AOF）
文件大小	小（壓縮）	大（文本 / 二進制）	中（RDB 壓縮 + AOF 增量）
恢復速度	快	慢	快（接近 RDB）
性能影響	低（bgsave?子進程）	中（fsync?策略）	中（同 AOF）
適用場景	大規模數據備份、恢復	高數據安全性需求	生產環境默認推薦

五、持久化方案選擇建議

1. 生產環境首選：混合持久化
   兼顧 RDB 的 “快速恢復” 和 AOF 的 “高數據完整性”，是 Redis 5.0+ 推薦的默認方案，適合 90% 以上的業務場景。

2. 僅用 RDB 的場景

   • 數據允許丟失幾分鐘（如非核心緩存數據）；
   • 需頻繁備份 / 恢復大規模數據（如每日全量備份）；
   • 對 Redis 性能要求極高，無法接受 AOF 的?fsync?開銷。

3. 僅用 AOF 的場景

   • 數據絕對不允許丟失（如金融交易數據），需配置?appendfsync always；
   • 需通過 AOF 日志排查歷史操作（如定位誤刪數據的命令）。

4. 禁用持久化的場景

   • Redis 僅作為純緩存（數據可從后端數據庫重建）；
   • 測試環境，無需保留數據。

六、關鍵注意事項

1. 持久化文件備份

   • 定期將?dump.rdb?和?appendonly.aof?復制到異地存儲（如云存儲、另一臺服務器），防止單磁盤故障導致文件丟失。
   • 備份時建議先執行?bgsave/bgrewriteaof，確保備份的是完整文件。

2. 避免持久化文件與 Redis 同磁盤

   • 若 Redis 數據和持久化文件存于同一磁盤，磁盤滿時會導致 Redis 無法寫入數據，建議分開存儲。

3. 定期測試恢復流程

   • 模擬故障場景（如刪除內存數據后重啟 Redis），驗證持久化文件能否正常加載，避免文件損壞或配置錯誤導致恢復失敗。

4. 內存與持久化配合

   • 若 Redis 內存過大（如 10GB+），bgsave?時?fork?子進程可能導致內存峰值過高，需配置?vm.overcommit_memory = 1（允許操作系統超分配內存），避免?fork?失敗。

總結

Redis 持久化用于內存數據落盤防丟失，核心有三種方案：

1. RDB：默認快照式，文件小、恢復快，但兩次快照間數據易丟失；
2. AOF：需手動開啟，記錄寫命令，數據安全（最多丟 1 秒），但文件大、恢復慢；
3. 混合持久化（4.0+）：結合 RDB 快恢復與 AOF 高安全，生產環境首選。

選擇：生產優先混合，數據允許丟失用 RDB，絕對不丟用 AOF；需定期備份文件、測試恢復。