目錄

• 為什麼要將redis持久化
• redis 如何持久化
  • redis持久化的方式有兩種
  • 兩種持久化方式的區別
  • RDB持久化
    • 觸發條件
      • 手動觸發
      • 自動觸發
      • 其他自動觸發機制
    • 執行流程
    • RDB檔案
    • 啟動時載入
    • RDB的優勢
    • RDB的劣勢
  • AOF持久化
    • 開啟AOF
    • 執行流程
    • 啟動時載入
    • 檔案校驗
    • 偽客戶端
    • AOF的優勢
    • AOF的劣勢
  • 兩種方式的常用配置
    • RDB持久化配置
    • AOF持久化配置
  • RDB 模式和 AOF 模式的恢復

為什麼要將redis持久化

Redis是記憶體資料庫，資料都是儲存在記憶體中，為了避免程序退出導致資料的永久丟失，需要定期將Redis中的資料以某種形式(資料或命令)從記憶體儲存到硬碟；當下次Redis重啟時，利用持久化檔案實現資料恢復。除此之外，為了進行災難備份，可以將持久化檔案拷貝到一個遠端位置。

redis 如何持久化

redis持久化的方式有兩種

• RDB持久化：將 Redis 在記憶體中的資料庫記錄定時 dump 到磁碟上的 RDB 持久化
• AOF持久化：將 Rdis 的操作日誌以追加的方式寫入到一個檔案中。

由於AOF持久化的實時性更好，即當程序意外退出時丟失的資料更少，因此AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地。

兩種持久化方式的區別

RDB持久化是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟，實際操作過程是fork一個子程序，先將資料集寫入臨時檔案，寫入成功後，再替換之前的檔案，用二進位制壓縮儲存。

AOF持久化以日誌的形式記錄伺服器所處理的每一個寫、刪除操作，查詢操作不會記錄，以文字的方式記錄，可以開啟檔案看到詳細的操作記錄。

RDB持久化

RDB持久化是將當前程序中的資料生成快照儲存到硬碟(因此也稱作快照持久化)，儲存的檔案字尾是rdb；當Redis重新啟動時，可以讀取快照檔案恢復資料。

觸發條件

RDB持久化的觸發分為手動觸發和自動觸發兩種。

手動觸發

save 命令和 bgsave 命令都可以生成 RDB 檔案

• savee 命令會阻塞Redis伺服器程序，直到RDB檔案建立完畢為止，在Redis伺服器阻塞期間，伺服器不能處理任何命令請求。

• bgsave命令會建立一個子程序，由子程序來負責建立RDB檔案，父程序(即Redis主程序)則繼續處理請求。

bgsave命令執行過程中，只有fork子程序時會阻塞伺服器，而對於save命令，整個過程都會阻塞伺服器，因此save已基本被廢棄，線上環境要杜絕save的使用；在自動觸發RDB持久化時，Redis也會選擇bgsave而不是save來進行持久化

自動觸發

觸發命令：

save m n 

自動觸發最常見的情況是在配置檔案中通過save m n，指定當m秒內發生n次變化時，會觸發bgsave。

下文中介紹的有 redis 的配置檔案(一般在redis根目錄下的 redis.conf)中相關的設定。

save m n 的實現原理

Redis的save m n，是通過serverCron函式、dirty計數器、和lastsave時間戳來實現的。

• serverCron是Redis伺服器的週期性操作函式，預設每隔100ms執行一次；該函式對伺服器的狀態進行維護，其中一項工作就是檢查 save m n 配置的條件是否滿足，

• dirty計數器是Redis伺服器維持的一個狀態，記錄了上一次執行bgsave/save命令後，伺服器狀態進行了多少次修改(包括增刪改)；而當save/bgsave執行完成後，會將dirty重新置為0。

  例如，如果Redis執行了set mykey helloworld，則dirty值會+1；如果執行了sadd myset v1 v2 v3，則dirty值會+3；注意dirty記錄的是伺服器進行了多少次修改，而不是客戶端執行了多少修改資料的命令。

