與時俱進，深入原理學習——Redis 4.0新持久化機制：混合持久化

眾所周知，Redis是一個內存數據庫。但它與其它內存數據庫（如memcache）等有一個很大的區別，就是Redis可以持久化到磁盤。有了持久化方案，Redis就可以對數據進行備份、恢復、複製。

Redis提供了兩種持久化方案：RDB和AOF。在Redis 4.0中，提供了一個新特性：兩者的混合持久化。下面將介紹Redis的各種持久化方案的原理和配置。

使用info persistence命令可以查看當前所有有關持久化的信息：

RDB

原理

RDB持久化是通過快照方式來完成的。當達到觸發條件時，Redis會自動將內存中所有數據以二進制方式生成一份副本並存儲在硬盤上。

在配置文件可以配置當前配置的備份文件和目錄，使用config命令也可以查看和設置：

觸發條件

RDB分為主動觸發和被動觸發。

主動觸發指的是客戶端執行save和bgsave命令會進行持久化。

執行save會使Redis處於阻塞狀態，不會響應任何其他客戶端發來的請求，直到RDB快照文件執行完畢，需要謹慎使用。

bgsave即background save，後臺保存。當執行bgsave命令時，Redis會fork出一個子進程來執行快照操作。需要注意的是，在fork子進程的過程中，Redis是阻塞的。而當子進程創建完成後，Redis就可以繼續響應客戶端的請求了。

子進程創建完成以後，返回“Background saving started”。子進程根據主進程的內存副本創建臨時快照文件，當快照文件完成以後對原快照文件進行替換。替換完成後，子進程發送信號給主進程完成快照操作，主進程更新統計信息（info Persistence可查看），子進程退出。

被動觸發有好幾種情況，下面分別介紹一下。

save m n規則觸發

在指定的m秒內，Redis中有n個鍵發生改變，則自動觸發bgsave。該規則默認在redis.conf中進行了配置，並且可組合使用，滿足其中一個規則，則觸發bgsave

比如save 900 1，表明當900秒內至少有1個鍵發生改變時候，Redis會觸發bgsave操作。

flushall觸發

flushall命令用於清空數據庫，請慎用，當我們使用了則表明我們需要對數據進行清空，那Redis當然需要對快照文件也進行清空，所以會觸發bgsave。

shutdown觸發

Redis在關閉前處於安全角度將所有數據全部保存下來，以便下次啟動會恢復。可以使用客戶端連入執行shutdown命令，也可以直接使用腳本關閉Redis，都會在退出前先執行save。

shutdown命令還可以傳遞一個參數save/nosave。如果使用nosave參數，則不會進行持久化，直接退出。

主從複製觸發

在Redis主從複製中，從節點執行全量複製操作，主節點會執行bgsave命令，並將rdb文件發送給從節點。

數據恢復

當Redis意外崩潰或者關閉再次啟動時，此時AOF持久化未開啟時(默認未開啟)，將使用RDB快照文件恢復數據。關掉Redis服務再重啟，會發現日誌裡面有：

DB loaded from disk

配置

AOF

默認情況下，Redis是關閉了AOF持久化，開啟AOF通過配置appendonly為yes開啟，我們修改配置文件或者在命令行直接使用config set修改，在用config rewrite同步到配置文件。通過客戶端修改好處是不用重啟Redis，AOF持久化直接生效。

原理

如果說RDB相當於數據庫的定時備份（冷備），那AOF就相當於數據庫的熱備。

通過前面的介紹會發現，如果使用RDB，在意外情況下，比如Redis服務突然宕機，這個時候有些內存裡面的數據還沒來得及刷新進磁盤，就會導致一部分數據丟失。

AOF就是用來解決這個問題的。AOF是Append Only File的縮寫，AOF可以將Redis執行的每一條寫命令追加到磁盤文件中，在Redis啟動時候優先選擇從AOF文件恢復數據。

因為每一次寫操作，都需要記錄到文件中，所以開啟AOF持久化會對性能有一定的影響，但是大部分情況下這個影響是可以接受的，我們可以使用讀寫速率高的硬盤提高AOF性能。與RDB持久化相比，AOF持久化數據丟失更少，其消耗內存更少(RDB方式執行bgsve會有內存拷貝)。

AOF實現本質是基於Redis通訊協議，將命令以純文本的方式寫入到文件中。

redis協議：

首先Redis是以行來劃分，每行以\\r\\n行結束。每一行都有一個消息頭，消息頭共分為5種分別如下:

+表示一個正確的狀態信息，具體信息是當前行後面的字符。

-表示一個錯誤信息，具體信息是當前行後面的字符。

*表示消息體總共有多少行，不包括當前行,後面是具體的行數。

$表示下一行數據長度，不包括換行符長度\\r\\n,後面則是對應的長度的數據。

: 表示返回一個數值，後面是相應的數的字節符。

Redis AOF持久化過程

1 追加寫入

Redis將每一條寫命令以Redis通訊協議添加至緩衝區aof_buf,這樣的好處在於在大量寫請求情況下，採用緩衝區暫存一部分命令隨後根據策略一次性寫入磁盤，這樣可以減少磁盤的I/O次數，提高性能。

2 同步命令到硬盤

當寫命令寫入aof_buf緩衝區後，Redis會將緩衝區的命令寫入到文件，Redis提供了三種同步策略，由配置參數appendfsync決定，下面是每個策略所對應的含義：

