我們都知道在對于Redis的開發(fā)或者面試的過程中，很容易就會遇到這個關于 Redis 持久化的問題，而我們在面試的時候，經常會有小伙伴只能說出這個 Redis 持久化的兩種方式，后續(xù)可能還會對比一些區(qū)別，但是對于怎么實現(xiàn)這個持久化的操作，都不是很熟，而且也并沒有實際應用過，以及什么時候應該使用什么類型的持久化，今天了不起就來給大家說說這個持久化。

Redis持久化

什么是 Redis 的持久化，我們都知道，Redis 是基于內存存儲的 key-value 的數(shù)據(jù)庫，那么如果出現(xiàn)斷電了，這就會導致數(shù)據(jù)丟失，那么持久化就非常重要了，也就是說，可以把數(shù)據(jù)寫入到硬盤上，而這個寫入到硬盤上面的操作，就是持久化。

Redis 持久化的兩種方式

• RDB（Redis DataBase)
• AOF（Append Of File）

什么是 RDB 呢？

簡而言之，就是在指定的時間間隔內，定時的將 redis 存儲的數(shù)據(jù)生成Snapshot快照并存儲到磁盤等介質上。

那么什么是 AOF 呢？

AOF 則是將 redis 執(zhí)行過的所有寫指令記錄下來，在下次 redis 重新啟動時，只要把這些寫指令從前到后再重復執(zhí)行一遍，就可以實現(xiàn)數(shù)據(jù)恢復了。

而 Redis 也是有自己默認的持久化的方式的，那就是 RDB 。

RDB持久化方式的原理

我們先說實現(xiàn)原理：

Redis 使用操作系統(tǒng)的多進程 COW(Copy On Write) 機制來實現(xiàn)快照持久化，這個機制很有意思，也很少人知道。多進程 COW 也是鑒定程序員知識廣度的一個重要指標。

Redis 在持久化時會調用 glibc 的函數(shù) fork 產生一個子進程，快照持久化完全交給子進程來處理，父進程繼續(xù)處理客戶端請求。子進程剛剛產生時，它和父進程共享內存里面的代碼段和數(shù)據(jù)段。這時你可以將父子進程想像成一個連體嬰兒，共享身體。這是 Linux 操作系統(tǒng)的機制，為了節(jié)約內存資源，所以盡可能讓它們共享起來。在進程分離的一瞬間，內存的增長幾乎沒有明顯變化。

子進程做數(shù)據(jù)持久化，它不會修改現(xiàn)有的內存數(shù)據(jù)結構，它只是對數(shù)據(jù)結構進行遍歷讀取，然后序列化寫到磁盤中。但是父進程不一樣，它必須持續(xù)服務客戶端請求，然后對內存數(shù)據(jù)結構進行不間斷的修改。

這個時候就會使用操作系統(tǒng)的 COW 機制來進行數(shù)據(jù)段頁面的分離。數(shù)據(jù)段是由很多操作系統(tǒng)的頁面組合而成，當父進程對其中一個頁面的數(shù)據(jù)進行修改時，會將被共享的頁面復制一份分離出來，然后對這個復制的頁面進行修改。這時子進程相應的頁面是沒有變化的，還是進程產生時那一瞬間的數(shù)據(jù)。

而這，就是 fork，也就是多進程。

那么我們應該怎么去配置，然后怎么知道這個 默認的持久化方式呢？

RDB 修改持久化

在redis.conf中，可以修改rdb備份文件的名稱，默認為dump.rdb，如下：

圖片

圖片

而存放目錄也是默認為Redis啟動命令所在的目錄

從這里我們能去配置 Redis 的持久化的方式。

接下來我們就得看看怎么能觸發(fā)這個持久化的規(guī)則了。

觸發(fā) RDB 持久化操作

圖片

配置文件我們能看看到。

900秒（15分鐘）后，如果至少有一個按鍵發(fā)生變化。

300秒（5分鐘）后，如果至少有10個按鍵發(fā)生變化

60秒后，如果至少有10000個密鑰發(fā)生更改

而這個 save 就是用來配置備份的規(guī)則的。