• lastsave時間戳也是Redis伺服器維持的一個狀態，記錄的是上一次成功執行save/bgsave的時間。

save m n的原理如下：每隔100ms，執行serverCron函式；在serverCron函式中，遍歷save m n配置的儲存條件，只要有一個條件滿足，就進行bgsave。對於每一個save m n條件，只有下面兩條同時滿足時才算滿足：

（1）當前時間-lastsave > m

（2）dirty >= n

其他自動觸發機制

除了save m n 以外，還有一些其他情況會觸發bgsave：

• 在主從複製場景下，如果從節點執行全量複製操作，則主節點會執行bgsave命令，並將rdb檔案傳送給從節點
• 執行shutdown命令時，自動執行rdb持久化

執行流程

前面介紹了觸發bgsave的條件，下面將說明bgsave命令的執行流程，如下圖所示

圖片中的5個步驟所進行的操作如下：

1. Redis父程序首先判斷：當前是否在執行save，或bgsave/bgrewriteaof（後面會詳細介紹該命令）的子程序，如果在執行則bgsave命令直接返回。bgsave/bgrewriteaof 的子程序不能同時執行，主要是基於效能方面的考慮：兩個併發的子程序同時執行大量的磁碟寫操作，可能引起嚴重的效能問題。
2. 父程序執行fork操作建立子程序，這個過程中父程序是阻塞的，Redis不能執行來自客戶端的任何命令
3. 父程序fork後，bgsave命令返回”Background saving started”資訊並不再阻塞父程序，並可以響應其他命令
4. 子程序建立RDB檔案，根據父程序記憶體快照生成臨時快照檔案，完成後對原有檔案進行原子替換
5. 子程序傳送訊號給父程序表示完成，父程序更新統計資訊

RDB檔案

RDB檔案是經過壓縮的二進位制檔案，下面介紹關於RDB檔案的一些細節。

儲存路徑
RDB檔案的儲存路徑既可以在啟動前配置，也可以通過命令動態設定。

配置：dir配置指定目錄，dbfilename指定檔名。預設是Redis根目錄下的dump.rdb檔案。

動態設定：Redis啟動後也可以動態修改RDB儲存路徑，在磁碟損害或空間不足時非常有用；執行命令為config set dir {newdir}和config set dbfilename {newFileName}。

RDB檔案格式

RDB檔案格式如下圖所示

image

其中各個欄位的含義說明如下：

1. REDIS：常量，儲存著”REDIS”5個字元。
2. db_version：RDB檔案的版本號，注意不是Redis的版本號。
3. SELECTDB 0 pairs：表示一個完整的資料庫(0號資料庫)，同理SELECTDB 3 pairs表示完整的3號資料庫；只有當資料庫中有鍵值對時，RDB檔案中才會有該資料庫的資訊(上圖所示的Redis中只有0號和3號資料庫有鍵值對)；如果Redis中所有的資料庫都沒有鍵值對，則這一部分直接省略。其中：SELECTDB是一個常量，代表後面跟著的是資料庫號碼；0和3是資料庫號碼；pairs則儲存了具體的鍵值對資訊，包括key、value值，及其資料型別、內部編碼、過期時間、壓縮資訊等等。
4. EOF：常量，標誌RDB檔案正文內容結束。
5. check_sum：前面所有內容的校驗和；Redis在載入RBD檔案時，會計算前面的校驗和並與check_sum值比較，判斷檔案是否損壞。

壓縮

Redis預設採用LZF演算法對RDB檔案進行壓縮。雖然壓縮耗時，但是可以大大減小RDB檔案的體積，因此壓縮預設開啟；可以通過命令關閉：

需要注意的是，RDB檔案的壓縮並不是針對整個檔案進行的，而是對資料庫中的字串進行的，且只有在字串達到一定長度(20位元組)時才會進行。

啟動時載入

