Redis持久化機制

博客地址：https://tech101.cn/2020/03/05/Redis%E6%8C%81%E4%B9%85%E5%8C%96%E6%9C%BA%E5%88%B6

前言

Redis是一款純C語言撰寫的符合ANSI C標準實作的記憶體資料庫，Redis以支持豐富的記憶體資料結構和高性能著稱，在互聯網行業中被廣泛用于快取資料和記憶體計算，

雖然Redis是一款記憶體資料庫，但是它也提供了資料持久化的能力，本文，我們就來聊聊Redis的資料持久化機制，

持久化面臨的問題

在正式開始介紹Redis持久化功能之前，我們先來看下實作持久化能力需要面臨的一些技術問題，

當客戶端請求Redis服務端將資料寫入Redis資料庫的時候，資料將被存放在記憶體中，如果Redis資料庫啟用了持久化功能，那么資料將被持久化到持久化設備（磁盤）上，從客戶端請求服務端寫入資料到資料被持久化到磁盤上，整個程序需要經歷如下幾個階段¹：

1. 客戶端向服務端發起寫命令，
2. 服務端接收到客戶端請求，執行寫命令將資料寫入記憶體，
3. 服務端呼叫write()系統呼叫（Unix環境）將記憶體中的資料寫入內核緩沖區，
4. 呼叫fsync()將內核緩沖區的資料寫入磁盤控制器的快取中，
5. 磁盤控制器將快取中的資料寫入到磁盤的物理介質上，

在上面列出的5個步驟中，第1步到第3步資料都在記憶體中存放，一旦服務crash，那么資料將永久性的丟失了，在第4步和第5步中，資料已經從記憶體轉移到了磁盤設備上，不過在第4步中資料是被寫入到了磁盤的控制器緩沖區（為了解決磁盤設備和記憶體設備訪問延遲的差異，通過緩沖區技術來提高單位時間內設備的吞吐量）中，所以一旦服務器掉電宕機，在快取中的這部分資料也可能將會丟失（取決于物理存盤設備），只有當資料經過第5步被寫入磁盤物理介質以后，資料才算真正地被保存了下來，不會因為服務器掉電而丟失資料，

從上面的程序中我們可以發現，為了保證資料持久化程序的順利，我們只有成功地將上面第1到5步這五個步驟同步執行完成以后，資料才算安全的被持久化下來，其中任意一步出現問題，資料都可能存在丟失的風險，

當然，要想完全的執行完上面的五個步驟是很理想的情況，實際在實作持久化機制的時候，將會面臨一些現實的約束，首先，完成上述五個步驟涉及到Redis服務、作業系統以及底層存盤硬體的緊密配合，對于作業系統之上的Redis服務實作者來說，要實作持久化功能，只能通過呼叫作業系統提供的功能（系統呼叫System call）來完成對底層存盤硬體的訪問，所以實作者能控制的只有上述的第1-4這四步，至于最后一步則可能不受Redis服務的實作者控制，由各個硬體設備自己實作（至少不能保證能提供對應的內核驅動API供作業系統訪問），所以在持久化這件事上，實作者能做的是保證第1-4步能順利完成，

其次，第3步和第4步都需要呼叫系統呼叫，呼叫系統呼叫會導致行程用戶態和內核態的切換，這個程序是有性能損失的，頻繁的呼叫系統呼叫將會降低服務的性能，而Redis作為一款高性能的記憶體資料庫，服務的性能也是需要重點考慮的一個指標，所以為了平衡好資料安全性和性能，在實作持久化機制的時候需要作出取舍，

Redis的實作者在實作持久化的時候，為了兼顧性能和資料安全性，引入了兩種持久化方案：

1. RDB持久化
2. AOF持久化

下面，我們將介紹這兩種持久化方案，

RDB持久化

RDB持久化是Redis引入的一種資料安全性相對弱的持久化方案，通過異步將記憶體資料庫的快照寫入持久化檔案來實作資料的持久化，由于生成快照是異步進行的，所以快照不會實時反應記憶體中的資料庫情況，因此它是一種資料安全性較弱的資料持久化方案，不過由于創建快照程序是異步進行的，在創建快照程序中基本不會對記憶體資料庫的操作產生影響，所以RDB持久化方案是一種注重性能，但是在資料安全性方面做出妥協的持久化方案，

