大家好，我是小林哥。雖說 Redis 是內存數(shù)據(jù)庫，但是它為數(shù)據(jù)的持久化提供了兩個技術。分別是「 AOF 日志和 RDB 快照」。這兩種技術都會用各用一個日志文件來記錄信息，但是記錄的內容是不同的。

• AOF 文件的內容是操作命令；

• RDB 文件的內容是二進制數(shù)據(jù)。

關于 AOF 持久化的原理我在上一篇已經(jīng)介紹了，今天主要講下 RDB 快照。

所謂的快照，就是記錄某一個瞬間東西，比如當我們給風景拍照時，那一個瞬間的畫面和信息就記錄到了一張照片。

所以，RDB 快照就是記錄某一個瞬間的內存數(shù)據(jù)，記錄的是實際數(shù)據(jù)，而 AOF 文件記錄的是命令操作的日志，而不是實際的數(shù)據(jù)。

因此在 Redis 恢復數(shù)據(jù)時， RDB 恢復數(shù)據(jù)的效率會比 AOF 高些，因為直接將 RDB 文件讀入內存就可以，不需要像 AOF 那樣還需要額外執(zhí)行操作命令的步驟才能恢復數(shù)據(jù)。

接下來，就來具體聊聊 RDB 快照 。

快照怎么用？

要熟悉一個東西，先看看怎么用是比較好的方式。

Redis 提供了兩個命令來生成 RDB 文件，分別是 save 和 bgsave，他們的區(qū)別就在于是否在「主線程」里執(zhí)行：

• 執(zhí)行了 save 命令，就會在主線程生成 RDB 文件，由于和執(zhí)行操作命令在同一個線程，所以如果寫入 RDB 文件的時間太長，會阻塞主線程；

• 執(zhí)行了 bgsava 命令，會創(chuàng)建一個子進程來生成 RDB 文件，這樣可以避免主線程的阻塞；

RDB 文件的加載工作是在服務器啟動時自動執(zhí)行的，Redis 并沒有提供專門用于加載 RDB 文件的命令。

Redis 還可以通過配置文件的選項來實現(xiàn)每隔一段時間自動執(zhí)行一次 bgsava 命令，默認會提供以下配置：

save?900?1
save?300?10
save?60?10000
別看選項名叫 sava，實際上執(zhí)行的是 bgsava 命令，也就是會創(chuàng)建子進程來生成 RDB 快照文件。

只要滿足上面條件的任意一個，就會執(zhí)行 bgsava，它們的意思分別是：

• 900 秒之內，對數(shù)據(jù)庫進行了至少 1 次修改；

• 300 秒之內，對數(shù)據(jù)庫進行了至少 10 次修改；

• 60 秒之內，對數(shù)據(jù)庫進行了至少 10000 次修改。

這里提一點，Redis 的快照是全量快照，也就是說每次執(zhí)行快照，都是把內存中的「所有數(shù)據(jù)」都記錄到磁盤中。

所以可以認為，執(zhí)行快照是一個比較重的操作，如果頻率太頻繁，可能會對 Redis 性能產(chǎn)生影響。如果頻率太低，服務器故障時，丟失的數(shù)據(jù)會更多。

通?？赡茉O置至少 5 分鐘才保存一次快照，這時如果 Redis 出現(xiàn)宕機等情況，則意味著最多可能丟失 5 分鐘數(shù)據(jù)。

這就是 RDB 快照的缺點，在服務器發(fā)生故障時，丟失的數(shù)據(jù)會比 AOF 持久化的方式更多，因為 RDB 快照是全量快照的方式，因此執(zhí)行的頻率不能太頻繁，否則會影響 Redis 性能，而 AOF 日志可以以秒級的方式記錄操作命令，所以丟失的數(shù)據(jù)就相對更少。

執(zhí)行快照時，數(shù)據(jù)能被修改嗎？

那問題來了，執(zhí)行 bgsava 過程中，由于是交給子進程來構建 RDB 文件，主線程還是可以繼續(xù)工作的，此時主線程可以修改數(shù)據(jù)嗎？

如果不可以修改數(shù)據(jù)的話，那這樣性能一下就降低了很多。如果可以修改數(shù)據(jù)，又是如何做到到呢？

直接說結論吧，執(zhí)行 bgsava 過程中，Redis 依然可以繼續(xù)處理操作命令的，也就是數(shù)據(jù)是能被修改的。

那具體如何做到到呢？關鍵的技術就在于寫時復制技術（Copy-On-Write, COW）。

執(zhí)行 bgsava 命令的時候，會通過 fork() 創(chuàng)建子進程，此時子進程和父進程是共享同一片內存數(shù)據(jù)的，因為創(chuàng)建子進程的時候，會復制父進程的頁表，但是頁表指向的物理內存還是一個。

只有在發(fā)生修改內存數(shù)據(jù)的情況時，物理內存才會被復制一份。

