什麼是Redis的持久化

我們知道Redis的資料都儲存在記憶體中，如果伺服器突然宕機，那麼記憶體資料將會全部消失，為了防止這種情況出現，利用一套機制來保證資料不會因為故障而丟失，我們將這種機制稱之為Redis的持久化機制，該機制主要目的是將記憶體資料存入到硬碟中

Redis 提供兩種持久化機制RDB（Redis DataBase）和AOF（Append-Only File）機制。

RDB-快照

快照是最簡單的Redis持久化模式，也就是生成某個時間點的資料集，生成RDB檔案，可以看到RDB檔案中的資料是非常緊湊的，所以在恢復資料的時候讀取也是非常快的

觸發RDB快照的方式有兩種

手動觸發

通過手動執行bgsave/save，顯示觸發生成快照

• save命令：阻塞當前Redis伺服器，直到RDB過程完成為止，對於記憶體 比較大的例項會造成長時間阻塞，線上環境不建議使用

• bgsave命令：Redis程序執行fork操作建立子程序，RDB持久化過程由子 程序負責，完成後自動結束。阻塞只發生在fork階段，一般時間很短

配置引數自動觸發

自動觸發有以下幾種情況：

• 使用save相關配置，命令save m n。表示m秒內資料集存在n次修改時，自動觸發bgsave
• 從節點執行全量複製操作，主節點自動執行bgsave生成RDB檔案傳送給從節點
• 執行debug reload命令重新載入Redis時，自動觸發save命令
• 執行shutdown命令
  時，如果沒有開啟AOF持久化功能自動執行bgsave

注意：在RDB持久化的過程中有兩個問題需要考慮

1. RDB快照過程中Redis是否會停止對外提供服務
2. 如果沒有停止服務，如何處理新的請求

針對上述問題我們先看一下RDB的持久化執行流程

根據上圖我們可以看到主執行緒主要是fork一個子執行緒來進行持久化操作，同時父子執行緒會共享一個數據區域，而且該區域設定為read-only方式，該方式下讀的時候沒有問題，但是寫的時候會觸發copyonwrite機制來進行，接下來我們看看什麼是 COW(Copy On Write) 機制 。

COW(Copy On Write) 機制

COW(Copy On Write) 機制屬於作業系統處理多程序下的一種機制，Redis在持久化的時候會呼叫glibc

所以持久化的時候是完全交給子程序，而父程序繼續處理客戶端請求，所以在持久化的時候作業系統採用COW機制程序資料段頁面的分離。資料段是由很多作業系統的頁面組合而成，當父程序對其中一個頁面進行資料修改的時候，先將被父子執行緒共享的這一個頁面複製並分離出來，然後直接對複製的頁面程序修改，而此時子程序對應的頁面是沒有修改的。

Redis採用該機制的簡單流程如下。Lunix在fork之後，作業系統會將父程序的所有記憶體也許可權設定為read-only，然後子程序的地址空間指向父程序。當父程序只讀時沒有問題，當有寫記憶體時，CPU硬體檢測到記憶體也是read-only，於是會觸發頁異常中斷（page-fault），陷入到作業系統的一箇中斷例程。中斷例程中，作業系統採用cow機制會觸發異常的也複製一份，於是父子程序各自持有獨立的一份，如果這個時候又大量寫入操作，會產生大量的分頁錯誤（頁異常中斷page-fault），從而觸發cow機制。

之所以稱之為快照也就是說在子程序建立的那一時刻開始。記憶體的資料就固定下來了，不會發生變化。

RDB的優缺點

優點：

1. 效能最大化，fork子程序來完成寫操作，讓主程序繼續處理命令，保證了redis的高效能
2. 重啟恢復資料的時候。資料量比較大時候，Redis直接解析RDB二進位制檔案，生成對應的資料儲存在記憶體中，比AOF的啟動效率更高

缺點

1. 資料安全性低，因為是間隔一段時間進行持久化，如果在持久化之間發生了故障，會丟失資料，這也就決定了該方式更適合在資料要求不嚴謹的時候採用
2. 系統性能耗費，根據上文提到的Redis執行cow機制時，可以看到大量的分頁錯誤會耗費不少效能在複製上。