RDB檔案的載入工作是在伺服器啟動時自動執行的，並沒有專門的命令。但是由於AOF的優先順序更高，因此當AOF開啟時，Redis會優先載入AOF檔案來恢復資料；只有當AOF關閉時，才會在Redis伺服器啟動時檢測RDB檔案，並自動載入。伺服器載入RDB檔案期間處於阻塞狀態，直到載入完成為止。

Redis啟動日誌中可以看到自動載入的執行。

Redis載入RDB檔案時，會對RDB檔案進行校驗，如果檔案損壞，則日誌中會列印錯誤，Redis啟動失敗。

RDB的優勢

• 一旦採用該方式，那麼你的整個Redis資料庫將只包含一個檔案，這對於檔案備份而言是非常完美的。比如，你可能打算每個小時歸檔一次最近24小時的資料，同時還要每天歸檔一次最近30天的資料。通過這樣的備份策略，一旦系統出現災難性故障，我們可以非常容易的進行恢復。

• 對於災難恢復而言，RDB是非常不錯的選擇。因為我們可以非常輕鬆的將一個單獨的檔案壓縮後再轉移到其它儲存介質上。

• 效能最大化。對於Redis的服務程序而言，在開始持久化時，它唯一需要做的只是fork出子程序，之後再由子程序完成這些持久化的工作，這樣就可以極大的避免服務程序執行IO操作了。

• 相比於AOF機制，如果資料集很大，RDB的啟動效率會更高。

RDB的劣勢

• 如果你想保證資料的高可用性，即最大限度的避免資料丟失，那麼RDB將不是一個很好的選擇。因為系統一旦在定時持久化之前出現宕機現象，此前沒有來得及寫入磁碟的資料都將丟失。即兩次持久化之間的時間宕機了，就會丟失上一次持久化到宕機時間內的資料。

• 由於RDB是通過fork子程序來協助完成資料持久化工作的，因此，如果當資料集較大時，可能會導致整個伺服器停止服務幾百毫秒，甚至是1秒鐘。

AOF持久化

RDB持久化是將程序資料寫入檔案，而AOF持久化(即Append Only File持久化)，則是將Redis執行的每次寫命令記錄到單獨的日誌檔案中（有點像MySQL的binlog）；當Redis重啟時再次執行AOF檔案中的命令來恢復資料。

與RDB相比，AOF的實時性更好，因此已成為主流的持久化方案。

開啟AOF

Redis伺服器預設開啟RDB，關閉AOF；要開啟AOF，需要在配置檔案中配置。(下文中有相關配置介紹)

執行流程

由於需要記錄Redis的每條寫命令，因此AOF不需要觸發，下面介紹AOF的執行流程。

AOF的執行流程包括：

• 命令追加(append)：將Redis的寫命令追加到緩衝區aof_buf；
• 檔案寫入(write)和檔案同步(sync)：根據不同的同步策略將aof_buf中的內容同步到硬碟；
• 檔案重寫(rewrite)：定期重寫AOF檔案，達到壓縮的目的。

命令追加(append)
Redis先將寫命令追加到緩衝區，而不是直接寫入檔案，主要是為了避免每次有寫命令都直接寫入硬碟，導致硬碟IO成為Redis負載的瓶頸。

命令追加的格式是Redis命令請求的協議格式，它是一種純文字格式，具有相容性好、可讀性強、容易處理、操作簡單避免二次開銷等優點；具體格式略。在AOF檔案中，除了用於指定資料庫的select命令（如select 0 為選中0號資料庫）是由Redis新增的，其他都是客戶端傳送來的寫命令。

檔案寫入(write)和檔案同步(sync)
Redis提供了多種AOF快取區的同步檔案策略，策略涉及到作業系統的write函式和fsync函式，說明如下：

為了提高檔案寫入效率，在現代作業系統中，當用戶呼叫write函式將資料寫入檔案時，作業系統通常會將資料暫存到一個記憶體緩衝區裡，當緩衝區被填滿或超過了指定時限後，才真正將緩衝區的資料寫入到硬盤裡。這樣的操作雖然提高了效率，但也帶來了安全問題：如果計算機停機，記憶體緩衝區中的資料會丟失；因此係統同時提供了fsync、fdatasync等同步函式，可以強制作業系統立刻將緩衝區中的資料寫入到硬盤裡，從而確保資料的安全性。