下面，我們來看下RDB持久化的實作原理，

生成RDB快照

Redis提供了兩個命令：SAVE和BGSAVE來創建RDB快照檔案，這兩個命令的最大區別是：SAVE命令在生成RDB檔案的時候會阻塞Redis的行程；而BGSAVE會創建一個子行程來生成RDB檔案，不會阻塞服務器的行程，

127.0.0.1:6379> SAVE
OK

127.0.0.1:6379> BGSAVE
Background saving started

由于SAVE命令是通過阻塞服務器的行程來進行快照生成的，所以在生成快照期間服務器將拒絕來自服務器外部的請求，而BGSAVE命令通過創建子行程實作快照的生成，所以在生成快照期間Redis服務可以繼續執行客戶端的請求，不過需要注意的一點是：在BGSAVE命令執行期間，BGSAVE、SAVE、BGREWRITEAOF命令的執行將會受到限制，

首先，在BGSAVE命令執行期間，SAVE命令會被拒絕執行；其次，在BGSAVE命令執行完成前，新的BGSAVE命令也會被拒絕執行；最后，對于AOF重新命令BGREWRITEAOF，在BGSAVE命令執行期間，該命令將會被延后執行，同時，如果在BGSAVE命令執行之前有BGREWRITEAOF命令正在執行，則BGSAVE命令也需要等到AOF重新命令完成以后才能被執行，這么做是考慮到持久化是一個消耗IO資源的操作，雖然BGSAVE和BGREWRITEAOF兩個命令都是通過創建子行程來執行的，但是出于服務器性能的考慮，這兩個命令不能同時執行，

定時生成快照

除了通過命令生成RDB快照以外，Redis也支持定時生成快照的功能，通過在Redis組態檔中設定快照生成配置，服務器可以在運行程序中自動生成RDB快照，自動生成快照和BGSAVE命令執行的效果類似，也是通過創建子行程的方式生成RDB快照檔案，

用戶可以通過在組態檔中設定save選項的值來控制自動生成快照的頻率，如果存在多個save選項配置，則任意一個配置滿足條件都會觸發生成RDB快照，

save 900 1
save 300 10
save 60 10000

上述配置的三個條件，只要滿足下面任意一個條件，快照就會被創建：

1. 服務器在900秒內，記憶體資料庫發生了至少1次修改，
2. 服務器在300秒內，記憶體資料庫發生了至少10次修改，
3. 服務器在60秒內，記憶體資料庫發送了至少10000次修改，

載入RDB快照

當Redis服務器啟動的時候如果發現存在RDB快照檔案，則會進行RDB快照檔案的載入，在RDB快照載入期間，Redis服務將會處于阻塞狀態，直到快照載入完成，

1:M 12 Apr 2020 07:29:28.289 # Server initialized
1:M 12 Apr 2020 07:29:28.291 * DB loaded from disk: 0.001 seconds
...

RDB檔案結構

通過RDB持久化創建的快照檔案是一個由5部分組成的二進制檔案，

1. redis快照檔案以REDIS字串開頭，占用5個位元組（C語言中一個char型別占據1個位元組），用于在載入的時候檢查檔案是否是RDB快照檔案，
2. db_version的長度為4個位元組，是一個字串表示的整數，記錄了RDB檔案的版本號，
3. databases是一個變長的欄位，存放了Redis服務中的資料庫資料，如果Redis資料庫為空，則這個欄位的長度為0，
4. EOF是長度為1個位元組的常量，用于標識RDB檔案正文內容的結束，
5. check_sum是一個長度為8個位元組的無符號整數，保存了前四部分的校驗和，用于在載入RDB檔案的時候進行檔案完整性檢查，

關于RDB檔案格式的詳細細節可以參考《Redis設計與實作》一書，作者對RDB檔案格式做了詳盡的介紹，

優缺點

優點

