Redis 持久化方式：RDB（Redis Database）和 AOF（Append Only File）

Redis
本部分內容是關于博主在學習 Redis 時關于持久化部分的記錄，介紹了 RDB 和 AOF 兩種持久化方式，詳細介紹了持久化的原理、配置、使用方式、優缺點和使用場景。并對兩種持久化方式做了對比。文章最后介紹了 Redis 持久化的意義并與其他常見的緩存技術做了對比。本文來源有視頻課程記錄，有其他博主的博客，也有 AI 查詢等等。

Redis 作為一個緩存組件，是否需要持久化功能？持久化的是什么？有什么意義？讓我們根據這幾個問題去了解 Redis 的持久化。

首先，Redis 是一個服務，是服務就會出現重啟，崩潰和宕機的情況，持久化的方式可以確保數據在 Redis 服務器重啟或崩潰后能夠恢復。所以持久化的作用還是很重要的，是確保數據在服務重啟后能夠恢復的關鍵機制。

接著說第二個問題，持久化的數據是什么？在解釋這個問題的時候就要涉及到 Redis 持久化的方式了，不同的方式持久化的數據有所不同，其意義和使用場景也不同。Redis 的兩種主要持久化方式是 RDB（Redis Database） 和 AOF（Append Only File）。

一、RDB（Redis Database）

當選擇使用 Redis 服務時，會默認選用一個方式進行持久化，這個方式一定是用于中小型項目體量，并且輕量化，易使用。RDB 就是 Redis 默認的持久化方式，它通過定期保存內存數據的快照到磁盤文件中，實現數據的持久化。

RDB 通過定期生成內存數據的快照（Snapshot）并將其保存到磁盤上的二進制文件中，實現數據的持久化。RDB 文件是一個壓縮的二進制文件，默認命名為 dump.rdb，它記錄了 Redis 在某一時刻的內存數據狀態。即 RDB 文件是二進制格式，存儲的是 Redis 當前數據集的快照。

工作原理：在 Redis 配置文件 redis.conf 中，可以通過 save 指令設置快照保存的觸發條件。

手動觸發：使用 SAVE（同步阻塞操作）或 BGSAVE（通過 fork 創建子進程進行持久化，不阻塞主線程）命令。
自動觸發：通過配置 save 參數（如 save 900 1 ，表示900秒內至少有1個鍵發生變化時自動保存快照）。

使用方式：在 Redis 配置文件中設置自動保存規則。

save 900 1    # 900秒內至少有1個鍵變化時保存快照
save 300 10   # 300秒內至少有10個鍵變化時保存快照
save 60 10000 # 60秒內至少有10000個鍵變化時保存快照

當觸發條件滿足時，Redis 會自動觸發快照操作，會通過 fork 創建一個子進程，由子進程負責將當前內存中的數據寫入到一個臨時文件中。寫入完成后，臨時文件會替換之前的 RDB 文件。另外，RDB 文件以二進制格式存儲，這種格式緊湊且加載速度快。

當 Redis 服務重啟時，Redis 會加載 RDB 文件中的數據，將其恢復到內存中，從而恢復到上次快照時的狀態。由于 RDB 文件是二進制格式且經過壓縮，恢復速度較快，適合用于快速啟動。

優點：

文件小：RDB 文件體積小，適合備份和全量復制。
恢復速度快：加載 RDB 文件恢復數據的速度非常快。
對性能影響小：通過子進程進行磁盤 I/O 操作，不會阻塞主線程。

缺點：

數據丟失風險：在兩次快照之間，如果 Redis 服務器發生故障，可能會丟失部分數據。
快照操作可能阻塞：在數據量較大時，fork 子進程可能會導致短暫的阻塞。

適用場景：

數據備份：適合定期備份數據。
災難恢復：快速恢復數據。
全量復制：用于 Redis 主從復制中的數據同步。

RDB 持久化通過定期生成內存數據的快照并保存到磁盤文件中，確保 Redis 服務重啟后能夠快速恢復數據。它適用于對數據丟失容忍度較高且需要快速恢復的場景。對于對數據安全性要求更高的場景，可以結合 AOF 持久化或使用混合持久化策略。

二、AOF（Append Only File）

如果該方式不是默認的話，說明該方式會應對大型項目，體量大。AOF 持久化通過記錄每次寫操作的命令到日志文件中，實現數據的持久化。AOF 文件是一個純文本文件，記錄了所有修改 Redis 數據的命令，格式與 Redis 的命令行協議一致。

使用方式：在 Redis 配置文件中啟用 AOF 并設置同步策略。

appendonly yes 			
appendfsync everysec # 這表示啟用 AOF 持久化，并每秒同步一次。

