---

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

---

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

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

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

一、RDB（Redis Database）

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

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

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

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

使用方式：在 Redis 配置文件中設(shè)置自動保存規(guī)則。

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

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

當 Redis 服務(wù)重啟時，Redis 會加載 RDB 文件中的數(shù)據(jù)，將其恢復(fù)到內(nèi)存中，從而恢復(fù)到上次快照時的狀態(tài)。由于 RDB 文件是二進制格式且經(jīng)過壓縮，恢復(fù)速度較快，適合用于快速啟動。

優(yōu)點：

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

缺點：

• 數(shù)據(jù)丟失風(fēng)險：在兩次快照之間，如果 Redis 服務(wù)器發(fā)生故障，可能會丟失部分數(shù)據(jù)。
• 快照操作可能阻塞：在數(shù)據(jù)量較大時，fork 子進程可能會導(dǎo)致短暫的阻塞。

適用場景：

• 數(shù)據(jù)備份：適合定期備份數(shù)據(jù)。
• 災(zāi)難恢復(fù)：快速恢復(fù)數(shù)據(jù)。
• 全量復(fù)制：用于 Redis 主從復(fù)制中的數(shù)據(jù)同步。

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

二、AOF（Append Only File）

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

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

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

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

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

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

優(yōu)點：

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

缺點：

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

適用場景

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

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

三、匯總

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

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

四、Redis 對比其他緩存技術(shù)

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

Redis 的持久化功能具有以下優(yōu)勢。

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

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

• 性能開銷：AOF 持久化需要頻繁寫入磁盤，可能會影響 Redis 的寫入性能。
• 文件大小：AOF 文件通常比 RDB 文件大，尤其是在寫操作頻繁的情況下。
• 恢復(fù)速度：AOF 恢復(fù)數(shù)據(jù)時需要重放所有命令，速度較慢。

Redis 與 Memcached 對比：

• 持久化：Redis 支持持久化，而 Memcached 不支持。
• 數(shù)據(jù)結(jié)構(gòu)：Redis 支持多種數(shù)據(jù)結(jié)構(gòu)（如字符串、哈希、列表、集合等），而 Memcached 僅支持簡單的鍵值對。
• 適用場景：Redis 適合需要持久化和復(fù)雜數(shù)據(jù)結(jié)構(gòu)的場景，而 Memcached 更適合簡單的緩存需求。

Redis 與 Guava Cache/Caffeine 對比：

• 本地緩存 vs 分布式緩存：Guava Cache 和 Caffeine 是本地緩存，不支持分布式。Redis 是分布式緩存，支持多節(jié)點共享數(shù)據(jù)。
• 持久化：Guava Cache 和 Caffeine 不支持持久化。
• 適用場景：對于單機應(yīng)用，Guava Cache 或 Caffeine 是高性能的選擇；對于分布式系統(tǒng)，Redis 是更好的選擇。

各種緩存技術(shù)的使用場景：

• Redis：適用于需要高可用性、數(shù)據(jù)持久化和復(fù)雜數(shù)據(jù)結(jié)構(gòu)的場景，如分布式系統(tǒng)、電商系統(tǒng)、實時數(shù)據(jù)處理等。
• Memcached：適用于簡單的緩存需求，如網(wǎng)頁緩存。
• Guava Cache/Caffeine：適用于單機應(yīng)用，尤其是需要高性能本地緩存的場景。

Redis 的持久化功能使其在需要數(shù)據(jù)安全性和高可用性的場景中具有顯著優(yōu)勢，但這種優(yōu)勢也帶來了性能開銷和文件大小的增加。在選擇緩存技術(shù)時，應(yīng)根據(jù)具體需求權(quán)衡數(shù)據(jù)安全性、性能和成本。對于分布式系統(tǒng)和復(fù)雜數(shù)據(jù)結(jié)構(gòu)的需求，Redis 是更優(yōu)的選擇。