其實這個就是相當于是自動備份了，這個配置直接都是使用的默認，或者咱們自己去修改這個 save 的操作。

如果我們想要恢復備份其實很簡單，其實當你重啟的時候，他默認會從咱們剛才看到的 dir 下去恢復，所以，如果你修改了備份的目錄，那么你想恢復備份，那么你就得之前的 dump.rdb 放到 dir 的下面，然后重啟 redis 就可以恢復了。

既然我們了解了這個 RDB 持久化了，那么接下來就得來說說這個 AOF 持久化了。

AOF 持久化

AOF 日志存儲的是 Redis 服務器的順序指令序列，AOF 日志只記錄對內存進行修改的指令記錄。

假設 AOF 日志記錄了自 Redis 實例創(chuàng)建以來所有的修改性指令序列，那么就可以通過對一個空的 Redis 實例順序執(zhí)行所有的指令，也就是「重放」，來恢復 Redis 當前實例的內存數(shù)據(jù)結構的狀態(tài)。

所以按照使用來說，更多的人會選擇 RDB 的持久化。

寫入操作

Redis 在收到客戶端修改命令后，先進行相應的校驗，如果沒問題，就立即將該命令存追加到 .aof 文件中，也就是先存到磁盤中，然后服務器再執(zhí)行命令。這樣就算遇到了突發(fā)的宕機情況情況，也只需將存儲到 .aof 文件中的命令，進行一次“命令重演”就可以恢復到宕機前的狀態(tài)。

也就是說，他是先存磁盤，然后再去執(zhí)行命令。

而 Redis 為了提升寫入效率，它不會將內容直接寫入到磁盤中，而是將其放到一個內存緩存區(qū)（buffer）中等到緩存區(qū)被填滿時采用異步真正將緩存區(qū)中的內容寫入到磁盤里。

所以就有了問題，如果機器突然宕機，AOF 日志內容可能還沒有來得及完全刷到磁盤中，這個時候就會出現(xiàn)日志丟失。

我們都能知道這么淺顯的問題，那么 Redis 一定是可以解決的，解決方案都很粗暴，直接就是配置文件上寫明了。

圖片

• Everysec默認

服務器每一秒調用一次 fsync 函數(shù)，將緩沖區(qū)里面的命令寫入到硬盤。這種模式下，服務器出現(xiàn)故障，最多只丟失一秒鐘內的執(zhí)行的命令數(shù)據(jù)，通常都使用它作為 AOF 配置策略

• Always

服務器每寫入一個命令，就調用一次 fsync函數(shù)，將緩沖區(qū)里面的命令寫入到硬盤。這種模式下，服務器出現(xiàn)故障，也不會丟失任何已經成功執(zhí)行的命令數(shù)據(jù)，但是其執(zhí)行速度較慢

• No

服務器不主動調用 fsync 函數(shù)，由操作系統(tǒng)決定何時將緩沖區(qū)里面的命令寫入到硬盤。這種模式下，服務器遭遇意外停機時，丟失命令的數(shù)量是不確定的，所以這種策略，不確定性較大，不安全。

而我們如果選用了 AOF ，那么在生產環(huán)境的服務器中，Redis 通常是每隔 1s 左右執(zhí)行一次 fsync 操作（ Everysec），這樣既保持了高性能，也讓數(shù)據(jù)盡可能的少丟失。

AOF 配置開啟

AOF默認不開啟，可以在 redis.conf 文件中對AOF進行配置開啟：

appendonly no # 是否開啟AOF，yes：開啟，no：不開啟，默認為no

appendfilename "appendonly.aof" # aof文件名稱，默認為appendonly.aof

dir ./ # aof文件所在目錄，默認./，表示執(zhí)行啟動命令時所在的目錄

AOF 的備份恢復

AOF的備份機制和性能雖然和RDB不同，但是備份和恢復的操作同RDB一樣，都是拷貝備份文件，需要恢復時再拷貝到Redis工作目錄下，啟動系統(tǒng)即加載。

所以關于 Redis 的持久化操作，你學會了么？