1. 生成RDB快照檔案的程序是異步的，所以在持久化程序中對服務器性能影響小，
2. RDB檔案存盤的是記憶體資料庫的快照，采用緊湊的二進制檔案存盤，通過RDB檔案進行資料庫恢復的時候速度快，

缺點

1. 由于RDB檔案是異步進行備份的，所以存在資料安全性弱的弊端：當系統發生故障導致記憶體資料庫資料丟失的時候，從RDB檔案中只能恢復創建RDB快照那一刻的資料，在最近一次創建RDB快照那一刻到服務器宕機之間的資料將永久性的丟失了，資料恢復的完整程度依賴于RDB快照創建的頻率，
2. 由于RDB快照是將整個記憶體資料庫備份下來，所以當記憶體資料庫很大的時候創建RDB檔案需要耗費更久的時間，

AOF持久化

鑒于RDB持久化方案存在的一些問題，Redis提供了另外一種持久化機制：AOF（Append Only File）持久化功能，

不同于RDB持久化方案通過創建快照檔案來持久化資料，AOF持久化方案通過持久化發送到Redis服務器的寫命令來實作持久化功能，AOF持久化機制會把所有引起記憶體資料庫資料變化的寫命令都保存下來，通過檔案追加（Append）的方式保存到AOF檔案中，在通過AOF檔案進行資料恢復的時候我們可以通過重放AOF檔案中的命令來恢復出Redis記憶體資料庫的內容，這就是AOF機制能進行持久化的原理，

AOF持久化方案通過犧牲一定的性能來換取資料的安全性，以滿足對資料安全性要求較高的場景，

創建AOF檔案

當Redis服務器啟用了AOF持久化選項以后，服務器會將接收到的寫命令以追加的方式寫入服務器的AOF緩沖區，然后由服務器按照不同的AOF持久化選項以不同的策略將緩沖區的命令寫入AOF檔案，

AOF持久化選項

以追加方式進行檔案寫入本質上是一種順序訪問磁盤的方式，對于磁盤這種存盤介質來說，順序訪問比隨機訪問的性能會高很多，所以追加方式寫入磁盤對服務的性能影響較小，但是這種性能的消耗在有些場景下可能是不能接受的，所以為了兼顧資料安全性和性能，Redis的AOF持久化方案提供了一些持久化選項，

Redis通過設定appendfsync選項來控制持久化的資料安全程度，該引數提供了三個可選的AOF持久化選項值：always、everysec、no，分別對應不同的資料安全級別，

注意：如果appendfsync選項的值沒有配置，則默認值為everysec，

我們在第一節中討論持久化面臨的問題的時候，提到服務器能控制的持久化步驟為第1-4步，其中第4步通過fsync()命令將內核緩沖區中的資料重繪到磁盤中（Linux環境），Linux環境下的Redis服務器就是通過該系統呼叫來實作appendfsync的不同持久化選項的，

由于每次進行fsync()系統呼叫相對比較耗時，所以AOF持久化方案提供了上述三種選項供開發者選擇，以滿足對資料安全性要求不同的使用場景，

如果appendfsync選項的值被配置為always，那么資料安全性最高，但是服務的性能會受到影響；如果選項值設定為no，那么資料安全性的保證相對較弱，但是服務器的性能有所提高；而everysec則是這兩種場景的一個折中，

從AOF檔案恢復

和RDB快照檔案直接包含資料庫狀態不同，AOF檔案包含了Redis服務器收到的所有寫命令，所以當服務器從AOF檔案恢復資料庫的時候，需要對AOF檔案中的所有命令按序進行重放來還原出資料庫狀態，

在Redis服務器通過AOF檔案恢復資料庫的時候，為AOF檔案創建一個偽客戶端，然后通過這個偽客戶端來執行AOF檔案中的命令，以此來重建資料庫，

重寫AOF檔案

由于AOF檔案恢復需要重放AOF檔案中的所有命令，所以資料庫的恢復時間和AOF檔案的大小成正比，當AOF檔案很大的時候恢復程序需要耗費很長一段時間才能完成，而RDB由于存盤的是快照，所以沒有這方面的困擾，不過RDB快斬訓復的速度和資料庫的大小正相關，

