A: rdbcompression 設置為 yes 時，表示啟用 rdbcompression， 啟用 rdbcompression 會使Redis在保存數(shù)據(jù)前先對其進行壓縮，這樣可以減少存儲空間的使用。但這也意味著在數(shù)據(jù)加載時可能需要額外的 CPU 時間來解壓。

Q: 我在配置中看到了 rdbchecksum，這是什么意思？

A: rdbchecksum 決定是否在 RDB 文件末尾添加一個 CRC64 校驗和。這個校驗和幫助檢測 RDB 文件是否在傳輸或存儲過程中受到損壞。如果你設置為yes，那么每次 Redis 保存或加載 RDB 文件時，它都會計算并檢查這個校驗和，確保數(shù)據(jù)的完整性。

Q: 什么是sanitize-dump-payload？我應該如何配置它？

A: 當你有一個Redis數(shù)據(jù)備份（RDB文件）或者使用 RESTORE 命令來導入數(shù)據(jù)時，你會希望這些數(shù)據(jù)是安全的，沒有任何問題。但是，有些時候數(shù)據(jù)可能存在問題，這可能會導致 Redis 在后續(xù)的操作中崩潰或者出現(xiàn)錯誤。

sanitize-dump-payload 這個配置項就是幫助你在加載數(shù)據(jù)時檢查這些數(shù)據(jù)的安全性。

如果你設置為no，那么Redis不會檢查數(shù)據(jù)，這樣會更快，但是風險也更大。

如果設置為yes，Redis會檢查所有的數(shù)據(jù)，確保它們是安全的，不會導致問題。這樣更安全，但可能會稍微慢一些。

如果設置為clients，只有從客戶端（比如你的應用程序）發(fā)來的數(shù)據(jù)會被檢查，而從其它 Redis 實例同步來的數(shù)據(jù)或RDB文件不會被檢查。

Q: rdb-del-sync-files 配置是做什么的？

A: 這個配置項決定是否在某些場景下刪除與復制（replication）相關的RDB文件。

在 Redis 的主從復制過程中，主節(jié)點需要生成 RDB 文件并將其發(fā)送給從節(jié)點，幫助從節(jié)點進行數(shù)據(jù)同步。在某些特定的安全環(huán)境中，一旦復制完畢，可能會要求盡快刪除這些RDB文件。

rdb-del-sync-files 這個選項，當設置為 yes 時，并且主節(jié)點沒有啟用 RDB 和 AOF持久化，redis 會自動刪除這些與復制相關的 RDB 文件。

默認為no，這意味著與復制相關的RDB文件在同步后不會被自動刪除。

Q8: dbfilename 和 dir 分別指的是什么？

A: dbfilename 是 RDB 文件名（默認是 dump.rdb）；dir 則是 RDB 文件存放的目錄，默認值 ./（當前目錄：Redis服務器啟動時的工作目錄），但推薦指定一個固定的目錄，例如：/var/redis/data/

注意：

• 上述的save 、dbfilename、以及 dir 指令配置是我們重點關注的，其他了解即可。

• 在更改 redis.conf 配置之后，我們需要重啟 redis 服務，才能生效。

RDB 持久化的優(yōu)缺點

優(yōu)點

快速備份：RDB可以迅速為你創(chuàng)建一個數(shù)據(jù)的“快照”，這是一個備份文件，方便你存儲或者遷移數(shù)據(jù)。

啟動快：當Redis重新啟動時，RDB能幫助它更快速地加載數(shù)據(jù)，因為它直接讀取一個完整的數(shù)據(jù)文件。

節(jié)省空間：與其他持久化方式相比，RDB的文件大小通常較小，因為它是經(jīng)過壓縮的。

缺點：

可能丟數(shù)據(jù)：因為RDB只是不時地保存一次數(shù)據(jù)快照，如果在兩次保存之間Redis出了問題，那中間的數(shù)據(jù)就可能會丟失。

有時會卡：在數(shù)據(jù)很多的情況下，創(chuàng)建 RDB 文件時可能會使服務器短暫地感覺有些卡頓。

卡頓的原因：盡管 Redis 使用寫時復制（Copy-On-Write, COW）技術來減少內(nèi)存的復制，fork( ) 在大數(shù)據(jù)集上的調(diào)用仍然可能相當耗時。這是因為操作系統(tǒng)需要為子進程準備一個與父進程相同的虛擬內(nèi)存空間。在這個準備過程中，即使不立即復制物理內(nèi)存，操作系統(tǒng)也需要復制和設置父進程的頁表，這在數(shù)據(jù)集很大時會占用相當一部分時間。fork( ) 的執(zhí)行時間與服務器上的數(shù)據(jù)量大小成正比。因此在數(shù)據(jù)集較大時，fork 可能會有比較久的延遲才能返回，所以才造成的卡頓。

