共計 3411 個字符，預計需要花費 9 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

丸趣 TV 小編給大家分享一下 Redis 持久化方案的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

Redis 支持 RDB 與 AOF 兩種持久化機制，持久化可以避免因進程異常退出或 down 機導致的數據丟失問題，在下次重啟時能利用之前的持久化文件實現數據恢復。

RDB 持久化

RDB 持久化即通過創建快照（壓縮的二進制文件）的方式進行持久化，保存某個時間點的全量數據。RDB 持久化是 Redis 默認的持久化方式。RDB 持久化的觸發包括手動觸發與自動觸發兩種方式。

手動觸發

save，在命令行執行 save 命令，將以同步的方式創建 rdb 文件保存快照，會阻塞服務器的主進程，生產環境中不要用

bgsave, 在命令行執行 bgsave 命令，將通過 fork 一個子進程以異步的方式創建 rdb 文件保存快照，除了 fork 時有阻塞，子進程在創建 rdb 文件時，主進程可繼續處理請求

自動觸發

在 redis.conf 中配置 save m n 定時觸發，如 save 900 1 表示在 900s 內至少存在一次更新就觸發
主從復制時，如果從節點執行全量復制操作，主節點自動執行 bgsave 生成 RDB 文件并發送給從節點
執行 debug reload 命令重新加載 Redis 時
執行 shutdown 且沒有開啟 AOF 持久化
redis.conf 中 RDB 持久化配置

 # 只要滿足下列條件之一，則會執行 bgsave 命令
save 900 1 # 在 900s 內存在至少一次寫操作
save 300 10
save 60 10000
# 禁用 RBD 持久化，可在最后加 save

# 當備份進程出錯時主進程是否停止寫入操作
stop-writes-on-bgsave-error yes
# 是否壓縮 rdb 文件 推薦 no 相對于硬盤成本 cpu 資源更貴
rdbcompression no

AOF 持久化

AOF（Append-Only-File）持久化即記錄所有變更數據庫狀態的指令，以 append 的形式追加保存到 AOF 文件中。在服務器下次啟動時，就可以通過載入和執行 AOF 文件中保存的命令，來還原服務器關閉前的數據庫狀態。

redis.conf 中 AOF 持久化配置如下

# 默認關閉 AOF，若要開啟將 no 改為 yes
appendonly no

# append 文件的名字
appendfilename appendonly.aof

# 每隔一秒將緩存區內容寫入文件 默認開啟的寫入方式
appendfsync everysec

# 當 AOF 文件大小的增長率大于該配置項時自動開啟重寫（這里指超過原大小的 100%）。
auto-aof-rewrite-percentage 100

# 當 AOF 文件大小大于該配置項時自動開啟重寫
auto-aof-rewrite-min-size 64mb

AOF 持久化的實現包括 3 個步驟:

命令追加：將命令追加到 AOF 緩沖區

文件寫入：緩沖區內容寫到 AOF 文件

文件保存：AOF 文件保存到磁盤

其中后兩步的頻率通過 appendfsync 來配置，appendfsync 的選項包括

always，每執行一個命令就保存一次，安全性最高，最多只丟失一個命令的數據，但是性能也最低（頻繁的磁盤 IO）

everysec，每一秒保存一次，推薦使用，在安全性與性能之間折中，最多丟失一秒的數據

no，依賴操作系統來執行（一般大概 30s 一次的樣子），安全性最低，性能最高，丟失操作系統最后一次對 AOF 文件觸發 SAVE 操作之后的數據

AOF 通過保存命令來持久化，隨著時間的推移，AOF 文件會越來越大，Redis 通過 AOF 文件重寫來解決 AOF 文件不斷增大的問題（可以減少文件的磁盤占有量，加快數據恢復的速度），原理如下：

調用 fork，創建一個子進程

子進程讀取當前數據庫的狀態來“重寫”一個新的 AOF 文件（這里雖然叫“重寫”，但實際并沒有對舊文件進行任何讀取，而是根據數據庫的當前狀態來形成指令）

主進程持續將新的變動同時寫到 AOF 重寫緩沖區與原來的 AOF 緩沖區中

主進程獲取到子進程重寫 AOF 完成的信號，調用信號處理函數將 AOF 重寫緩沖區內容寫入新的 AOF 文件中，并對新文件進行重命名，原子地覆蓋原有 AOF 文件，完成新舊文件的替換