這樣的目的是為了減少創(chuàng)建子進程時的性能損耗，從而加快創(chuàng)建子進程的速度，畢竟創(chuàng)建子進程的過程中，是會阻塞主線程的。

所以，創(chuàng)建 bgsave 子進程后，由于共享父進程的所有內存數(shù)據(jù)，于是就可以直接讀取主線程里的內存數(shù)據(jù)，并將數(shù)據(jù)寫入到 RDB 文件。

當主線程對這些共享的內存數(shù)據(jù)也都是只讀操作，那么，主線程和 bgsave 子進程相互不影響。

但是，如果主線程要修改共享數(shù)據(jù)里的某一塊數(shù)據(jù)（比如鍵值對 A）時，就會發(fā)生寫時復制，于是這塊數(shù)據(jù)的物理內存就會被復制一份（鍵值對 A'），然后主線程在這個數(shù)據(jù)副本（鍵值對 A'）進行修改操作。與此同時，bgsave 子進程可以繼續(xù)把原來的數(shù)據(jù)（鍵值對 A）寫入到 RDB 文件。

就是這樣，Redis 使用 bgsave 對當前內存中的所有數(shù)據(jù)做快照，這個操作是由 bgsave 子進程在后臺完成的，執(zhí)行時不會阻塞主線程，這就使得主線程同時可以修改數(shù)據(jù)。

細心的同學，肯定發(fā)現(xiàn)了，bgsave 快照過程中，如果主線程修改了共享數(shù)據(jù)，發(fā)生了寫時復制后，RDB 快照保存的是原本的內存數(shù)據(jù)，而主線程剛修改的數(shù)據(jù)，是被辦法在這一時間寫入 RDB 文件的，只能交由下一次的 bgsave 快照。

所以 Redis 在使用 bgsave 快照過程中，如果主線程修改了內存數(shù)據(jù)，不管是否是共享的內存數(shù)據(jù)，RDB 快照都無法寫入主線程剛修改的數(shù)據(jù)，因為此時主線程的內存數(shù)據(jù)和子線程的內存數(shù)據(jù)已經(jīng)分離了，子線程寫入到 RDB 文件的內存數(shù)據(jù)只能是原本的內存數(shù)據(jù)。

如果系統(tǒng)恰好在 RDB 快照文件創(chuàng)建完畢后崩潰了，那么 Redis 將會丟失主線程在快照期間修改的數(shù)據(jù)。

另外，寫時復制的時候會出現(xiàn)這么個極端的情況。

在 Redis 執(zhí)行 RDB 持久化期間，剛 fork 時，主進程和子進程共享同一物理內存，但是途中主進程處理了寫操作，修改了共享內存，于是當前被修改的數(shù)據(jù)的物理內存就會被復制一份。

那么極端情況下，如果所有的共享內存都被修改，則此時的內存占用是原先的 2 倍。

所以，針對寫操作多的場景，我們要留意下快照過程中內存的變化，防止內存被占滿了。

RDB 和 AOF 合體

盡管 RDB 比 AOF 的數(shù)據(jù)恢復速度快，但是快照的頻率不好把握：

• 如果頻率太低，兩次快照間一旦服務器發(fā)生宕機，就可能會比較多的數(shù)據(jù)丟失；

• 如果頻率太高，頻繁寫入磁盤和創(chuàng)建子進程會帶來額外的性能開銷。

那有沒有什么方法不僅有 RDB 恢復速度快的優(yōu)點和，又有 AOF 丟失數(shù)據(jù)少的優(yōu)點呢？

當然有，那就是將 RDB 和 AOF 合體使用，這個方法是在 Redis 4.0 提出的，該方法叫混合使用 AOF 日志和內存快照，也叫混合持久化。

如果想要開啟混合持久化功能，可以在 Redis 配置文件將下面這個配置項設置成 yes：

aof-use-rdb-preamble?yes
混合持久化工作在 AOF 日志重寫過程。

當開啟了混合持久化時，在 AOF 重寫日志時，fork 出來的重寫子進程會先將與主線程共享的內存數(shù)據(jù)以 RDB 方式寫入到 AOF 文件，然后主線程處理的操作命令會被記錄在重寫緩沖區(qū)里，重寫緩沖區(qū)里的增量命令會以 AOF 方式寫入到 AOF 文件，寫入完成后通知主進程將新的含有 RDB 格式和 AOF 格式的 AOF 文件替換舊的的 AOF 文件。

也就是說，使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量數(shù)據(jù)，后半部分是 AOF 格式的增量數(shù)據(jù)。

這樣的好處在于，重啟 Redis 加載數(shù)據(jù)的時候，由于前半部分是 RDB 內容，這樣加載的時候速度會很快。

加載完 RDB 的內容后，才會加載后半部分的 AOF 內容，這里的內容是 Redis 后臺子進程重寫 AOF 期間，主線程處理的操作命令，可以使得數(shù)據(jù)更少的丟失。