AOF快取區的同步檔案策略由引數appendfsync控制，各個值的含義如下：

• always：命令寫入aof_buf後立即呼叫系統fsync操作同步到AOF檔案，fsync完成後執行緒返回。這種情況下，每次有寫命令都要同步到AOF檔案，硬碟IO成為效能瓶頸，Redis只能支援大約幾百TPS寫入，嚴重降低了Redis的效能；即便是使用固態硬碟（SSD），每秒大約也只能處理幾萬個命令，而且會大大降低SSD的壽命。
• no：命令寫入aof_buf後呼叫系統write操作，不對AOF檔案做fsync同步；同步由作業系統負責，通常同步週期為30秒。這種情況下，檔案同步的時間不可控，且緩衝區中堆積的資料會很多，資料安全性無法保證。
• everysec：命令寫入aof_buf後呼叫系統write操作，write完成後執行緒返回；fsync同步檔案操作由專門的執行緒每秒呼叫一次。everysec是前述兩種策略的折中，是效能和資料安全性的平衡，因此是Redis的預設配置，也是我們推薦的配置。

檔案重寫

隨著時間流逝，Redis伺服器執行的寫命令越來越多，AOF檔案也會越來越大；過大的AOF檔案不僅會影響伺服器的正常執行，也會導致資料恢復需要的時間過長。

檔案重寫是指定期重寫AOF檔案，減小AOF檔案的體積。需要注意的是，AOF重寫是把Redis程序內的資料轉化為寫命令，同步到新的AOF檔案；不會對舊的AOF檔案進行任何讀取、寫入操作!

關於檔案重寫需要注意的另一點是：對於AOF持久化來說，檔案重寫雖然是強烈推薦的，但並不是必須的；即使沒有檔案重寫，資料也可以被持久化並在Redis啟動的時候匯入；因此在一些實現中，會關閉自動的檔案重寫，然後通過定時任務在每天的某一時刻定時執行。

檔案重寫之所以能夠壓縮AOF檔案，原因在於：

• 過期的資料不再寫入檔案
• 無效的命令不再寫入檔案：如有些資料被重複設值(set mykey v1, set mykey v2)、有些資料被刪除了(sadd myset v1, del myset)等等
• 多條命令可以合併為一個：如sadd myset v1, sadd myset v2, sadd myset v3可以合併為sadd myset v1 v2 v3。不過為了防止單條命令過大造成客戶端緩衝區溢位，對於list、set、hash、zset型別的key，並不一定只使用一條命令；而是以某個常量為界將命令拆分為多條。這個常量在redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD中定義，不可更改，3.0版本中值是64。

檔案重寫的觸發

檔案重寫的觸發，分為手動觸發和自動觸發：

• 手動觸發：直接呼叫bgrewriteaof命令，該命令的執行與bgsave有些類似：都是fork子程序進行具體的工作，且都只有在fork時阻塞。

• 自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage引數，以及aof_current_size和aof_base_size狀態確定觸發時機。

  • auto-aof-rewrite-min-size：執行AOF重寫時，檔案的最小體積，預設值為64MB。
  • auto-aof-rewrite-percentage：執行AOF重寫時，當前AOF大小(即aof_current_size)和上一次重寫時AOF大小(aof_base_size)的比值。

其中，引數可以通過config get命令檢視：

狀態可以通過info persistence檢視：

只有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個引數同時滿足時，才會自動觸發AOF重寫，即bgrewriteaof操作。

檔案重寫的流程

檔案重寫流程如下圖所示：

關於檔案重寫的流程，有兩點需要特別注意：

(1)重寫由父程序fork子程序進行；

(2)重寫期間Redis執行的寫命令，需要追加到新的AOF檔案中，為此Redis引入了aof_rewrite_buf快取。

對照上圖，檔案重寫的流程如下：

