redis數據結構-11（了解 Redis 持久性選項：RDB 和 AOF）

了解 Redis 持久性選項：RDB 和 AOF

Redis 提供了多個持久性選項，以確保數據持久性并防止在服務器發生故障或重啟時丟失數據。了解這些選項對于為您的特定使用案例選擇正確的策略、平衡性能和數據安全至關重要。本章節將深入探討 Redis 中的兩種主要持久性機制：Redis 數據庫（RDB）快照和僅附加文件（AOF）。我們將探討它們的工作原理、優點和缺點以及如何配置它們。

了解 RDB 快照

RDB（Redis 數據庫）持久性按指定的時間間隔執行數據集的時間點快照。這些快照表示 Redis 數據庫在特定時刻的整個狀態。

RDB 的工作原理

當指示 Redis 創建 RDB 快照時，它會執行以下步驟：

**分叉：**Redis 使用 fork（） 系統調用創建子進程。此子進程是父進程（Redis 服務器）的精確副本。
數據轉儲： 然后，子進程遍歷內存中的整個數據集，并將其寫入磁盤上的臨時文件。
文件壓縮（可選）： 默認情況下，Redis 使用 LZF 壓縮來壓縮 RDB 文件以減小其大小。這可以進行配置。
原子替換： 子進程完成 RDB 文件的寫入后，它會以原子方式將舊的 RDB 文件（如果存在）替換為新的 RDB 文件。這可確保 RDB 文件始終處于一致狀態。
子進程終止： 然后，子進程將退出，從而釋放系統資源。

在整個過程中，父進程繼續為客戶端請求提供服務，從而最大限度地減少停機時間。但是，fork（） 作可能會占用大量資源，尤其是對于大型數據集，因為它暫時需要雙倍的內存。

配置 RDB 快照

您可以使用 redis.conf 文件中的 save 指令配置 RDB 快照。save 指令采用兩個參數：秒數和在這些秒內必須發生的更改數才能觸發快照。

例如：

save 900 1       # Save the DB if at least 1 key changed in 900 seconds
save 300 10      # Save the DB if at least 10 keys changed in 300 seconds
save 60 10000    # Save the DB if at least 10000 keys changed in 60 seconds

redis.conf 中的這些行定義了三個不同的保存點。如果滿足_這些條件中的任何一個_ ，Redis 將觸發 RDB 快照。您可以通過注釋掉所有保存行來完全禁用 RDB 快照。

您還可以使用 redis-cli 中的 SAVE 或 BGSAVE 命令手動觸發 RDB 快照。

SAVE： 此命令執行同步保存，阻止 Redis 服務器，直到快照完成。通常不建議將其用于生產環境。
BGSAVE： 此命令使用上述相同的分叉機制執行異步保存。它允許 Redis 服務器在創建快照時繼續為客戶端請求提供服務。

RDB 的優勢

**壓實度：**RDB 文件非常緊湊，非常適合用于備份和災難恢復。
**性能：**RDB 快照的創建（尤其是壓縮）和還原速度相對較快。
**災難恢復：**RDB 非常適合災難恢復，因為單個文件代表整個數據集。
**數據可移植性：**RDB 文件易于移植，可以傳輸到其他服務器或存檔以進行長期存儲。

RDB 的缺點

**數據丟失可能性：**RDB 快照是時間點備份，因此在快照之間寫入的任何數據在服務器發生故障時都將丟失。可能的數據丟失量取決于配置的存儲間隔。
分叉開銷：fork（） 作可能會占用大量資源，尤其是對于大型數據集，這可能會導致暫時的性能下降。

RDB 配置選項

除了 save 指令之外，redis.conf 中其他與 RDB 相關的配置選項還包括：

stop-writes-on-bgsave-error：如果設置為 yes（默認值），則當 BGSAVE 命令失敗時，Redis 將停止接受寫入作。這可以防止在出現磁盤錯誤或磁盤空間不足時損壞數據。
rdbcompression：如果設置為 yes（默認值），Redis 將使用 LZF 壓縮 RDB 文件。將其設置為 no 可以提高 CPU 性能，但會導致 RDB 文件變大。
rdbchecksum：如果設置為 yes（默認值），Redis 將在 RDB 文件中包含一個校驗和，以檢測數據損壞。將其設置為 no 可以提高性能，但會降低數據完整性。
dbfilename：指定 RDB 文件的名稱（默認值：dump.rdb）。
dir：指定 RDB 文件的存儲目錄（默認：Redis 工作目錄）。

了解 AOF（僅追加文件）

AOF（僅附加文件）持久性為 RDB 快照提供了更持久的替代方案。AOF 不會定期拍攝快照，而是記錄服務器收到的每個寫入作。

AOF 的工作原理

啟用 AOF 后，Redis 會將每個寫入作（例如 SET、HSET、``LPUSH）附加到 AOF 文件中。此文件實質上包含對數據庫執行的所有寫入作的完整歷史記錄。

