從這篇文章開始，我們來介紹Redis高可用相關的機制。Redis要想實現高可用，主要有以下方面來保證：

• 資料持久化
• 主從複製
• 自動故障恢復
• 叢集化

這篇文章我們先介紹Redis的高可用保障的基礎：資料持久化。因為Redis的主從複製和自動故障恢復，都需要依賴Redis持久化相關的東西。同時，Redis的資料持久化也可以用來做資料備份，用來保障資料的安全性。

Redis是一個記憶體資料庫，它的資料都儲存在記憶體中，如果例項宕機，那麼資料則全部丟失。如何保證資料的完整性和安全性也是提高服務高可用的重要機制之一。

Redis提供了完善的持久化機制，可以把記憶體中的資料持久化到磁碟上，方便我們進行備份資料和快速恢復資料。

這篇文章我們就來分析Redis的資料持久化是如何實現的？我們經常聽的RDB和AOF有什麼區別？以及它們不同的使用場景。

持久化方式

Redis提供的資料持久化方式主要有2種：

• RDB：產生一個數據快照檔案
• AOF：實時追加命令的日誌檔案

它們分別對應了不同的使用場景，下面我們就來依次分析。

RDB

RDB全稱Redis Database Backup file（Redis資料備份檔案），也被叫做Redis資料快照。

我們可以通過執行save或bgsave命令讓Redis在本地生成RDB快照檔案，這個RDB檔案包含了整個例項接近完整的資料內容。

它的優點如下：

• RDB檔案資料是被壓縮寫入的，因此RDB檔案的體積要比整個例項記憶體要小
• 當例項宕機恢復時，載入RDB檔案的速度很快，能夠在很短時間內迅速恢復檔案中的資料

它的缺點也很明顯：

• 由於是某一時刻的資料快照，因此它的資料並不全
• 生成RDB檔案的代價是比較大的，它會消耗大量的CPU和記憶體資源

因此RDB比較適用於以下場景：

• 主從全量同步資料
• 資料庫備份
• 對於丟失資料不敏感的業務場景，例項宕機後快速恢復資料

Redis主從全量同步資料就是使用RDB檔案進行的，我們會在後面的文章詳細講到。

由此可以看出，RDB非常適合做資料備份，我們可以定時讓Redis生成RDB檔案，然後備份這個快照檔案即可。

定時生成RDB

Redis也提供了定時觸發生成RDB檔案的配置項：

# 最近15分鐘內 至少產生1次寫入
save 
 
900 1
# 最近5分鐘內 至少產生10次寫入
save 300 10
# 最近1分鐘內 至少產生10000次寫入
save 60 10000

如果達到以上任意條件，則Redis會自動生成新的RDB檔案，降低RDB資料內容與例項資料的差異。

Copy On Write

在Redis上執行save和bgsave命令都可以生成RDB檔案，但前者是在前臺執行的，也就是說在生成RDB檔案時，會阻塞整個例項，在RDB未生成之前，任何請求都是無法處理的，對於記憶體很大的例項，生成RDB檔案非常耗時，顯然這是我們不能接受的。

所以通常我們會選擇執行bgsave讓Redis在後臺生成RDB檔案，這樣Redis依舊可以處理客戶端請求，不會阻塞整個例項。

但不是說後臺生成RDB就是沒有代價的，Redis為了實現後臺把記憶體資料的快照寫入檔案，採用了作業系統提供的Copy On Write技術，也就是我們熟知的fork系統呼叫。

fork系統呼叫會產生一個子程序，它與父程序共享相同的記憶體地址空間，這樣子程序在這一時刻就能擁有與父程序的相同的記憶體資料。

雖然子程序與父程序共享同一塊記憶體地址空間，但在fork子程序時，作業系統需要拷貝父程序的記憶體頁表給子程序，如果整個Redis例項記憶體佔用很大，那麼它的記憶體頁表也會很大，在拷貝時就會比較耗時，同時這個過程會消耗大量的CPU資源。在完成拷貝之前父程序也處於阻塞狀態，無法處理客戶端請求。

