一文帶你深入了解Redis的持久化方式及其原理
Redis 提供了兩種持久化方式，一種是基于快照形式的 RDB，另一種是基于日志形式的 AOF，每種方式都有自己的優缺點，本文將介紹 Redis 這兩種持久化方式，希望閱讀本文后你對 Redis 的這兩種持久化方式有更加全面、清晰的認識。
RDB 快照方式持久化
先從 RDB 快照方式聊起，RDB 是 Redis 默認開啟的持久化方式，并不需要我們單獨開啟，先來看看跟 RDB 相關的配置信息：
- ################################ SNAPSHOTTING ################################
- #
- # Save the DB on disk:
- #
- # save <seconds> <changes>
- #
- # Will save the DB if both the given number of seconds and the given
- # number of write operations against the DB occurred.
- #
- # In the example below the behaviour will be to save:
- # after 900 sec (15 min) if at least 1 key changed
- # after 300 sec (5 min) if at least 10 keys changed
- # after 60 sec if at least 10000 keys changed
- # save ""
- # 自動生成快照的觸發機制 中間的是時間，單位秒，后面的是變更數據 60 秒變更 10000 條數據則自動生成快照
- save 900 1
- save 300 10
- save 60 10000
- # 生成快照失敗時，主線程是否停止寫入
- stop-writes-on-bgsave-error yes
- # 是否采用壓縮算法存儲
- rdbcompression yes
- # 數據恢復時是否檢測 RDB文件有效性
- rdbchecksum yes
- # The filename where to dump the DB
- # RDB 快照生成的文件名稱
- dbfilename dump.rdb
- # 快照生成的路徑 AOF 也是存放在這個路徑下面
- dir .
關于 RDB 相關配置信息不多，需要我們調整的就更少了，我們只需要根據自己的業務量修改生成快照的機制和文件存放路徑即可。
RDB 有兩種持久化方式：手動觸發 和 自動觸發，手動觸發使用以下兩個命令：
- save：會阻塞當前 Redis 服務器響應其他命令，直到 RDB 快照生成完成為止，對于內存 比較大的實例會造成長時間阻塞，所以線上環境不建議使用。
- bgsave：Redis 主進程會 fork 一個子進程，RDB 快照生成有子進程來負責，完成之后，子進程自動結束，bgsave 只會在 fork 子進程的時候短暫的阻塞，這個過程是非常短的，所以推薦使用該命令來手動觸發。
除了執行命令手動觸發之外，Redis 內部還存在自動觸發 RDB 的持久化機制，在以下幾種情況下 Redis 會自動觸發 RDB 持久化：
- 在配置中配置了 save 相關配置信息，如我們上面配置文件中的 save 60 10000 ，也可以把它歸類為“save m n”格式的配置，表示 m 秒內數據集存在 n 次修改時，會自動觸發 bgsave。
- 在主從情況下，如果從節點執行全量復制操作，主節點自動執行 bgsave 生成 RDB 文件并發送給從節點。
- 執行 debug reload 命令重新加載 Redis 時，也會自動觸發 save 操作。
- 默認情況下執行 shutdown 命令時，如果沒有開啟 AOF 持久化功能則自動執行 bgsave。
上面就是 RDB 持久化的方式，可以看出 save 命令使用的比較少，大多數情況下使用的都是 bgsave 命令，所以這個 bgsave 命令還是有一些東西，那接下來我們就一起看看 bgsave 背后的原理，先從流程圖開始入手：
bgsave 運作流程圖
bgsave 命令大概有以下幾個步驟：
1、執行 bgsave 命令，Redis 主進程判斷當前是否存在正在執行的 RDB/AOF 子進程，如果存在， bgsave 命令直接返回不在往下執行。
2、父進程執行 fork 操作創建子進程，fork 操作過程中父進程會阻塞，fork 完成后父進程將不在阻塞可以接受其他命令。
3、子進程創建新的 RDB 文件，基于父進程當前內存數據生成臨時快照文件，完成后用新的 RDB 文件替換原有的 RDB 文件，并且給父進程發送 RDB 快照生成完畢通知。
上面就是 bgsave 命令背后的一些內容，RDB 的內容就差不多了，我們一起來總結 RDB 持久化的優缺點，RDB 方式的優點：
- RDB 快照是某一時刻 Redis 節點內存數據，非常適合做備份，上傳到遠程服務器或者文件系統中，用于容災備份。
- 數據恢復時 RDB 要遠遠快于 AOF。
有優點同樣存在缺點，RDB 的缺點有：
- RDB 持久化方式數據沒辦法做到實時持久化/秒級持久化。我們已經知道了 bgsave 命令每次運行都要執行 fork 操作創建子進程，屬于重量級操作，頻繁執行成本過高。
- RDB 文件使用特定二進制格式保存，Redis 版本演進過程中有多個格式 的 RDB 版本，存在老版本 Redis 服務無法兼容新版 RDB 格式的問題。
如果我們對數據要求比較高，每一秒的數據都不能丟，RDB 持久化方式肯定是不能夠滿足要求的，那 Redis 有沒有辦法滿足呢，答案是有的，那就是接下來的 AOF 持久化方式。
AOF 文件持久化方式
Redis 默認并沒有開啟 AOF 持久化方式，需要我們自行開啟，在 redis.conf 配置文件中將 appendonly no 調整為 appendonly yes，這樣就開啟了 AOF 持久化，與 RDB 不同的是 AOF 是以記錄操作命令的形式來持久化數據的，我們可以查看以下 AOF 的持久化文件 appendonly.aof。
- *2
- $6
- SELECT
- $1
- 0
- *3
- $3
- set
- $6
- mykey1
- $6
- 你好
- *3
- $3
- set
- $4
- key2
- $5
- hello
- *1
- $8
大概就是長這樣的，具體的你可以查看你 Redis 服務器上的 appendonly.aof 配置文件，這也意味著我們可以在 appendonly.aof 文件中國修改值，等 Redis 重啟時將會加載修改之后的值。看似一些簡單的操作命令，其實從命令到 appendonly.aof 這個過程中非常有學問的，下面時 AOF 持久化流程圖：
AOF 持久化流程圖
在 AOF 持久化過程中有兩個非常重要的操作：一個是將操作命令追加到 AOF_BUF 緩存區，另一個是 AOF_buf 緩存區數據同步到 AOF 文件，接下來我們詳細聊一聊這兩個操作：
1、為什么要將命令寫入到 aof_buf 緩存區而不是直接寫入到 aof 文件?
我們知道 Redis 是單線程響應，如果每次寫入 AOF 命令都直接追加到磁盤上的 AOF 文件中，這樣頻繁的 IO 開銷，Redis 的性能就完成取決于你的機器硬件了，為了提升 Redis 的響應效率就添加了一層 aof_buf 緩存層， 利用的是操作系統的 cache 技術，這樣就提升了 Redis 的性能，雖然這樣性能是解決了，但是同時也引入了一個問題，aof_buf 緩存區數據如何同步到 AOF 文件呢?由誰同步呢?這就是我們接下來要聊的一個操作：fsync 操作。
2、aof_buf 緩存區數據如何同步到 aof 文件中?
aof_buf 緩存區數據寫入到 aof 文件是有 linux 系統去完成的，由于 Linux 系統調度機制周期比較長，如果系統故障宕機了，意味著一個周期內的數據將全部丟失，這不是我們想要的，所以 Linux 提供了一個 fsync 命令，fsync 是針對單個文件操作(比如這里的 AOF 文件)，做強制硬盤同步，fsync 將阻塞直到寫入硬盤完成后返回，保證了數據持久化，正是由于有這個命令，所以 redis 提供了配置項讓我們自行決定何時進行磁盤同步，redis 在 redis.conf 中提供了appendfsync 配置項，有如下三個選項：
- # appendfsync always
- appendfsync everysec
- # appendfsync no
- always：每次有寫入命令都進行緩存區與磁盤數據同步，這樣保證不會有數據丟失，但是這樣會導致 redis 的吞吐量大大下降，下降到每秒只能支持幾百的 TPS ，這違背了 redis 的設計，所以不推薦使用這種方式
- everysec：這是 redis 默認的同步機制，雖然每秒同步一次數據，看上去時間也很快的，但是它對 redis 的吞吐量沒有任何影響，每秒同步一次的話意味著最壞的情況下我們只會丟失 1 秒的數據， 推薦使用這種同步機制，兼顧性能和數據安全
- no：不做任何處理，緩存區與 aof 文件同步交給系統去調度，操作系統同步調度的周期不固定，最長會有 30 秒的間隔，這樣出故障了就會丟失比較多的數據。
這就是三種磁盤同步策略，但是你有沒有注意到一個問題，AOF 文件都是追加的，隨著服務器的運行 AOF 文件會越來越大，體積過大的 AOF 文件對 redis 服務器甚至是主機都會有影響，而且在 Redis 重啟時加載過大的 AOF 文件需要過多的時間，這些都是不友好的，那 Redis 是如何解決這個問題的呢?Redis 引入了重寫機制來解決 AOF 文件過大的問題。
3、Redis 是如何進行 AOF 文件重寫的?
Redis AOF 文件重寫是把 Redis 進程內的數據轉化為寫命令同步到新 AOF 文件的過程，重寫之后的 AOF 文件會比舊的 AOF 文件占更小的體積，這是由以下幾個原因導致的：
- 進程內已經超時的數據不再寫入文件
- 舊的 AOF 文件含有無效命令，如 del key1、hdel key2、srem keys、set a111、set a222等。重寫使用進程內數據直接生成，這樣新的AOF文件只保 留最終數據的寫入命令
- 多條寫命令可以合并為一個，如：lpush list a、lpush list b、lpush list c可以轉化為：lpush list a b c。為了防止單條命令過大造成客戶端緩沖區溢 出，對于 list、set、hash、zset 等類型操作，以 64 個元素為界拆分為多條。
重寫之后的 AOF 文件體積更小了，不但能夠節約磁盤空間，更重要的是在 Redis 數據恢復時，更小體積的 AOF 文件加載時間更短。AOF 文件重寫跟 RDB 持久化一樣分為手動觸發和自動觸發，手動觸發直接調用 bgrewriteaof 命令就好了，我們后面會詳細聊一聊這個命令，自動觸發就需要我們在 redis.conf 中修改以下幾個配置：
- auto-aof-rewrite-percentage 100
- auto-aof-rewrite-min-size 64mb
- auto-aof-rewrite-percentage：代表當前 AOF文件空間 (aof_current_size)和上一次重寫后 AOF 文件空間(aof_base_size)的比值，默認是 100%，也就是一樣大的時候
- auto-aof-rewrite-min-size：表示運行 AOF 重寫時 AOF 文件最小體積，默認為 64MB，也就是說 AOF 文件最小為 64MB 才有可能觸發重寫。
滿足了這兩個條件，Redis 就會自動觸發 AOF 文件重寫，AOF 文件重寫的細節跟 RDB 持久化生成快照有點類似，下面是 AOF 文件重寫流程圖：
AOF 文件重寫
AOF 文件重寫也是交給子進程來完成，跟 RDB 生成快照很像，AOF 文件重寫在重寫期間建立了一個 aof_rewrite_buf 緩存區來保存重寫期間主進程響應的命令，等新的 AOF 文件重寫完成后，將這部分文件同步到新的 AOF 文件中，最后用新的 AOF 文件替換掉舊的 AOF 文件。需要注意的是在重寫期間，舊的 AOF 文件依然會進行磁盤同步，這樣做的目的是防止重寫失敗導致數據丟失。
Redis 持久化數據恢復
我們知道 Redis 是基于內存的，所有的數據都存放在內存中，由于機器宕機或者其他因素重啟了就會導致我們的數據全部丟失，這也就是要做持久化的原因，當服務器重啟時，Redis 會從持久化文件中加載數據，這樣我們的數據就恢復到了重啟前的數據，在數據恢復這一塊Redis 是如何實現的?我們先來看看數據恢復的流程圖：
Redis 數據恢復
Redis 的數據恢復流程比較簡單，優先恢復的是 AOF 文件，如果 AOF 文件不存在時則嘗試加載 RDB 文件，為什么 RDB 的恢復速度比 AOF 文件快，但是還是會優先加載 AOF 文件呢?我個人認為是 AOF 文件數據更全面并且 AOF 兼容性比 RDB 強，需要注意的是當存在 RDB/AOF 時，如果數據加載不成功，Redis 服務啟動會失敗。