AOF

AOF是什么？

想象你正在寫日記，每次有新的事件，你就寫下來。AOF 就像是 Redis 的日記，記錄了所有的寫操作命令。

簡單圖解：

AOF文件 生成過程

AOF 的工作原理

基本機制和流程

Redis 中的 AOF 持久化方式旨在持續(xù)地保存服務器上的所有修改操作。每當執(zhí)行一個會改變數(shù)據(jù)的命令時，Redis 都會將該命令寫入 AOF 文件中。這樣，當 Redis 需要恢復數(shù)據(jù)時，只需執(zhí)行 AOF 文件中的命令就可以恢復到原來的狀態(tài)。

AOF 文件的生成

流程圖

AOF 文件生成流程圖

步驟說明：

AOF 持久化的實現(xiàn)主要是以上三步：命令追加、文件寫入、文件同步

• 命令追加: 將 redis 寫操作命令追加到 aof_buf 緩沖區(qū)
• 文件寫入: 周期性地將 aof_buf 緩沖區(qū)的命令寫入 AOF 文件的內(nèi)核緩沖區(qū)。
• 文件同步:根據(jù)配置同步策略，將 AOF 文件緩沖區(qū)的內(nèi)容同步到磁盤。

其中文件同步策略 redis 提供了三種，分別是以下三種：

always：每次有命令寫入時都立即同步。這提供了最高的數(shù)據(jù)安全性，但效率最低。

everysec：每秒同步一次。這是一個權衡安全性和效率的策略。最多只丟失 1 秒 的數(shù)據(jù)

no：讓操作系統(tǒng)決定最佳的同步時間。這可能導致數(shù)據(jù)丟失，但提供了最高的效率。

AOF 文件的載入

當 Redis 服務器啟動時，如果配置為使用 AOF 持久化，它會檢查 AOF 文件的存在。如果找到 AOF 文件，Redis 會加載并執(zhí)行其中的命令來恢復數(shù)據(jù)的。

這里順帶提個問題：假如 Redis 的 RDB 和 AOF 持久化都啟用，redis 在載入數(shù)據(jù)的時候，是載入 AOF 文件？還是 RDB 文件？

我直接說答案：Redis 會優(yōu)先載入 AOF 文件來恢復數(shù)據(jù)，而不是 RDB 文件。這是因為 AOF 文件通常包含了更完整的操作記錄，從而能夠恢復更完整的數(shù)據(jù)狀態(tài)。而 RDB 文件是定時生成的數(shù)據(jù)快照，所以它可能沒有記錄到最后一次快照之后發(fā)生的所有更改。因此，使用 AOF 文件恢復數(shù)據(jù)可以提供更高的數(shù)據(jù)完整性。

AOF 重寫

在了解了 AOF 的工作原理之后，我們知道它是通過追加寫操作命令到文件的方式來恢復數(shù)據(jù)的。但這會帶來一個新的問題: 隨著追加命令的不斷增加，這個 AOF 文件可能會變得很大和冗長。面對這樣的問題，Redis 提供了一個非常有效的優(yōu)化手段，那就是 AOF 重寫。

AOF重寫是什么？

AOF 重寫，可以看作是對 AOF文件 進行的一次“精簡”操作。它的目的是減少AOF文件的大小，并去除那些冗余的、不再必要的命令，使得該文件只包含恢復當前數(shù)據(jù)集所需的最小命令集。

為什么需要AOF重寫？

節(jié)省磁盤空間：隨著操作的積累，原始AOF文件可能會變得非常大。通過重寫，我們可以減少文件的大小。

加速恢復速度：一個更小、更簡潔的AOF文件意味著在Redis重啟時，數(shù)據(jù)的恢復過程會更快。

AOF 重寫流程圖：

AOF 重寫過程

步驟說明：

AOF 重寫主要有以下四步：

• redis 主進程 fork 子進程來進行 AOF 的重寫，生成 AOF 文件。
• 在子進程進行 AOF 重寫的同時，redis 主進程將新的寫操作命令寫入 AOF重寫緩沖區(qū)
• 主進程將 AOF 重寫緩沖區(qū)的內(nèi)容寫入到新的 AOF 文件中
• 使用新的 AOF 文件替換舊的 AOF 文件