命令附加： 每次執行寫入作時，Redis 都會將相應的命令附加到 AOF 文件中。該命令以 Redis 協議格式編寫。
**文件同步：**AOF 文件會定期同步到磁盤，以保證數據的持久性。此同步的頻率是可配置的。
AOF 重寫： 隨著時間的推移，AOF 文件可能會變得非常大，因為它包含所有寫入作的歷史記錄。為了減小文件大小，Redis 可以執行 AOF 重寫。AOF 重寫會創建一個新的、更小的 AOF 文件，其中包含重新創建當前數據集所需的最少命令集。這與 RDB 快照的工作方式類似，但結果仍然是 AOF 文件。

配置 AOF

AOF 在 redis.conf 文件中配置。關鍵配置選項包括：

appendonly：設置為 yes 以啟用 AOF 持久化。設置為 no 可禁用它（默認）。
appendfilename：指定 AOF 文件的名稱（默認：appendonly.aof）。
appendfsync：指定 Redis 應將 AOF 文件同步到磁盤的頻率。它可以具有以下值之一：
- always：在每次寫入作后同步。這提供了最高級別的數據持久性，但也提供了最低的性能。
- everysec：每秒同步一次。這是數據持久性和性能之間的良好平衡（推薦）。
- no：讓作系統決定何時同步。這提供了最佳性能，但數據持久性級別最低。

AOF 重寫配置

使用以下選項配置 AOF 重寫：

auto-aof-rewrite-percentage：指定在觸發重寫之前 AOF 文件必須增長的百分比。例如，值 100 表示 AOF 文件的大小必須翻倍才能觸發重寫。
auto-aof-rewrite-min-size：指定觸發重寫之前 AOF 文件的最小大小。這可以防止重寫非常小的 AOF 文件。

您還可以使用 redis-cli 中的 BGREWRITEAOF 命令手動觸發 AOF 重寫。

AOF 的優勢

**高數據持久性：**AOF 提供比 RDB 更高的數據持久性，尤其是在使用 appendfsync always 或 appendfsync everysec 時。
減少數據丟失： 如果服務器發生故障，AOF 可確保將數據丟失降至最低，因為只有最后幾個尚未同步到磁盤的命令會丟失。
**人類可讀格式：**AOF 文件采用人類可讀格式（Redis 協議），因此可以更輕松地在需要時手動調試和恢復數據。

AOF 的缺點

**較大的文件大小：**AOF 文件通常比 RDB 文件大，因為它們包含所有寫入作的歷史記錄。
**性能開銷：**AOF 可能會帶來性能開銷，尤其是在始終使用 appendfsync 時。
**重寫開銷：**AOF 重寫可能是資源密集型的，盡管它是在后臺執行的。

RDB 與 AOF：比較

特征	RDB	AOF
數據持久性	較低（可能丟失數據）	更高（最小數據丟失）
文件大小	較小	較大
性能	更快	更慢（尤其是 `always`）
恢復時間	更快	較慢（需要重放命令）
配置	`save` 指令	`appendonly`， `appendfsync` 指令
使用案例	備份、災難恢復、緩存	需要高數據持久性的應用程序

選擇正確的持久性選項

RDB 和 AOF 之間的選擇取決于您的具體要求：

RDB： 如果您需要快速備份和恢復，并且可以容忍一些數據丟失，請使用 RDB。它適用于數據丟失不嚴重的緩存方案。
主干： 如果您需要高數據持久性并且無法承受丟失數據，請使用 AOF。它適用于數據完整性至關重要的應用程序，例如金融系統或存儲關鍵用戶信息的數據庫。
混合方法： 您還可以同時使用 RDB 和 AOF。在這種情況下，Redis 將使用 AOF 來恢復數據，因為它提供了最完整的數據集。RDB 仍可用于非關鍵情況下的備份和更快的恢復。

實例

示例 1：為緩存服務器配置 RDB

假設您使用 Redis 作為網站的緩存服務器。數據丟失是可以接受的，因為可以從主數據庫中檢索數據。在這種情況下，您可以配置具有相對不頻繁的保存間隔的 RDB：

save 600 100      # Save if at least 100 keys changed in 600 seconds
save 300 1000     # Save if at least 1000 keys changed in 300 seconds
save 60 10000     # Save if at least 10000 keys changed in 60 seconds

此配置為緩存服務器提供了性能和數據持久性之間的良好平衡。

示例 2：為會話存儲配置 AOF

假設您使用 Redis 作為電子商務網站的會話存儲。數據丟失是不可接受的，因為它可能導致用戶丟失購物車或被注銷。在這種情況下，您應該每 sece 使用 appendfsync 配置 AOF：

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

此配置可確保每秒將每個會話更改寫入磁盤，從而最大限度地降低數據丟失的風險。

示例 3：同時使用 RDB 和 AOF

對于假設的財務應用程序，您可以同時使用 RDB 和 AOF。每 squad 使用 appendfsync 的 AOF 可確保將事務記錄的數據丟失降至最低。RDB 快照每天在非高峰時段拍攝，為災難恢復和報告目的提供方便的備份。如果服務器發生故障，Redis 將使用 AOF 文件進行恢復。如果 AOF 文件已損壞或不可用，則可以將每日 RDB 快照用作回退，從而承認自上次快照以來可能會丟失數據。