• no：不使用fsync方法同步，而是交給操作系統write函數去執行同步操作，在linux操作系統中大約每30秒刷一次緩衝。
• always：表示每次有寫操作都調用fsync方法強制內核將數據寫入到aof文件。
• everysec：數據將使用調用操作系統write寫入文件，並使用fsync每秒一次從內核刷新到磁盤。這是折中的方案，兼顧性能和數據安全，所以Redis默認推薦使用該配置。

3 文件重寫(bgrewriteaof)

當開啟的AOF時，隨著時間推移，AOF文件會越來越大,當然Redis也對AOF文件進行了優化，即觸發AOF文件重寫條件的時候，Redis將使用bgrewriteaof對AOF文件進行重寫。這樣的好處在於減少AOF文件大小，同時有利於數據的恢復。重寫策略：

• 重複或無效的命令不寫入文件
• 過期的數據不再寫入文件
• 多條命令合併寫入（當多個命令能合併一條命令時候會對其優化合並作為一個命令寫入，例如“RPUSH list1 a; RPUSH list1 b" 合併為“RPUSH list1 a b” ）

重寫

AOF文件重寫過程與RDB快照bgsave工作過程有點相似，都是通過fork子進程，由子進程完成相應的操作，同樣的在fork子進程簡短的時間內，Redis是阻塞的，過程如圖：

過程說明：

1.開始bgrewriteaof，判斷當前有沒有bgsave命令(RDB持久化)/bgrewriteaof在執行，倘若有，則這些命令執行完成以後再執行。

2.主進程fork出子進程，在這一個短暫的時間內，redis是阻塞的。

3.主進程fork完子進程繼續接受客戶端請求，所有寫命令依然寫入AOF文件緩衝區並根據appendfsync策略同步到磁盤，保證原有AOF文件完整和正確。由於fork的子進程僅僅只共享主進程fork時的內存，因此Redis使用採用重寫緩衝區(aof_rewrite_buf)機制保存fork之後的客戶端的寫請求，防止新AOF文件生成期間丟失這部分數據。此時，客戶端的寫請求不僅僅寫入原來aof_buf緩衝，還寫入重寫緩衝區(aof_rewrite_buf)。

4.子進程通過內存快照，按照命令重寫策略寫入到新的AOF文件。

4.1子進程寫完新的AOF文件後，向主進程發信號，父進程更新統計信息。

4.2主進程把aof_rewrite_buf中的數據寫入到新的AOF文件。

5.使用新的AOF文件覆蓋舊的AOF文件，標誌AOF重寫完成。

重寫的觸發條件：

AOF文件觸發條件可分為手動觸發和自動觸發。

手動觸發：客戶端執行bgrewriteaof命令。

自動觸發：自動觸發通過以下兩個配置協作生效：

• auto-aof-rewrite-min-size: AOF文件最小重寫大小，只有當AOF文件大小大於該值時候才可能重寫，4.0默認配置64mb。
• auto-aof-rewrite-percentage：當前AOF文件大小和最後一次重寫後的大小之間的比率等於或者等於指定的增長百分比，如100代表當前AOF文件是上次重寫的兩倍時候才重寫。

Redis開啟在AOF功能開啟的情況下，會維持以下三個變量

• 記錄當前AOF文件大小的變量aof_current_size。
• 記錄最後一次AOF重寫之後，AOF文件大小的變量aof_rewrite_base_size。
• 增長百分比變量aof_rewrite_perc。

每次當serverCron（服務器週期性操作函數）函數執行時，它會檢查以下條件是否全部滿足，如果全部滿足的話，就觸發自動的AOF重寫操作：

• 沒有BGSAVE命令（RDB持久化）/AOF持久化在執行；
• 沒有BGREWRITEAOF在進行；
• 當前AOF文件大小要大於server.aof_rewrite_min_size的值；
• 當前AOF文件大小和最後一次重寫後的大小之間的比率等於或者大於指定的增長百分比（auto-aof-rewrite-percentage參數）

數據恢復

當AOF開啟時候，Redis數據恢復優先選用AOF進行數據恢復。關掉Redis服務再重啟，會發現日誌裡面有：

DB loaded from append only file

配置

RDB與AOF對比

RDB的優點：

RDB文件體積小，因此在傳輸速度上較快，適合災難恢復。RDB使Redis性能更高，子進程處理保存工作。在恢復大數據集時比AOF恢復速度快。

AOF的優點：

數據更完整和安全，秒級數據丟失（取決於appendfsync策略）。兼容性高，因為是基於Redis通訊協議形成的明文文件，所以容易閱讀，且任何版本的Redis都兼容。

混合持久化

混合持久化是Redis 4.0才有的功能。

混合持久化同樣也是通過bgrewriteaof完成的，不同的是當開啟混合持久化時，fork出的子進程先將共享的內存副本以RDB方式寫入AOF文件，然後在將重寫緩衝區的增量命令以AOF方式寫入到文件，寫入完成後通知主進程更新統計信息，並將新的AOF文件替換舊的的AOF文件。

簡單的說：新的AOF文件前半段是RDB格式的全量數據，後半段是AOF格式的增量數據。

數據恢復

使用混合持久化後，Redis依然優先加載AOF文件。可能有兩種情況：

• AOF文件開頭是RDB的格式，先加載RDB部分的內容，再加載剩餘的AOF
• AOF文件開頭不是RDB的格式，直接加載整個AOF文件

配置

4.0版本的混合持久化默認關閉的，通過aof-use-rdb-preamble配置參數控制，yes則表示開啟，no表示禁用，默認是no，可通過config set修改。

混合模式可以結合AOF和RDB的優點，能夠快速加載的同時避免丟失過多的數據。