這里思考一下：子進程 進行 AOF 重寫，具體怎么重寫，是根據(jù)現(xiàn)有的 AOF 文件進行重寫還是其他方式？

子進程是通過讀取 Redis 當前的內(nèi)存數(shù)據(jù)來進行重寫的。假如: redis 數(shù)據(jù)庫存在列表鍵 List = [a,b,c,d,e,f,g,h] ，在舊的 AOF 文件中，可能有多個命令添加和刪除這些元素。但在 AOF 重寫時，子進程只需要看 List鍵 的當前狀態(tài)，然后生成一個簡短的命令，如 RPUSH List a b c d e f g h，直接設置正確的值，避免了任何冗余操作。

AOF 配置詳解

我們只需要在 Redis 配置文件 redis.conf 中搜索 APPEND ONLY MODE 即可搜到 AOF 配置項。

Q: 我想啟用 AOF 模式，我應該怎么做？

A: 將 appendonly 設置為 yes。默認是 no。

Q: 我想改變 AOF 文件的名稱，該怎么做？

A: 使用 appendfilename 選項。默認名稱是 appendonly.aof。

Q: 有哪些方式可以控制 AOF 數(shù)據(jù)同步到磁盤的頻率？

A: 使用 appendfsync 選項。你有三個選擇：

always: 每次寫操作后都同步。

everysec: 每秒同步一次。

no: 由操作系統(tǒng)決定何時同步。

默認設置是 everysec。

Q: 當 Redis 進行 AOF 重寫或快照保存時，我怎樣避免主進程 fsync 的延遲？

A: 設置 no-appendfsync-on-rewrite 為 yes。默認是 no。

Q: 我怎樣自動觸發(fā) AOF 文件重寫？

A: 使用以下兩個配置：

auto-aof-rewrite-percentage: AOF 文件增長的百分比，達到此值則觸發(fā) AOF 重寫。例如，如果設置為100%，那么當 AOF 文件的大小是上次重寫后的兩倍時，Redis 會考慮觸發(fā)自動重寫。

auto-aof-rewrite-min-size: AOF 文件大小門檻，超過此值即使增長的百分比小也會觸發(fā) AOF 重寫。

Q: 如果 AOF 文件在末尾被截斷，Redis怎么辦？

A: 使用 aof-load-truncated 選項。如果設置為 yes，Redis 嘗試加載并啟動，同時發(fā)出日志警告；如果為 no，Redis 會中止并拒絕啟動。默認是 yes。

AOF 持久化的優(yōu)缺點

優(yōu)點：

不輕易丟數(shù)據(jù)：AOF 記錄了所有的寫操作，所以即使服務器突然斷電，數(shù)據(jù)丟失的機會也很小。

易于理解：AOF是一個文本文件，里面就是一系列的命令，你可以打開查看。

出問題也能救：如果 AOF 文件最后有點損壞，Redis 也能夠修復它，避免大量數(shù)據(jù)丟失。

缺點：

可能會慢一些：因為要不斷寫入操作，所以比 RDB 要慢一點。

文件可能很大：AOF 會記錄所有操作，所以文件可能迅速增大，占用更多空間。

恢復時間長：如果需要從 AOF 文件中恢復數(shù)據(jù)，由于文件可能很大，所以這個過程可能會比較慢。

混合持久化

回顧一下，我們已經(jīng)探討了 Redis 的 RDB 和 AOF 持久化。RDB 提供快速的數(shù)據(jù)恢復，但可能有數(shù)據(jù)丟失風險；AOF 保證了數(shù)據(jù)完整性，但文件可能過大，恢復速度較慢。那么，是否有一種既快速又可靠的方法？接下來，我們將介紹 Redis 的混合持久化策略。

混合持久化是什么？

混合持久化是 Redis 4.0 新引入的持久化策略，結合了 RDB 的快速恢復和 AOF 的數(shù)據(jù)完整性的優(yōu)點，它首先以 RDB 格式保存當前數(shù)據(jù)狀態(tài)，然后繼續(xù)以 AOF 格式記錄新的寫操作，確保數(shù)據(jù)完整性并優(yōu)化恢復速度。

簡單圖解

混合持久化文件格式

混合持久化的工作原理

在 AOF 重寫之前，RDB 和 AOF 都是按照它們各自的持久化策略工作的。當 AOF 重寫被觸發(fā)時，混合持久化才開始發(fā)揮作用：將當前的數(shù)據(jù)集會首先以RDB 格式寫入新 AOF 文件的頂部，然后再追加新的命令到文件的末尾。