1. Redis父程序首先判斷當前是否存在正在執行 bgsave/bgrewriteaof的子程序，如果存在則bgrewriteaof命令直接返回，如果存在bgsave命令則等bgsave執行完成後再執行。前面曾介紹過，這個主要是基於效能方面的考慮。

2. 父程序執行fork操作建立子程序，這個過程中父程序是阻塞的。

3. 父程序fork後，bgrewriteaof命令返回”Background append only file rewrite started”資訊並不再阻塞父程序，並可以響應其他命令。Redis的所有寫命令依然寫入AOF緩衝區，並根據appendfsync策略同步到硬碟，保證原有AOF機制的正確。

4. 由於fork操作使用寫時複製技術，子程序只能共享fork操作時的記憶體資料。由於父程序依然在響應命令，因此Redis使用AOF重寫緩衝區(圖中的aof_rewrite_buf)儲存這部分資料，防止新AOF檔案生成期間丟失這部分資料。也就是說，bgrewriteaof執行期間，Redis的寫命令同時追加到aof_buf和aof_rewirte_buf兩個緩衝區。

5. 子程序根據記憶體快照，按照命令合併規則寫入到新的AOF檔案。

6. 子程序寫完新的AOF檔案後，向父程序發訊號，父程序更新統計資訊，具體可以通過info persistence檢視。

7. 父程序把AOF重寫緩衝區的資料寫入到新的AOF檔案，這樣就保證了新AOF檔案所儲存的資料庫狀態和伺服器當前狀態一致。

8. 使用新的AOF檔案替換老檔案，完成AOF重寫。

啟動時載入

當AOF開啟時，Redis啟動時會優先載入AOF檔案來恢復資料；只有當AOF關閉時，才會載入RDB檔案恢復資料。

檔案校驗

與載入RDB檔案類似，Redis載入AOF檔案時，會對AOF檔案進行校驗，如果檔案損壞，則日誌中會列印錯誤，Redis啟動失敗。但如果是AOF檔案結尾不完整(機器突然宕機等容易導致檔案尾部不完整)，且aof-load-truncated引數開啟，則日誌中會輸出警告，Redis忽略掉AOF檔案的尾部，啟動成功。aof-load-truncated引數預設是開啟的：

偽客戶端

因為Redis的命令只能在客戶端上下文中執行，而載入AOF檔案時命令是直接從檔案中讀取的，並不是由客戶端傳送；因此Redis伺服器在載入AOF檔案之前，會建立一個沒有網路連線的客戶端，之後用它來執行AOF檔案中的命令，命令執行的效果與帶網路連線的客戶端完全一樣。

AOF的優勢

• 該機制可以帶來更高的資料安全性，即資料永續性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事實上，

  • 每秒同步也是非同步完成的，其效率也是非常高的，所差的是一旦系統出現宕機現象，那麼這一秒鐘之內修改的資料將會丟失。
  • 每修改同步，我們可以將其視為同步持久化，即每次發生的資料變化都會被立即記錄到磁碟中。可以預見，這種方式在效率上是最低的。
  • 無同步，字面意思。

• 由於該機制對日誌檔案的寫入操作採用的是append模式，因此在寫入過程中即使出現宕機現象，也不會破壞日誌檔案中已經存在的內容。然而如果我們本次操作只是寫入了一半資料就出現了系統崩潰問題，不用擔心，在Redis下一次啟動之前，我們可以通過redis-check-aof工具來幫助我們解決資料一致性的問題。

• 如果日誌過大，Redis可以自動啟用rewrite機制。即Redis以append模式不斷的將修改資料寫入到老的磁碟檔案中，同時Redis還會建立一個新的檔案用於記錄此期間有哪些修改命令被執行。因此在進行rewrite切換時可以更好的保證資料安全性。

• AOF包含一個格式清晰、易於理解的日誌檔案用於記錄所有的修改操作。事實上，我們也可以通過該檔案完成資料的重建。

AOF的劣勢

• 對於相同數量的資料集而言，AOF檔案通常要大於RDB檔案（比如，一個 key 多次寫入，這個過程整個都會在恢復時在現）。RDB 在恢復大資料集時的速度比 AOF 的恢復速度要快。

