一文了解 Redis 的持久化

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

Redis 持久化

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

Redis 持久化的兩種方式

RDB（Redis DataBase)
AOF（Append Of File）

什麼是 RDB 呢？

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

那麼什麼是 AOF 呢？

AOF 則是將 redis 執行過的所有寫指令記錄下來，在下次 redis 重新啓動時，只要把這些寫指令從前到後再重複執行一遍，就可以實現數據恢復了。

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

RDB 持久化方式的原理

我們先說實現原理：

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

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

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

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

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

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

RDB 修改持久化

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

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

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

接下來我們就得看看怎麼能觸發這個持久化的規則了。

觸發 RDB 持久化操作

配置文件我們能看看到。

900 秒（15 分鐘）後，如果至少有一個按鍵發生變化。

300 秒（5 分鐘）後，如果至少有 10 個按鍵發生變化

60 秒後，如果至少有 10000 個密鑰發生更改

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

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

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

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

AOF 持久化

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

假設 AOF 日誌記錄了自 Redis 實例創建以來所有的修改性指令序列，那麼就可以通過對一個空的 Redis 實例順序執行所有的指令，也就是「重放」，來恢復 Redis 當前實例的內存數據結構的狀態。

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

寫入操作

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

也就是說，他是先存磁盤，然後再去執行命令。

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

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

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

Everysec 默認

服務器每一秒調用一次 fsync 函數，將緩衝區裏面的命令寫入到硬盤。這種模式下，服務器出現故障，最多隻丟失一秒鐘內的執行的命令數據，通常都使用它作爲 AOF 配置策略

Always

服務器每寫入一個命令，就調用一次 fsync 函數，將緩衝區裏面的命令寫入到硬盤。這種模式下，服務器出現故障，也不會丟失任何已經成功執行的命令數據，但是其執行速度較慢

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

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

AOF 配置開啓

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

appendonly no # 是否開啓AOF，yes：開啓，no：不開啓，默認爲no

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

dir ./ # aof文件所在目錄，默認./，表示執行啓動命令時所在的目錄

AOF 的備份恢復

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

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/7u2DNMbJ2_iwJLlaDslJyw