AOF 的重寫也分為手動觸發與自動觸發

手動觸發：直接調用 bgrewriteaof 命令

自動觸發：根據 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 參數確定自動觸發時機。其中 auto-aof-rewrite-min-size 表示運行 AOF 重寫時文件最小體積，默認為 64MB。auto-aof-rewrite-percentage 表示當前 AOF 文件大小（aof_current_size）和上一次重寫后 AOF 文件大小（aof_base_size）的比值。自動觸發時機為 aof_current_size auto-aof-rewrite-min-size（aof_current_size – aof_base_size）/aof_base_size = auto-aof-rewrite-percentage

RDB vs AOF

RDB 與 AOF 兩種方式各有優缺點。

RDB 的優點：與 AOF 相比，RDB 文件相對較小，恢復數據比較快（原因見數據恢復部分）

RDB 的缺點：服務器宕機，RBD 方式會丟失掉上一次 RDB 持久化后的數據；使用 bgsave fork 子進程時會耗費內存。

AOF 的優點：AOF 只是追加文件，對服務器性能影響較小，速度比 RDB 快，消耗內存也少，同時可讀性高。

AOF 的缺點：生成的文件相對較大，即使通過 AOF 重寫，仍然會比較大；恢復數據的速度比 RDB 慢。

數據庫的恢復

服務器啟動時，如果沒有開啟 AOF 持久化功能，則會自動載入 RDB 文件，期間會阻塞主進程。如果開啟了 AOF 持久化功能，服務器則會優先使用 AOF 文件來還原數據庫狀態，因為 AOF 文件的更新頻率通常比 RDB 文件的更新頻率高，保存的數據更完整。

redis 數據庫恢復的處理流程如下，

在數據恢復方面，RDB 的啟動時間會更短，原因有兩個：

RDB 文件中每一條數據只有一條記錄，不會像 AOF 日志那樣可能有一條數據的多次操作記錄。所以每條數據只需要寫一次就行了，文件相對較小。

RDB 文件的存儲格式和 Redis 數據在內存中的編碼格式是一致的，不需要再進行數據編碼工作，所以在 CPU 消耗上要遠小于 AOF 日志的加載。

但是在進行 RDB 持久化時，fork 出來進行 dump 操作的子進程會占用與父進程一樣的內存，采用的 copy-on-write 機制，對性能的影響和內存的消耗都是比較大的。比如 16G 內存，Redis 已經使用了 10G，這時 save 的話會再生成 10G，變成 20G，大于系統的 16G。這時候會發生交換，要是虛擬內存不夠則會崩潰，導致數據丟失。所以在用 redis 的時候一定對系統內存做好容量規劃。

RDB、AOF 混合持久化

Redis 從 4.0 版開始支持 RDB 與 AOF 的混合持久化方案。首先由 RDB 定期完成內存快照的備份，然后再由 AOF 完成兩次 RDB 之間的數據備份，由這兩部分共同構成持久化文件。該方案的優點是充分利用了 RDB 加載快、備份文件小及 AOF 盡可能不丟數據的特性。缺點是兼容性差，一旦開啟了混合持久化，在 4.0 之前的版本都不識別該持久化文件，同時由于前部分是 RDB 格式，閱讀性較低。

開啟混合持久化

aof-use-rdb-preamble yes

數據恢復加載過程就是先按照 RDB 進行加載，然后把 AOF 命令追加寫入。

持久化方案的建議

如果 Redis 只是用來做緩存服務器，比如數據庫查詢數據后緩存，那可以不用考慮持久化，因為緩存服務失效還能再從數據庫獲取恢復。

如果你要想提供很高的數據保障性，那么建議你同時使用兩種持久化方式。如果你可以接受災難帶來的幾分鐘的數據丟失，那么可以僅使用 RDB。

通常的設計思路是利用主從復制機制來彌補持久化時性能上的影響。即 Master 上 RDB、AOF 都不做，保證 Master 的讀寫性能，而 Slave 上則同時開啟 RDB 和 AOF（或 4.0 以上版本的混合持久化方式）來進行持久化，保證數據的安全性。

以上是“Redis 持久化方案的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注丸趣 TV 行業資訊頻道！