AOF（Append Only File - 僅追加檔案）

根據上文，快照在某些情況下不是可行的選擇，所以AOF很好的支援了。

AOF 原理

該方式非常簡單：也就是修改記憶體的操作命令都會記錄下來，加入AOF日誌記錄都是Redis例項建立以來的所有修改性指令序列，所以恢復也就是順序執行所有執行。

Redis使用單執行緒相應命令，如果每次寫AOF檔案命令都追加到硬碟，會極大地影響處理效能，所以Redis會先寫入到aof緩衝區，根據使用者配置的同步硬碟策略寫入到aof檔案中，這個策略可以通過appendfsync引數配置，

• always：每一次寫操作都會呼叫一次fsync，這時資料是最安全的，當然，由於每次都會執行fsync，所以其效能也會受到影響
• no：Redis不會主動呼叫fsync去將AOF日誌內容同步到磁碟，所以這一切就完全依賴於作業系統的除錯了。對大多數Linux作業系統，是每30秒進行一次fsync，將緩衝區中的資料寫到磁碟上。
• everysec：Redis會預設每隔一秒進行一次fsync呼叫，將緩衝區中的資料寫到磁碟。但是當這一次的fsync呼叫時長超過1秒時。Redis會採取延遲fsync的策略，再等一秒鐘。也就是在兩秒後再進行fsync，這一次的fsync就不管會執行多長時間都會進行。這時候由於在fsync時檔案描述符會被阻塞，所以當前的寫操作就會阻塞。

注意，這也是影響Redis效能的引數之一，建議採用 appendfsync everysec（預設方式）

AOF重寫

所謂重寫，Redis在長期執行過程中日誌會越來越大，在恢復的時候會非常好使，所以我們的目的就是對日誌做瘦身

會從以下幾點做瘦身：

1. 無效命令可以刪除，比如del key1、hdel key2、srem keys、set a111、set a222等，直接用最終的資料生成命令儲存下來就行
2. 多條命令可以刪除，如：lpush list a、lpush list b、lpush list c可以轉化為：lpush list a b c
3. 等等，就不列舉了

Redis使用bgrewriteaof指令做瘦身，主要也是開闢一個子程序對記憶體遍歷轉化為一系列指令，並序列化到新的檔案中，接下來再將操作期間的增量AOF日誌追加到新的日誌檔案中，最終替換了舊的。

AOF重寫機制兩種方式觸發

1. 手動觸發：bgrewriteaof指令
2. 自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage引數確定自動觸發時機

• auto-aof-rewrite-min-size：表示執行AOF重寫時檔案最小體積，預設為64MB。

• auto-aof-rewrite-percentage：代表當前AOF檔案空間 （aof_current_size）和上一次重寫後AOF檔案空間（aof_base_size）的比值。

auto-aof-rewrite-min-size????100auto-aof-rewrite-percentage??64mb複製程式碼

如上代表AOF檔案的大小小於64mb(預設值)，且當前AOF檔案大小比基準大小增長了100%時會觸發。

AOF優缺點

優點

資料安全，aof持久化配置appendfsync屬性，有always，每執行一次命令操作就記錄到aof檔案一次

缺點

資料集大的時候，比如RDB啟動效率低

混合持久化（Redis 4.0版本）

我們根據上文知道，RDB恢復會存在大量資料，AOF恢復效能又較慢，所以在Redis4.0中，採用混合持久化，將RDB檔案記憶體和增量的AOF日誌檔案放在一起，這裡的AOF日誌不再是全量日誌。而是自持久化開始到持久化結束的這段時間的增量日誌，通常較小，重啟效率因此大幅得到提升

載入的時候，首先會識別AOF檔案是否以REDIS字串開頭，如果是就按照RDB格式載入，載入完成後繼續按AOF載入剩餘的部分

總結

在清楚了各個大廠的面試重點之後，就能很好的提高你刷題以及面試準備的效率，接下來小編也為大家準備了最新的網際網路大廠資料。

資料領取：點我即可免費領取