fork執行完之後，子程序就可以掃描自身所有的記憶體資料，然後把全部資料寫入到RDB檔案中。

之後父程序依舊處理客戶端的請求，當在處理寫命令時，父程序會重新分配新的記憶體地址空間，從作業系統申請新的記憶體使用，不再與子程序共享，這個過程就是Copy On Write（寫實複製）名字的由來。這樣父子程序的記憶體就會逐漸分離，父程序申請新的記憶體空間並更改記憶體資料，子程序的記憶體資料不受影響。

由此可以看出，在生成RDB檔案時，不僅消耗CPU資源，還有需要佔用最多一倍的記憶體空間。

我們在Redis執行info命令，可以看到fork子程序的耗時，可以通過這個耗時來評估fork時間是否符合預期。同時我們應該保證Redis機器擁有足夠的CPU和記憶體資源，併合理設定生成RDB的時機。

AOF

AOF全稱為Append Only File（追加日誌檔案）。它與RDB不同的是，AOF中記錄的是每一個命令的詳細資訊，包括完整的命令型別、引數等。只要產生寫命令，就會實時寫入到AOF檔案中。

我們可以通過配置檔案開啟AOF：

# 開啟AOF
appendonly yes

# AOF檔名
appendfilename "appendonly.aof"

# 檔案刷盤方式
appendfsync everysec

刷盤方式

開啟AOF後，Redis會把每個寫操作的命令記錄到檔案並持久化到磁碟中，為了保證資料檔案的安全性，Redis還提供了檔案刷盤的時機：

• appendfsync always：每次寫入都刷盤，對效能影響最大，佔用磁碟IO比較高，資料安全性最高
• appendfsync everysec：1秒刷一次盤，對效能影響相對較小，節點宕機時最多丟失1秒的資料
• appendfsync no：按照作業系統的機制刷盤，對效能影響最小，資料安全性低，節點宕機丟失資料取決於作業系統刷盤機制

以上可以看出AOF相對於RDB的優點是，AOF資料檔案更新比較及時，比RDB儲存更完整的資料，這樣在資料恢復時能夠恢復儘量完整的資料，降低丟失資料的風險。

如果同時存在RDB檔案和AOF檔案，Redis會優先使用AOF檔案進行資料恢復。

但它的缺點也很易見：

• 隨著時間增長，AOF檔案會越來越大
• AOF檔案刷盤會增加磁碟IO的負擔，可能影響Redis的效能（開啟每秒刷盤時）

AOF重寫

針對第一種情況，Redis提供了AOF瘦身的功能，可以設定在AOF檔案很大時，自動觸發AOF重寫，Redis會掃描整個例項的資料，重新生成一個AOF檔案達成瘦身的效果。但這個重寫過程也需要消耗大量的CPU資源。

# AOF檔案距離上次檔案增長超過多少百分比則觸發重寫
auto-aof-rewrite-percentage 100
# AOF檔案體積最小多大以上才觸發重寫
auto-aof-rewrite-min-size 64mb

由於AOF可以最大可能降低丟失資料的風險，所以它一般適用於對丟失資料很敏感的業務場景，例如涉及金錢交易的業務。

效能影響

如果AOF的刷盤時機設定為每次寫入都刷盤，那麼會大大降低Redis的寫入效能，因為每次寫命令都需要寫入檔案並刷到磁碟中才會返回，當寫入量很大時，會增加磁碟IO的負擔。

效能與資料安全不能兼得，雖然Redis提供了實時刷盤的機制，但是在真正場景中使用的不多。

通常我們會選擇每秒刷盤這種方式，既能保證良好的寫入效能，在例項宕機時最多丟失1秒的資料，做到效能和安全的平衡。