Redis為了解決AOF檔案太大的情況，提供了AOF檔案重寫的功能，通過對AOF檔案進行重寫，將一些命令進行合并來達到縮減AOF檔案的目的，最終實作減少AOF檔案恢復時間的目的，

比如，通過對下面的這幾個命令進行重寫，產生一個重寫后的命令來達到和重寫前同樣的效果：

# 重寫前
PUSH list "A"
PUSH list "B"

# 重寫后
PUSH list "A" "B"

Redis提供了BGREWRITEAOF命令進行AOF重寫操作，BGREWRITEAOF命令是一個后臺執行的命令，通過創建一個子行程來完成AOF檔案重寫作業，

重寫程序

在AOF檔案重寫程序中Redis服務器還可以繼續處理請求，所以AOF檔案會繼續追加命令，如果不對AOF重寫和命令追加進行協調，那么將導致AOF檔案資料不一致的情況，

為了解決這個問題，Redis服務器會在AOF檔案重寫開始以后創建一個AOF重寫緩沖區，當服務器接收到寫命令以后，會同步將這個命令寫入AOF重寫緩沖區和原先的AOF追加緩沖區，這保證了在AOF重寫期間，Redis服務器可以繼續進行AOF持久化，而且新接受到的命令也會被記錄到AOF重寫緩沖區中，

當處理AOF重寫的子行程完成AOF重寫作業以后，會通過信號機制通知父行程（服務器行程），父行程接收到信號以后會執行如下兩步操作：

1. 服務器行程會將AOF重寫緩沖區中的命令寫入重寫后的新AOF檔案中，
2. 服務器會原子的將AOF檔案修改為重寫后的AOF檔案，完成新舊AOF檔案的替換，

優缺點

優點

1. 資料的安全性更高，當服務crash以后丟失的資料更少，
2. AOF檔案的可讀性更好，
3. 通過append方式追加命令，訪問磁盤的效率高，

缺點

1. 由于AOF持久化會在一定程度上進行磁盤同步處理操作，這個程序是阻塞的（雖然很短），所以對服務器處理命令的性能會產生影響，
2. AOF檔案記錄的是寫命令，恢復的時候需要重放命令來得到記憶體資料庫的狀態，即使有AOF重寫機制，恢復速度上和RDB相比也會有差距，

從RDB持久化轉換成AOF持久化

在調整持久化方案的時候，Redis在不同版本有不同的操作方式，在Redis 2.2以后的版本中可以在不停機的情況下修改持久化方案，通過如下步驟進行操作：

1. 創建最近的RDB檔案的備份，
2. 將備份保存在安全的位置，
3. 發起如下命令：
   • 客戶端執行 config set appendonly yes啟用AOF持久化，
   • 客戶端執行 config set save “”關閉RDB持久化，
4. 確認資料庫包含相同的keys，
5. 確認write操作被正確追加到了AOF檔案，
6. 修改redis.conf檔案，保證下次重啟的時候也是正確的持久化配置，

同時使用AOF持久化和RDB持久化

在AOF和RDB兩個持久化方案都啟動的情況下，除了RDB的快照命令SAVE會阻塞行程導致其他命令都不能被執行之外，BGSAVE和BGREWRITEAOF命令都是在子行程中異步執行的，不會影響到服務器行程的正常執行，不過考慮到持久化操作會占用磁盤IO資源，對機器的IO性能會產生影響，Redis對BGSAVE和BGREWRITEAOF命令的執行做了限制：同一時刻服務中只能執行一個命令，

同樣，在AOF和RDB這兩個持久化方案都啟用的情況下恢復資料的時候，由于AOF檔案的資料安全性（完整性）更高，Redis在啟動的時候會優先采用AOF檔案恢復的方式重建資料庫，只有當AOF功能關閉的情況下才會使用RDB進行資料重建，

總結

在本文中，我們介紹了Redis的兩種持久化方案，分析了兩種方案各自的實作原理和優缺點，

標籤：其他

上一篇：qt creator原始碼全方面分析(4)

下一篇：實施Cisco統一通信VoIP和QoS下載