• 根據同步策略的不同，AOF在執行效率上往往會慢於RDB。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和RDB一樣高效。

二者選擇的標準，就是看系統是願意犧牲一些效能，換取更高的快取一致性（aof），還是願意寫操作頻繁的時候，不啟用備份來換取更高的效能，待手動執行save的時候，再做備份（rdb）。rdb這個就更有些 eventually consistent的意思了。

兩種方式的常用配置

RDB持久化配置

Redis會將資料集的快照dump到dump.rdb檔案中。此外，我們也可以通過配置檔案來修改 Redis伺服器dump快照的頻率，在開啟redis.conf檔案之後，我們搜尋 save ，可以看到下面的配置資訊：

• 預設備份的時間間隔

save 900 1              #在900秒(15分鐘)之後，如果至少有1個key發生變化，則dump記憶體快照。

save 300 10            #在300秒(5分鐘)之後，如果至少有10個key發生變化，則dump記憶體快照。

save 60 10000        #在60秒(1分鐘)之後，如果至少有10000個key發生變化，則dump記憶體快照。

• 預設備份的檔名稱

# The filename where to dump the DB
dbfilename dump.rdb

• 預設備份的 RDB 檔案位置

# Note that you must specify a directory here, not a file name.
dir /usr/local/var/db/redis/

• 是否開啟RDB檔案壓縮

# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes

• 是否開啟RDB檔案校驗

# tell the loading code to skip the check.
rdbchecksum yes

• bgsave出現錯誤時，redis是否停止執行寫命令。

# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes

設定為yes，則當硬碟出現問題時，可以及時發現，避免資料的大量丟失；設定為no，則Redis無視bgsave的錯誤繼續執行寫命令，當對Redis伺服器的系統(尤其是硬碟)使用了監控時，該選項考慮設定為no

動態設定：Redis 啟動後也可以動態修改 RDB 儲存路徑，在磁碟空間不足時非常有用。執行命令如下：
config set dir {newdir} 和 config set dbfilename {newFileName}。

AOF持久化配置

• 開啟 AOF 持久化模式

# Please check http://redis.io/topics/persistence for more information.

appendonly yes  # appendonly no   yes 為 開

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"  # 儲存記錄的檔名

• 在Redis的配置檔案中存在三種同步方式，它們分別是：

# appendfsync always      # 每次有資料修改發生時都會寫入AOF檔案。

appendfsync everysec      # 每秒鐘同步一次，該策略為AOF的預設策略。優先

# appendfsync no          # 從不同步。高效但是資料不會被持久化。

• 其他配置

# "no" that is the safest pick from the point of view of durability.

no-appendfsync-on-rewrite no  # AOF重寫期間是否禁止fsync；如果開啟該選項，可以減輕檔案重寫時CPU和硬碟的負載（尤其是硬碟），但是可能會丟失AOF重寫期間的資料；需要在負載和安全性之間進行平衡

# rewrite feature.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb


# will be found.
aof-load-truncated yes # 如果AOF檔案結尾損壞，Redis啟動時是否仍載入AOF檔案

RDB 模式和 AOF 模式的恢復

Redis崩潰後，重啟redis會自動找備份恢復檔案。

RDB檔案的載入工作是在伺服器啟動時自動執行的，並沒有專門的命令。但是由於AOF的優先順序更高，因此當AOF開啟時，Redis會優先載入AOF檔案來恢復資料；只有當AOF關閉時，才會在Redis伺服器啟動時檢測RDB檔案，並自動載入。伺服器載入RDB檔案期間處於阻塞狀態，直到載入完成為止。

Redis啟動日誌中可以看到自動載入的執行。

Redis載入RDB檔案時，會對RDB檔案進行校驗，如果檔案損壞，則日誌中會列印錯誤，Redis啟動失敗。

下圖大致描述了redis重啟後的過程。

參考文件：來源一 來源二 來源三 來源四-包含持久化的策略選擇