AOF 的工作原理可以分為以下幾個步驟：

命令追加（Command Appending）：
- 每次執行寫操作時，Redis 將命令追加到內存中的緩沖區 aof_buf。
- 緩沖區的內容會根據配置的同步策略寫入到 AOF 文件中。
文件同步（File Syncing）：根據 appendfsync 的配置，Redis 提供三種同步策略。
- always：每次寫操作后立即同步到磁盤，數據最安全，但性能開銷最大。
- everysec：每秒同步一次，性能和數據安全性平衡。
- no：由操作系統決定同步時機，性能最高，但可能丟失更多數據。
文件重寫（File Rewriting）：
- AOF 文件會隨著操作的增加而變大，Redis 提供了 AOF 重寫機制來壓縮文件大小。
- 重寫過程由 BGREWRITEAOF 命令觸發，Redis 會創建一個子進程，將當前內存中的數據以最小化的方式重寫到一個新的 AOF 文件中。
- 自動重寫可以通過配置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 參數實現。
重啟加載（Loading on Restart）：
- 當 Redis 重啟時，會加載 AOF 文件中的命令并逐條執行，以恢復數據。
- 如果同時啟用了 RDB 和 AOF，Redis 會優先加載 AOF 文件。

當 Redis 服務重啟時，通過重放 AOF 文件中的命令，Redis 可以恢復到最近一次寫操作的狀態。即使在 Redis 服務崩潰時，AOF 也能保證數據的完整性，最多丟失最后一次同步前的數據，具有高數據安全性。

優點：

高數據安全性：AOF 提供了更高的數據安全性，尤其是在使用 everysec 或 always 同步策略時。
可讀性高：AOF 文件是文本格式，記錄了實際的 Redis 命令，便于閱讀和分析。
支持修復工具：如果 AOF 文件損壞，可以使用 redis-check-aof 工具進行修復。
靈活的同步策略：用戶可以根據需求選擇不同的同步策略，平衡性能和數據安全性。

缺點：

文件較大：AOF 文件記錄了所有寫操作，文件體積通常比 RDB 文件大。
恢復速度慢：恢復數據時需要逐條重放命令，速度較慢。
性能開銷：高頻磁盤寫入可能影響 Redis 的寫入性能。

適用場景

高數據安全性：適用于對數據丟失容忍度低的場景，如金融系統、訂單系統。
寫操作頻繁：適合寫操作頻繁且需要實時持久化的場景。
調試和審計：AOF 文件記錄了詳細的命令日志，便于開發和測試中的調試。

AOF 持久化通過記錄每個寫操作的命令，提供了高數據安全性和靈活性。它適用于對數據丟失敏感的場景，但可能會帶來較大的文件體積和恢復速度較慢的問題。在實際應用中，AOF 可以與 RDB 混合使用，以兼顧數據安全性和恢復速度。

三、匯總

持久化方式	優點	缺點	適用場景
RDB	文件小、恢復速度快、對性能影響小	數據丟失風險、快照操作可能阻塞	數據備份、災難恢復、全量復制
AOF	數據安全性高、文件可讀性強、支持修復	文件較大、恢復速度慢、性能開銷	數據安全性要求高、誤操作恢復

如果需要高數據安全性，建議使用 AOF；如果需要快速恢復和較小的磁盤占用，建議使用 RDB。

四、Redis 對比其他緩存技術

Redis 的持久化功能是其作為緩存系統的一個重要特性，相比其他緩存技術（如 Memcached、Guava Cache、Caffeine 等），Redis 的持久化功能在某些場景下具有顯著優勢。

Redis 的持久化功能具有以下優勢。

數據持久化：Redis 提供了兩種主要的持久化方式：RDB（快照）和 AOF（追加文件），以及混合持久化（RDB + AOF）。這些持久化方式確保了數據在 Redis 服務器重啟或崩潰后能夠恢復。相比之下，Memcached 和 Guava Cache 等緩存技術不支持持久化，數據在重啟后會丟失。
高數據安全性：AOF 持久化通過記錄每個寫操作，確保即使在 Redis 崩潰時，也能恢復到非常接近崩潰時的狀態。這種高數據安全性使得 Redis 在金融、交易系統等對數據完整性要求極高的場景中具有明顯優勢。
快速恢復：RDB 持久化通過快照文件快速恢復數據，適合需要快速啟動的場景。混合持久化（RDB + AOF）結合了兩者的優點，既保證了數據的完整性，又提高了恢復速度。
靈活的配置：Redis 允許用戶根據需求選擇不同的持久化策略。例如，AOF 的 appendfsync 參數可以設置為 always、everysec 或 no，以平衡數據安全性和性能。

Redis 的持久化功能存在一定的開銷。