混合持久化的工作流程圖

redis 混合持久化流程圖

步驟說明：

混合持久化的實現(xiàn)主要是靠主進程和子進程共同來完成的。

子進程:

子進程進行 AOF 重寫：

• 首先創(chuàng)建新的 AOF 文件 appendonly.rdb
• 將 Redis 當前的數(shù)據(jù)生成 RDB 快照寫入 appendonly.rdb 文件的開始部分

主進程

• 主進程先將新的寫操作命令寫入 AOF 重寫緩沖區(qū)
  -主進程將 AOF 重寫緩沖區(qū)的內(nèi)容追加到 appendonly.rdb
  文件的 RDB 數(shù)據(jù)的末尾
• 使用 appendonly.rdb 文件替換舊的 AOF 文件

混合持久化的配置

Q: Redis 的混合持久化如何開啟？

A: 將 aof-use-rdb-preamble 選項設置為 yes，并且要同時啟用 RDB 和 AOF 兩種持久化。

混合持久化的 AOF 重寫與普通的 AOF 重寫的區(qū)別：

在不使用混合持久化的情況下，普通的 AOF 重寫是通過讀取當前的內(nèi)存數(shù)據(jù)并記錄達到這一狀態(tài)所需的最少命令來減少 AOF 文件的大小的。

而混合持久化在 AOF 重寫時，會首先將當前數(shù)據(jù)集以 RDB 格式快照的形式寫入新 AOF 文件的開始位置，然后再追加新的寫命令到文件末尾。

混合持久化的優(yōu)缺點

優(yōu)點：

更快的啟動速度：混合持久化結合了RDB的速度優(yōu)勢，所以Redis可以更快地重新啟動，不用等待很久。

數(shù)據(jù)安全：利用AOF的方式，即使服務器突然斷電，也只會丟失極短的時間內(nèi)的數(shù)據(jù)。

文件更小巧：因為混合持久化結合了 RDB 和 AOF 的優(yōu)勢，所以文件大小和冗余度都可以得到控制。

兩全其美：簡單說，它就是RDB和AOF的結合體，帶來了兩者的好處。

缺點：

稍微復雜：因為它結合了兩種技術，所以處理起來比單一的 RDB 或 AOF 要復雜一點。

可能占更多空間：在某些情況下，保存數(shù)據(jù)的文件可能會比只使用 RDB 或AOF 的文件要大一些。

寫入速度：可能會稍慢一些，特別是當數(shù)據(jù)需要經(jīng)常被保存到硬盤時（比如當 appendfsync 配置為“always”時）

總結

在本系列文章中，我們深入探討了 Redis 的持久化機制。通過詳細介紹 RDB、AOF 以及混合持久化這三種主流的持久化方法，我們不僅學習了它們各自的工作機制和配置策略，還探討了它們的優(yōu)缺點，以幫助讀者根據(jù)自己的實際需求選出合適的持久化方式。

• RDB 持久化以其高效的數(shù)據(jù)恢復速度和較小的性能開銷脫穎而出，適合數(shù)據(jù)備份和災難恢復場景。
• AOF 持久化通過記錄每個寫操作確保了更高級別的數(shù)據(jù)安全性，盡管它可能導致文件體積增大和寫入性能的輕微下降。
• 混合持久化模式結合了 RDB 的快速數(shù)據(jù)恢復能力和 AOF 的數(shù)據(jù)安全性，提供了一種既快速又可靠的數(shù)據(jù)恢復解決方案。

所以大家在選擇持久化策略時，需要考慮到數(shù)據(jù)安全性、恢復速度、以及系統(tǒng)性能三者之間的平衡。RDB 適合需要定期備份的場景，AOF 適合對數(shù)據(jù)丟失有嚴格要求的應用，而混合持久化模式則是一種比較折中的方案，它結合了 RDB 的快速數(shù)據(jù)恢復能力和 AOF 的數(shù)據(jù)安全性。

這里我又將 Redis 的三種持久化方式的優(yōu)缺點以及使用場景做了詳細的對比:

最后

如果你對 Linux C/C++ 編程，Redis 等后端技術感興趣或者想學習計算機基礎相關的知識，歡迎關注我。這里會持續(xù)更新的簡單易懂的技術文章，也包括常見的技術面試題。

大家如果覺得我寫的還不錯，也希望大家能夠幫忙點個贊，感謝大家的關注！